Subject | gbak reliability problem |
---|---|
Author | jack.mason58 |
Post date | 2013-08-09T13:42:57Z |
Whether we use the old Interbase 6.02 gbak or the current 2.52 (as of yesterday) Firebird gbak, gbak will not reliably backup one of our Interbase databases.
The structure of the failing database table is quite simple: one integer, one timestamp, and one blob. The blob appears to be the problem. The database is backed up successfully until this table is attempted. Even though the database is on a remote system that is quite slow to access, most of the database backs up within a couple of minutes, including 145,000 records of another table
Sometimes gbak will back up the entire table, and complete the entire database successfully, sometimes it will hang showing no recordss backed up, sometimes 20,000 records backed up, sometimes 40,000 records backed up. When it hangs, it hangs for about an hour (we haven't actually timed it) and then aborts.
The backup command is part of a Windows batch file:
C:\"program files"\firebird\firebird_2_5\bin\gbak -b -v lserver:C:\BFL\SMTBDB\sales C:\backups\Friday\sales.bak
The structure of the failing database table is quite simple: one integer, one timestamp, and one blob. The blob appears to be the problem. The database is backed up successfully until this table is attempted. Even though the database is on a remote system that is quite slow to access, most of the database backs up within a couple of minutes, including 145,000 records of another table
Sometimes gbak will back up the entire table, and complete the entire database successfully, sometimes it will hang showing no recordss backed up, sometimes 20,000 records backed up, sometimes 40,000 records backed up. When it hangs, it hangs for about an hour (we haven't actually timed it) and then aborts.
The backup command is part of a Windows batch file:
C:\"program files"\firebird\firebird_2_5\bin\gbak -b -v lserver:C:\BFL\SMTBDB\sales C:\backups\Friday\sales.bak