On Wed, 21 Dec 2005, Daniel Webb wrote:
> I read somewhere that this isn't a problem with rsync, that it only copies > atomically. So are snapshots even needed if using rsync? yes... snapshots is needed if rsync doesn't do what oyu want > I'm curious as to the relative merits of rdiff-backup vs. rsync snapshots > (http://www.mikerubel.org/computers/rsync_snapshots/). == == things gets messy ( aka fun ) if you want to recover any random file to == any random time and date == ( which is trivial to do if you perform the "proper steps" ) == --- --- get into the habit of "save it" before you edit(destroy) it --- --- one you write it, its is 100x harder to undo that change --- and is possible to recover under some/certain circumstances --- otherwise, the previous copy is forever lost or corrupted --- -- which way is the preferred way would depend on the task at hand and NOT the methodology - to have a live backup of identical data files - to save the "previous known good state" prior to the corruption or [cr|h]acker - to apply the changes to the "backup" or "rsync" or "snapshot" or foo-blah-blah are all the same and have the same problems and features if the files are modified or not modified by the 1000 different ways to "do it" rsync ... - you can do dry-runs to prevent mistakes or see what it will do before you do it - lots of useful options ( -v, --bandwidth, --dry-run, logs, .. ) - copies everything from Master into OtherDisk which is good and bad depending on your paranoia level - there is no history of what was overwritten unless you save rsync logs rsync -v master:/home/ mirror:/home 21& | \ tee /var/log/rsync.log but that history does NOT let oyu recover the the passwd files or other files prior to rsync - you cannot undo the changes prior to rync running unless you saved that copy BEFORE running rsync - if undo of "rsync" changes is required, you have to save the ALL the changes on the master server along with the full backups and you can gurantee to reoover to any date/time as long as you can gurantee full and incremental backups are not corrupted - more stuff snap-shots - typically a full backup at that time - sometimes, typically intended to be a difference between what was previously saved as full backup and the current set of changes - some people apply the "snap shots" to the mirrors, backups and snapshot servers... - if you apply the changes, you cannot undo the changes unless you save before applying changes - if you leave the snapshots as just a file of changes, that is a good thing - more stuff - find | tar | gpg meeets all of my requirements for most all possible potential disasters and recovery - there are common basic requirements and assumptions that applies to all methodologies - how long to recover the data you just lost - what is the costs of recovering the data - what is the consequence if your all important web server dies - how much $$$ do you lose .. vs how much $$$ you spent to protect against 1 failure mode - how good are you at "disaster simulations", preparedness and recovery - did you just put your /etc/shadow file into a world readable file onto a un-maintained backup machine that doesn't ask for passwds - backup machines are checked how often for signs of [h|cr]ackers - assume a malicious rm -rf / cracker is in your network and machines, ( because they are ) ... now protect your data - 9/10 [h|cr]ackers will be *-you-* that broke it by fiddling with something and your alarms should be lighting up like a xmas tree ... and if you didn't get those emails that /etc/shadow was changed or other important files, you'll never find the cancer growing in your servers - endless list - name and explicitly list 100 ways your server can die - gazillion ways to make backups, mirrors and snapshots c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
