On 2/29/12 3:30 PM, todderamaa wrote: > --- In firebird-support@yahoogroups.com, Doug Chamberlin > <chamberlin.doug@...> wrote: >> On 2/29/12 2:50 PM, todderamaa wrote: >>> Maybe with the possibility of corruption, I should tell him to exclude >>> the database files from backup entirely and only backup the gbk files >>> that are created in the evening. >> This is the usual way to backup Firebird databases in situations like >> your clients have. Operating on the live database files is a quick way >> to corrupted backup copies. If you have not experienced corruption >> either you have been lucky or have not actually tried restoring from >> many of those backup copies. > I thought that the corruption could actually happen to the live database you > were copying, not just the backup. > > Is the risk only to the backup?
The architecture in use has some bearing on the situation. With Firebird's superserver architecture it is my understanding that the server process opens the database files for exclusive, read-write access. If that prevents the backup software from reading the file I generally consider that a good thing. After all, that's what exclusive access is for. But if the backup process has enough privilege to bypass an exclusive lock, who knows what will happen. If Firebird's' classic architecture is being used then each process accessing the file can read it. However, it's hard to imagine a read-only file access would corrupt the file being read. Perhaps better experts than I can give you a more definitive answer.
