Re: Question on backups using rsync
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
Reply to: