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

Nate Duehr nate at natetech.com
Sun Feb 5 08:13:03 MST 2006

Jeffrey Siegal wrote:
> On Feb 3, 2006, at 23:34 , Nate Duehr wrote:
>>> One way do deal with this is to use LVM snapshots.  Snapshot, mount 
>>> snapshot read only, rsync from snapshot, unmount and then delete the 
>>> snapshot.
>> This is very common in the commercial world.  There's another step 
>> usually...
>> Put DB in quiet mode. (No disk reads or writes, but DB is still up.)
>> snapshot
>> Put DB back in normal mode.
> This isn't strictly necessary, but I guess it avoids a recovery step and 
> the possibility of data loss due to bugs in the database and/or storage 
> subsystem.  Ordinarily just creating a point-in-time snapshot should be 
> sufficient, with database rollback/recovery doing everything else 
> required.  The snapshot looks like the system suffered from a crash at 
> that instant, which a decent database should be a able to deal with.
> Be careful with non-transactional databases though (such as MySQL with 
> non-transactional table types).

Yeah, it just saves going through a checkpoint/recovery mode.

Since you're probably already down for some period of time before 
needing to use such a backup to get things back to "normal", saving 
those extra minutes (or more realistically, saving the system resources 
and time going through a checkpoint/recovery would take) can be 
essential for any critical Production level system.  Especially 
considering that going into quiescent mode at backup-time usually takes 
almost NO resources or much extra time at all.

If your DB is so busy you can't get into quiet mode, the "snapshot while 
live" is better than none, but most DB's have at least a few hours a day 
where quiescent mode and a snapshot can be taken without any user impact 
at all.


More information about the LUG mailing list