[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

	- 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 

	- did you just put your /etc/shadow file into a world readable
	file onto a un-maintained backup machine that doesn't ask for

	- 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

Reply to: