[ZODB-Dev] Online Backup , in Windows 2000 Server

Tim Peters tim at zope.com
Tue May 11 15:00:06 EDT 2004


[Sajan Varghese]
>> ...
>>   I doing my deployement in Windows 2000 Server , I am using Zope
>> 2.7 and Plone 1.0.5 , with some Products of Plone .
>>
>>  Now , I have tested in Windows 2000 , Online Backup of the Var
>> Folder or the Data.fs doesnt , work , I have read many mail list
>> that in linux does an online backup.

Sorry, I don't know what "doesn't work" means, or what "Online Backup" means
(is that a generic term, or the label on some button in some GUI app, or
...?).  Exactly what did you do, and exactly what happened as a result?

[Dieter Maurer]
> It would work iff Windows would let you copy open files...

Windows doesn't allow to rename or delete an open file, but it has no
prohibition against opening again (and then copying) an already-open file.
By explicit action, it's *possible* to lock a file in Windows, using
Windows-specific calls, so that a process has exclusive access to a file's
contents; but, e.g., ZODB does not do that for Data.fs files.

For example, here in a DOS box I open a pre-existing file:

>>> f = open('temp.txt', 'r+b')
>>>

Over in another DOS box I copy it:

C:\Code>copy temp.txt temp2.txt
        1 file(s) copied
C:\Code>

No problem.

> Apparently, there are some tricks to do this: MS Word appears to be
> able to read file which are currently under work.

The only trick is not explicitly stopping it from working <wink>.

> ...
> Another one: tell Zope to pack its database (you can do this
> via an HTTP request, e.g. with Python's "urllib" or with
> "ZPublisher.Client"). When packing is complete, backup
> "Data.fs.old".

Indeed, ZODB packs an open FileStorage by opening the file again in the
packing thread, on Linux and on Windows.  This allows packing to proceed in
parallel with ongoing database mutations.  Nothing special was needed to
make this work on Windows (to the contrary, something special turned out to
be needed to make it work on most non-Windows boxes, because mutations made
via one file handle weren't always getting seen by other file handles open
on the same underlying file).




More information about the ZODB-Dev mailing list