Strategy for using snapshots to back up Ubuntu Linux server?
- by MountainX
I need some backup advice for my home file server. Here are the mount points, volume groups, logical volumes and used/total space of all the volumes on my Ubuntu 8.10 home file server.
/ vgA/lvRoot [7.5G/50G]
/tmp vgB/lvTmp [195M/30G]
/var vgB/lvVar [780M/30G]
swap vgB/lvSwap [16.00 GB]
/media1 vgC/lvMedia1 [400G/975G]
/media2 vgC/lvMedia2 [75G/295G]
/boot partition (no volume group) [95M/200M]
/video partition (no volume group) [450G/950G]
/backups vgD/lvBackupTarget [800G/925G]
/home vgE/lvHome [85G/200G]
I have just added a 2.0 TB external USB drive that I would like to use to backup everything. (It will be a close fit to get it all on one 2.0 TB drive. I actually have a 2nd external USB drive if needed.) I'd like to backup "/", var, /media1, media2 and /home. I'll deal with /boot and /video separately since they are not logical volumes.
For all the logical volumes I'm anticipating taking snapshots and then copying those snapshots to the 2.0 TB external USB drive. I have never done a task like that before. If I do that, I could use the tutorial I found here:
http://www.howtoforge.com/linux_lvm_snapshots
My questions are:
What is the best overall strategy? Is it LVM snapshots, as I'm assuming?
How should I prepare, subdivide and mount the 2.0 TB external USB drive?
2.a. Should I create one or more regular partitions or should I create a physical volume with one or more logical volumes?
2.b. Would it be advisable to extactly mirror the source pv/lv layout on the external drive, and if so, is this a good strategy?
What's the best way to get the snapshots onto the external drive? dd?
Even though this is a strategy question, feedback with actual commands is appreciated. I need step-by-step cookbook-style help because I don't do much server admin work.
(Background: This is a home file server that I have rarely had to touch in about 2 years. It has done its job without much intervention. The really old PC that I used to back everything up recently failed, so I'm replacing that with the external USB drive(s) and I'd like to upgrade my backup strategy at the same time. Previously, I just copied stuff from /backups over to the other computer and that would not have made things very easy in a real restore situation. The /backups mount point contains backup copies of "most" of the important data on a file by file basis, but it does not contain copies of /boot, etc. BTW, the actual internal HDD that holds /backups is separate from the other storage devices.)
EDIT: I'll propose a strategy...
The idea came from a comment here:
LVM mirroring VS RAID1
"LVM mirrors are for replication of a logical volume to a different physical volume. It's essentially meant to "move the data to a different disk". The mirror is then broken..."
That would fit my requirements well. Here is an ideal situation:
establish the LV mirror on the external drive
break the link with the mirror
create a (persistent) snapshot on the mirror
after a week, resync the mirror with the original source and update the mirror
break the link and create another snapshot on the mirror.
Obviously, the mirror will be like a weekly full backup. And the snapshots on the mirror will represent earlier points in time.
If this would work and if it would be time efficient, it would give a nice full & differential type backup on the external drive based on LVM. I have not heard of a strategy like this before. Will it work? Could it be scripted? Thoughts?
EDIT 2: Creating Portable DiskSafes With LoopbackFS And LVM Snapshots
This article seems intriguing:
http://www.howtoforge.com/creating-portable-disksafes-with-loopbackfs-and-lvm-snapshots
Unfortunately, I don't understand exactly how to map those ideas to the strategy I'm proposing above. I'm going to ask this last bit as a separate question. I will leave my original question in place because I still desire feedback on the overall best strategy. At this moment I'm assuming it is LVM mirroring in the style of "Creating Portable DiskSafes with LVM Snapshots" but that might be wrong.
