| Subject | Re: [firebird-support] Ghost image backups |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-06-06T05:17:15Z |
At 02:59 AM 6/06/2008, you wrote:
If you have active operations going on and this application locks the part of the disk where Firebird is writing to (or needs to) then the *best* you can hope for is that the first affected transaction causes the Firebird server to crash and report an i/o error in the log. Between "best" and a completely corrupted database (which this behaviour makes eminently possible), you have a wonderful range of partial and progressive corruptions with an escalating degree of challenge to retrieve and validate the data from the broken database.
EXCLUDE is not a "nice to have", it is a total MUST HAVE. Databases should be in their own partition and the whole partition should be excluded totally from the purview of everything except the Firebird server. It's scary that your principals employ "techs" who can't comprehend a documented warning that clearly indicates the software will break active read/write files, yet have the authority to carry on and install it regardless. It's scary even to think such imbeciles have access to the database file at all!
You could also alert your principals to the fact that, if a database is corrupted, from whatever cause, then the next "ghosts" will be an image of the corrupt file. The "ghosts" will be progressively more corrupt as the backup software continues to subject the database file to potential corruption at 15-minute intervals.
To note also: gbak (or its Services API equivalent) runs inside a single transaction. If this Acronis software, or XP SystemRestore, or VSS, or Norton Ghost, or any of these supposed "disaster recovery for idiots" utilities, should kick in and hit either the database or the backup file while Firebird's backup is running, then the chances of ending up with a restorable backup will be between "small" and "infinitesimal". Indeed, if you are injecting gbaks at hourly intervals alongside, it sounds like a race to the death.
To go back and answer your question about upgrading server and databases to take advantage of nbackup...nbackup is (in a sense) a "ghosting" utility in its own right. But, unlike these block-imaging utilities, it knows what it is doing with the *content* and when it is right to do it. Like database files, nbackup files are read/write files, so the block-imaging utility (and the untechnical "techs" with their unbridled power) must be prevented from getting hold of them as well if the Fb server is running.
./heLen
>That's about what I thought. Let me ask you a question about that, though.Loss of data is only one small problem inside a larger one. The warning to shutdown "complex servers" is the one you (and your principals) need to be concerned about. These utilities have potentially fatal override privileges to enable then to override existing write locks arbitrarily and impose their own for the duration of the image-copying operation. XP SystemRestore, VSS and many of these third-party disk-imaging utilities have these powers.
>They do a backup every 15 minutes according to the tech. Would that be too
>much to worry about even if I upgraded to be able to use NBackup
>functionality? Would I be better off, say, doing my thing every hour or so
>to at least give them as small a lose of data as possible?
If you have active operations going on and this application locks the part of the disk where Firebird is writing to (or needs to) then the *best* you can hope for is that the first affected transaction causes the Firebird server to crash and report an i/o error in the log. Between "best" and a completely corrupted database (which this behaviour makes eminently possible), you have a wonderful range of partial and progressive corruptions with an escalating degree of challenge to retrieve and validate the data from the broken database.
EXCLUDE is not a "nice to have", it is a total MUST HAVE. Databases should be in their own partition and the whole partition should be excluded totally from the purview of everything except the Firebird server. It's scary that your principals employ "techs" who can't comprehend a documented warning that clearly indicates the software will break active read/write files, yet have the authority to carry on and install it regardless. It's scary even to think such imbeciles have access to the database file at all!
You could also alert your principals to the fact that, if a database is corrupted, from whatever cause, then the next "ghosts" will be an image of the corrupt file. The "ghosts" will be progressively more corrupt as the backup software continues to subject the database file to potential corruption at 15-minute intervals.
To note also: gbak (or its Services API equivalent) runs inside a single transaction. If this Acronis software, or XP SystemRestore, or VSS, or Norton Ghost, or any of these supposed "disaster recovery for idiots" utilities, should kick in and hit either the database or the backup file while Firebird's backup is running, then the chances of ending up with a restorable backup will be between "small" and "infinitesimal". Indeed, if you are injecting gbaks at hourly intervals alongside, it sounds like a race to the death.
To go back and answer your question about upgrading server and databases to take advantage of nbackup...nbackup is (in a sense) a "ghosting" utility in its own right. But, unlike these block-imaging utilities, it knows what it is doing with the *content* and when it is right to do it. Like database files, nbackup files are read/write files, so the block-imaging utility (and the untechnical "techs" with their unbridled power) must be prevented from getting hold of them as well if the Fb server is running.
./heLen