LVM snapshots vs. --link-dest
Andrew Gideon
c182driver1 at gideon.org
Sun Sep 27 11:14:42 MDT 2009
I currently do incremental backups using --link-dest. Unchanged files
are hard links to the previous snapshot; changed files are new copies.
Where this "fails" is for large files that have received small changes.
The directory containing my main IMAP account, for example, typically
generates between 1 and 2 G of daily backup data as I file messages in my
inbox. Yesterday, though, I filed some old messages in my inbox. This
touched files I don't typically touch. They were minor changes in the
scheme of things, but the result was an 11G backup of that volume last
night.
I was thinking that an alternative to links, which do nothing to preserve
space when small file changes have been made, would be using LVM
snapshots. Instead of creating a new directory for a new backup, and
specifying --link-dest to the previous directory, I'd create a snapshot
of the current backup volume to preserve it, and then do a normal (ie. w/
o --link-dest) rsync to the "live" volume for the new backup.
Has anyone done anything like this? I'm curious about the experiences of
others, pro and con.
I can see one immediate problem: this really only works with a local file
system. On one of our backup servers, for example, the volumes to which
backups are written are mounted via NFS from a file server. So the
backup server has no ability to take snapshots as far as I can see.
Am I missing something?
But I can think of at least one work-around: Switching to iSCSI would
move the file system to the backup server, even if the storage itself
were still remote.
Anything better than this?
For the backup servers that use local storage, though, using LVM
snapshots seems like a decent solution. But I'm worried about managing
"little details", like assuring that there's enough space in the snapshot
to handle the changes to the live volume.
That's why, before I start experimenting, I thought I'd ask what others
have done/tried/abandoned.
Thanks...
Andrew
More information about the rsync
mailing list