Disaster Recovery and Rsync (was [lug] Commercial rsync service?)

Siegfried Heintze siegfried at heintze.com
Fri Feb 3 15:29:52 MST 2006


So we need to draw the distinction between WAN disaster recovery (which is
not feasible) and WAN/rsync backup that does not use rsync on your entire
disk -- just a few selected directories.

I assume WAN backup on selected directories is feasible and could maybe be
done with Indra.net?

Thanks,
Siegfried

-----Original Message-----
From: lug-bounces at lug.boulder.co.us [mailto:lug-bounces at lug.boulder.co.us]
On Behalf Of David L. Anselmi
Sent: Friday, February 03, 2006 3:20 PM
To: Boulder (Colorado) Linux Users Group -- General Mailing List
Subject: Re: Disaster Recovery and Rsync (was [lug] Commercial rsync
service?)

Sigh...

Siegfried Heintze wrote:
> It sounds like we are back on the old disaster recovery topic again...
> 
> What are some favorite ways of using rsync with a remote repository
> accessible over the public internet for the purposes of disaster recovery?

No, we're not back on disaster recovery.  WAN backup doesn't scale for 
most people so it isn't done. See:

> 
> (1) Would you only use rsync on directories you are working in? It then
> becomes your responsibility to remember which directories you have
modified
> files in. I've done this for years with zipping directories on CDs but it
> scares me. And if you get hacked you still have to rebuild your system
disk.
> 
> (2) Would you daily rsync everything including the /usr/bin, /bin,
> /usr/local/bin, /etc, etc...? I guess you would use the find command to
> exclude stuff in the /mnt directory so you would not include the entirety
of
> other devices on other machines.
> 
> (3) How do databases work? Do you have to stop the (for example) MySQL
> deamon while you do the rsync? My guess is definitely. What about the
> subversion or cvs deamons? Could this be a problem if you try to use a
> single rsync command for an entire computer's local storage and it takes a
> long time? It seems to me like you would want to have a lot of short shell
> scripts to run daily so you don't have to shut down all your servers at
once
> for the entire duration of the synchronization.
> 
> (4) What about links? Creators of linux distros love links. Does rsync
> properly reconstruct hard and soft links?
> 
> (5) Let us say you initially rsync the entirety of your local storage for
a
> software development computer that also doubles as prototyping web site
> server and cvs/subversion repository. Maybe it is Saturday and you know
you
> have only altered one file. Could you rsync that directory only and would
> rsync be smart enough to find that sub directory in the remote repository
> instead of having to date compares on all the files for the entirety of
your
> local storage?
> 
> (6) I believe someone previously explained that one can boot from a LiveCD
> and use rsync to restore your boot disk and then boot from the boot disk.
I
> guess I should give this a try before disaster strikes. To bad this won't
> work for windows (NTFS) paritions (or will it?). Has anyone tried it? Can
> you run rsync on a windows partition? If you were doing it for the
purposes
> of rebuilding a boot disk, I think you would want to do this at a block
> level because special files like the windows registery cannot (I believe)
be
> simply copied. Sometime ago someone explained to me that they could zip an
> entire Win95 boot disk and restore it with zip and expect to boot, but
this
> did not work with NT. I assume this is still true with XP.
> 
> Can rsync simply bypass the NTFS file system and do block level restores?
> Perhaps there is some other utility?
> 
> 
> Thanks,
> siegfried
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
> 

_______________________________________________
Web Page:  http://lug.boulder.co.us
Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
Join us on IRC: lug.boulder.co.us port=6667 channel=#colug




More information about the LUG mailing list