On Apr 19, 2007, at 11:01 AM, Tom Malia wrote:
> Might it be helpful if people were to enumerate exactly how this
> data loss
> would/could occur so that he has the requested specific details to
> take to
> his superior as the reason why they MUST change?
I believe this has already been provided but...
If the state of the filesystem changes while the backup running, it
will be backed up in an inconsistent state. That is the first case
that comes to mind. Depending on what the operating system is doing
behind the scenes, I believe there are other things that could go wrong.
An operating system that can handle "shadow copy" type functionality
might be able to backup the file system and preserve the state at the
time the backup was started.
However, if you are backing up something of even moderate importance,
do you want to use something that "might" work or go with the
solution that was designed to work and is being used by thousands of
other people successfully?
If someone is insisting on a tar, go ahead and make the tar, but
create a dump file and put somewhere so you at least have a safety
net. You can even stick it in the tar file.
Here is a link to a script I wrote to handle backups and name them
according to the date and time:
http://blog.markwshead.com/archives/2005/09/21/backing-up-subversion-
automatically.html
The script, creates the backup, zips it and moves it to a remote
server. Then it verifies the backup, by pulling it back down,
creating a new repository, loading everything back in and checking
out a copy of the trunk into a directory. If there is a problem it
should show up in an email to the owner of the cron job that called it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 20 07:11:00 2007