The tech that does backups on my new NT server (IIS) tells me that everything backs up ok except the \var\Data.fs.lock file. Is that normal or a problem? Darren Addy Internet Specialist and Interim Web Presence Coordinator Office of Information Technology Services University of Nebraska at Kearney
On Tue, 27 Jun 2000 16:30:30 -0500, addyd@unk.edu wrote:
The tech that does backups on my new NT server (IIS) tells me that everything backs up ok except the \var\Data.fs.lock file. Is that normal or a problem?
It's definitely normal, and arguably a problem. On Windows, any file opened for write access by the C fopen function has its sharing flags set so that no other process can read or write the file. I solve the problem with a small batch file, scheduled to run just before the backup, that looks similar to.... net stop zope copy c:/zope/var/data.fs c:/zope/var/backupdata.fs net start zope hope this helps, Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson wrote:
It's definitely normal, and arguably a problem.
net stop zope copy c:/zope/var/data.fs c:/zope/var/backupdata.fs net start zope
I'd say it's definitely a problem if you have to stop zope to do a backup :( But then, I'd say it's a problem running (Zope on) Windows in a production environment ;-) cheers, Chris
On Wed, 28 Jun 2000, Chris Withers wrote:
I'd say it's definitely a problem if you have to stop zope to do a backup :(
How would you do it? In Unix you can't check if the file is being read to (can you?), so if you start backing up a 2GB Data.fs file and then the Zope process starts writing to it, you'll have garbage :-). Does ZEO solve this?
Erik Enge wrote:
How would you do it? In Unix you can't check if the file is being read to (can you?), so if you start backing up a 2GB Data.fs file and then the Zope process starts writing to it, you'll have garbage :-).
I don't think you'd have garbage since it's just transactions beign tacked on the end of what's there already but it is a good point nonetheless... So, how should we backup data.fs without stopping Zope and ensuring the integrity of our data all the while? cheers, Chris
On Wed, 28 Jun 2000, Chris Withers wrote:
So, how should we backup data.fs without stopping Zope and ensuring the integrity of our data all the while?
Pack and backup Data.fs.old. Oleg. (All opinions are mine and not of my employer) ---- Oleg Broytmann Foundation for Effective Policies phd@phd.russ.ru Programmers don't die, they just GOSUB without RETURN.
On Wed, 28 Jun 2000, Oleg Broytmann wrote:
On Wed, 28 Jun 2000, Chris Withers wrote:
So, how should we backup data.fs without stopping Zope and ensuring the integrity of our data all the while?
Pack and backup Data.fs.old.
But what if the site is incredibly busy and transactions are going on _all the time_? And can you automate the Pack function? (If I wanted to do it during the night for example)
Erik Enge wrote:
On Wed, 28 Jun 2000, Oleg Broytmann wrote:
On Wed, 28 Jun 2000, Chris Withers wrote:
So, how should we backup data.fs without stopping Zope and ensuring the integrity of our data all the while?
Pack and backup Data.fs.old.
But what if the site is incredibly busy and transactions are going on _all the time_? And can you automate the Pack function? (If I wanted to do it during the night for example)
Would this whole problem go away if Zope had a 'backup data.fs' funcion internally that could keep all transactions in memory while the appopriate files were copied? Chris
On Thu, 29 Jun 2000, Chris Withers wrote:
Would this whole problem go away if Zope had a 'backup data.fs' funcion internally that could keep all transactions in memory while the appopriate files were copied?
It would, but keeping it in memory would be a bad thing. Say your data.fs file was 10GB large, and it took 4 hours to back it up, and you only had X amount of RAM - then it would begin swapping after some time. Now that would be ugly :-). One could possibly have a function that put new transactions in a new file, and then - when told it was ok to do so - it could update the regular data.fs file. Actually, if I'm not mistaken, this could be something to put in ZEO?
Erik Enge wrote:
One could possibly have a function that put new transactions in a new file, and then - when told it was ok to do so - it could update the regular data.fs file.
Hmm, about extending this so you have 'rotating data.fs files' in the same way you have rotating log files?
Actually, if I'm not mistaken, this could be something to put in ZEO?
Definitely, but I think it also needs to be solved for the normal Zope case as this is what most people will be running... Chris
On Thu, 29 Jun 2000, Chris Withers wrote:
Hmm, about extending this so you have 'rotating data.fs files' in the same way you have rotating log files?
In general, yes :-). Do you think it would be solving the right problem the right way?
Definitely, but I think it also needs to be solved for the normal Zope case as this is what most people will be running...
That's right.
Erik Enge wrote:
On Thu, 29 Jun 2000, Chris Withers wrote:
Hmm, about extending this so you have 'rotating data.fs files' in the same way you have rotating log files?
In general, yes :-). Do you think it would be solving the right problem the right way?
I think so, but that's only my view. If anyone's got any better ideas, please pipe up :-) cheers, Chris
On Wed, 28 Jun 2000, Erik Enge wrote:
Pack and backup Data.fs.old.
But what if the site is incredibly busy and transactions are going on _all the time_? And can you automate the
I beleive packing works fine in this situataion.
Pack function? (If I wanted to do it during the night for example)
Never tried it myself, but I do not expect to call manage_pack using ZClient or XML-RPC. Just provide correct login/password in a script, and hide the script from random readers. Oleg. (All opinions are mine and not of my employer) ---- Oleg Broytmann Foundation for Effective Policies phd@phd.russ.ru Programmers don't die, they just GOSUB without RETURN.
participants (5)
-
addyd＠unk.edu -
Chris Withers -
Erik Enge -
Oleg Broytmann -
Toby Dickenson