Disaster Recovery and Rsync (was [lug] Commercial rsync service?)
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
>> This is very common in the commercial world. There's another step
>> Put DB in quiet mode. (No disk reads or writes, but DB is still up.)
>> 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
More information about the LUG