4

I'd like to make backup on external drive of LVM2 logical volume in dd manner.

Approach I consider is to

  • make lv on external drive with identical size
  • copy with dd

(Please let me know if you see something really wrong in such approach. I need something reliable and fast.)

I would like to automate the whole process; this is what I have:

# Sanity check that lv is not used
lvuses="$( lvdisplay -c /dev/mapper/vgA-AA | cut -d ':' -f 6 )"
if [ $lvuses -gt 0 ]; then exit 1 ; fi
#obtain lv size (in sectors)
lvsize="$( lvdisplay -c /dev/mapper/vgA-AA | cut -d ':' -f 7 )"
#create destination
lvcreate -L "${lvsize}s" vgB -n BB || exit 1
# copy
dd if=/dev/mapper/vgA-AA of=/dev/mapper/vgB-BB

Is it all right? Have I missed something?

(In my case vgA-AA is LVM snapshot and I would like to backup it to external drive and take this drive to other geographical location)

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
Grzegorz Wierzowiecki
  • 14,264

4 Answers4

4

Your script looks fine, but I'd use a different approach: create a mirror, then break it. You can do this online, as far as I know. Untested:

lvconvert -m /dev/mapper/vgA-AA /dev/sdz98 /dev/sdz99
lvconvert --splitmirrors 1 --name BB /dev/mapper/vgA-AA

If you want to move the new logical volume to a different volume group, I think you have to ensure that the LV you want to send over is on its own physical volume(s), and transfer the PV(s) from one VG to the other with vgsplit.

Gilles 'SO- stop being evil'
  • 829,060
  • Sounds like nice approach. Disadvantage is that I would have to put those PV into one VG, but sounds ok. On think makes me scared: articles like this on internet "LVM2 mirroring - how it is broken" I hope it's outdated. – Grzegorz Wierzowiecki Mar 23 '12 at 09:26
  • 1
    @GrzegorzWierzowiecki, it's not out of date. Also after splitting like that, since both volumes will have the same UUID, the system won't know which one to mount, so when you reboot the wrong one may be mounted. – psusi Mar 25 '12 at 14:57
  • 2
    @psusi For a backup, conserving the UUID is arguably the correct thing to do. This is a problem if you use the UUID in fstab and the backup is visible at boot time; but with LVM there's little reason to use the UUID instead of the LVM volume path in fstab. – Gilles 'SO- stop being evil' Mar 26 '12 at 18:18
2

Don't use dd. It is a dumb animal that will copy everything in the volume, including the free space, and result in a filesystem with the same UUID as the original, which can confuse the system. Instead, use a tool like partclone or ghost4linux or fsarchiver that can copy the system to a compressed image file and skip the free blocks.

psusi
  • 17,303
  • Thanks for tips. I know about partimage, fsarchiver etc. The advantage of dd is that is rock solid and fast as harddrives+filesystems are (or just harddrives+LVM2 in our case) – Grzegorz Wierzowiecki Mar 23 '12 at 09:06
  • 1
    @GrzegorzWierzowiecki, the smart tools are faster since they don't waste time copying all of the free space. You might also look at dump, which is a more proper backup solution that is not only very fast, but capable of incremental backup/restore. – psusi Mar 23 '12 at 14:28
  • Identical UUID is intentional. I'd like to recover partitions with their original data and meta-data (like UUIDs). However, in general case, you're recommendations are all right. I believe other users will profit from mentioned tools. – Grzegorz Wierzowiecki Mar 24 '12 at 02:02
  • Btw. dump seems to be file level, not partition level... – Grzegorz Wierzowiecki Mar 24 '12 at 02:02
  • @GrzegorzWierzowiecki, no, it is filesystem level. It opens the block device directly without it being mounted and interprets the filesystem itself to figure out what needs backed up. This allows it to avoid backing up useless free space, and be very fast both at full and incremental backups. Also while you may want to preserve the UUID when restoring the fs, having two volumes online at the same time with the same UUID will confuse the system, which is why you want the backup in an image file not another logical volume. – psusi Mar 25 '12 at 14:48
  • Thanks you for advices. What about UUIDs, I work on /dev/mapper/... paths and find it works even UUIDs are same. AFAIK LVM2 has nothing to UUIDs, cause those are different layers of abstraction. Even thou, advice is usefull for other readers, cause some might like to work on UUIDs. – Grzegorz Wierzowiecki Mar 25 '12 at 18:44
2
  • mount external disk
  • stop the application
  • check if the file system is unused ($ sudo fuser -M /path/to/filesystem/mountpoint)
  • create snapshot ($ sudo lvcreate -s ........... )
  • start application
  • backup using rsync (check man rsync for --update and --link-dest)
  • or check http://dirvish.org or http://backuppc.sourceforge.net/ for implementations
  • umount external disk
  • remove snapshot LV This procedure creates a directory on the external disk per backup. It only copies changed/new files from the source disk ànd it saves space by hardlinking duplicate files between backups.
jippie
  • 14,086
1

Reliable and fast. I would recommend LVM snapshots.

It is extremely fast and you can guarantee that the backup will happen without any file changes happening during the backup. Also, should you have a database on the volume you won't have to take it offline.

This is also a good way to test changes to your volume. Snapshot it, make your changes, they fail you merge the snapshot back. If they succeed you delete the snapshot.

Edit: Code

lvcreate -L 10G -s -n snapshot /dev/VG/LV

Then backup the snapshot volume to wherever you want however you want.

For filesystem testing you can snapshot and merge back.

lvconvert --merge /dev/VG/snapshot

This merge will auto-delete the snapshot volume.

Note: snapshots require kernel version 2.6.33 or newer and LVM tools 2.02.58 or newer

Edit. Links:

TLDP: Taking a Backup Using Snapshots

HowtoForge: Back Up and Restore Partitions Using LVM Snapshots

Cyberciti: Consistent Backup with LVM Snapshots

2bc
  • 3,978
  • Actuaklly , I would like to make backup of LVM snapshot to external drive. LVM snapshot is not making bakup, but snapshot ! – Grzegorz Wierzowiecki Mar 23 '12 at 09:07
  • @Grzegorz Wierzowiecki - Right, but once the snapshot is taken you mount it and that is what you back up. Snapshots are extremely fast and in some cases instantaneous. You can script the snap and the backup of the snapshot copy just like you would a backup of the original volume. – 2bc Mar 23 '12 at 10:06
  • @GrzegorzWierzowiecki - added links – 2bc Mar 23 '12 at 10:10
  • I know it and it's not what I was asking for. I use LVM2 snapshots a while and my question is about how to make backup of them to external drive. – Grzegorz Wierzowiecki Mar 24 '12 at 01:59