Re: Scheduled backup + files store
Re: Scheduled backup + files store
- Subject: Re: Scheduled backup + files store
- From: Guido Neitzer <email@hidden>
- Date: Wed, 13 May 2009 12:58:55 -0700
On May 13, 2009, at 12:42 PM, Stamenkovic Florijan wrote:
1. Refuse or delay the transfers of files to the server at a
particular time of day when the backup is happening. This is sloppy,
I don't want to do it.
This is what I do at the moment. Not the best solution though.
2. If I first perform the database backup, and afterwards backup the
files (delay it a bit), the only risk I run is that I have a file
too many in my file storage. This could be acceptable if I tweak my
server-side file writing to overwrite without asking.
This is not true, if your users can also delete files. You might end
up with a backup that refers to files that were deleted during the
backup run.
Is there a better, standardized way of doing this?
Hmm. I could think of triggering an rsync to file system clone when
you also trigger the db backup. If you do the rsync part really often
(so that only minimal changes need to be transferred each time), you
should have a pretty good snapshot of the file for the time when you
start your db backup. Now, during the db backup you can stop the rsync
process so changes happening during the db backup will not change your
FS structure.
This is just an idea, there might be better ways.
Maybe in the future this will be easier using ZFS snapshots or
something similar (at least, if I read the feature correctly).
cug
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden