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