[ZODB-Dev] Copying filestorage file while program is running

[Toby Dickenson]

On Wednesday 16 Oct 2002 3:22 pm, Magnus Lycka wrote:
> My client just asked me if it's safe for him to backup
> the xxx.fs file when he has saved, or if he must close
> the program first. (The only thing I do on "save" is
> get_transaction().commit().)
>
> Is it?

It is as safe as any software can be.

Partially it depends on the backup software. Reading the file the obvious=
 way=20
is safe (open it, then read it until end of file). Some software (such as=
=20
rsync, I think) can do bad things if the file changes during the backup=20
process.

(one exception - I think (but havent proved) that there is a small proble=
m=20
window in FileStorage's non-transactional undo. Zope always uses=20
transactional undo, which is definitely safe.)

Of course other things can always defeat this safety. For example, readin=
g the=20
backup over NFS can risk breaking any backup software.

> Is there any clever/safer way to make a backup of the
> database from the code?

Using FileStorage? no.

> What about the tmp- and index-files? Might we need them?

tmp- you *never* need.

index- I suggest not backing up. It is only used to make startup faster. =
Not=20
having it will make startup a little slower until a new index- is written=
=2E If=20
your database has changed since the index was written then it will not be=
=20
used anyway.

> I assume that ZODB fully updates the file when the
> transaction is committed, but I'm not certain about
> Windows flushing things and so on.

That a relevant question if you are concerned with data durability across=
=20
power loss or system crash. Whether or not things are flushed to permanen=
t=20
storage on disk, a backup process running concurrently to the database wi=
ll=20
always see the same file contents.

> On a related subject, what happens when Windows crashes
> with the program running? Can we be certain that all
> committed transactions are in the file, amd that it's
> not corrupted when we start the computer again?
> (Something more elaborate then "No" would be very helpful. ;)

All the common storages (FileStorage, Berkeley/*, DirectoryStorage,=20
OracleStorage) are as safe as they can be. Other aspects of your=20
configuration can always defeat this too. Problems you might want to look=
 out=20
for are filesystem type (use vfat and all bets are off), and volatile=20
writeback caches in your ide controller (particularly on laptops)