backups using rsync

[David Brodbeck]

On Mon, Mar 4, 2013 at 1:37 PM, CyberLeo Kitsana <cyberleo at cyberleo.net>wrote:

> You can use dump(8) to dump a SU-journaled filesystem; you just cannot
> create a snapshot. This implies that dump(8) will be run against the
> live and possibly changing filesystem, which can lead to issues with the
> consistency of the contents of files thus dumped; but not necessarily
> with the consistency of the dump itself. Any tool that backs up a live
> filesystem, such as rsync or tar, will have these issues.
>

Note that this is mainly a problem for things like databases, where the
contents of multiple files, or different portions of the same file, have to
be in sync.  For example, take your typical MySQL database table.  You have
the actual data, in a .MYD file, and the indexes, in a .MYI file.  If your
rsync backup hits while a table is being updated, it might get the .MYD
file before an update, and the .MYI file after, leaving the table and index
inconsistent.  Or it might catch the .MYD file *partway* through an update,
giving a file that's internally inconsistent.  This is likely to give very
unexpected results if you load the backup back into the database.

Note that even if you take a filesystem snapshot, if you don't halt
database updates while you take it, you can still end up with inconsistent
files.  Snapshots are mostly useful for limiting the downtime in these
kinds of scenarios -- instead of taking the DB offline for the whole backup
window, you just down it long enough to take the snapshot.

In the absence of snapshots, the easiest way is to use whatever backup
tools the database offers to make sure a consistent copy exists to be
backed up.  For example, before you run the backup, run mysqlhotcopy or
mysqldump to write-lock the database, make consistent backup copies of all
the files, then unlock it.  That way, even if the backup of the active
database is inconsistent, the copies that were backed up along with it are
guaranteed to be consistent.

Anything database-like can have this problem; another common example is a
Subversion FSFS repository.  Backing it up without running "svnadmin
hotcopy" first is asking for corrupt commits when you do a restore.