2

I've got myself one of these fancy tape drives, HP LTO2 with 200/400 GB cartridges. The st driver reports it like this: 

scsi 1:0:0:0: Sequential-Access HP       Ultrium 2-SCSI   T65D

I can store and retrieve files like a charm using tar, both 

tar cf /dev/st0 somedirectory

and 

tar xf /dev/st0

work flawless.

However, what I really would like to backup are LVM LVs. They contain entire virtual machines with varying partition layouts, so using mount and tar is not an option.

I've tried using something like 

dd if=/dev/VG/LV bs=64k of=/dev/st0

to achieve this, but there seem to be various problems associated with this approach.

Firstly, I would like to be able to store more than 1 LV on a single tape. Now I guess I could seek to concatenate the data on the tape, but I think this would not work very well in an automated scenario with many different LVs of various sizes. Secondly, I would like to store a small XML file along with the raw data that contains some information about the VM contained in the LV.

I could dump everything to a directory and tar it up - not very desirable, I would have to set aside huge amounts of scratch space.

Is there an easier way to achieve this?

Thirdly, from googling around it seems like it would be wise to use something like mbuffer when writing to the tape, to prevent what wikipedia calls "shoe-shining" the tape. However, I can't get anything useful done with mbuffer. The mbuffer man page suggests this for writing to a tape device: 

mbuffer -t -m 10M -p 80 -f -o $TAPE

So I've tried this: 

dd if=/dev/VG/LV | mbuffer -t -m 10M -p 80 -f -d 64k -o /dev/st0

Note the added "-d 64k" to account for the 64k block size of the tape.

However, reading data back from a tape written in this way never seems to yield any useful results - dd has been running for ages now, and managed to transfer only 361M of data from the tape.

What's wrong here?

Aljoscha Vollmerhaus
  • 81
  • 1
  • 3
  • as a more complete solution, have you considered deploying an amanda server ? – Sirex Dec 10 '12 at 04:03
  • Always use a 10k block size when working with tapes unless you're using something exotic - for curmudgeonly historical reasons almost all of them work perfectly this with block size. – Chris S Dec 10 '12 at 04:08
  • Which virtualization technology is in use? KVM? Version of Linux and distribution, please? – ewwhite Dec 10 '12 at 04:18
  • My bad, I've corrected the "shoe-horning". I'm using Gentoo Linux, kernel version 3.5.7 if that matters. I've not considered amanda yet, and from a quick google search it seems like it is a solution that works on file basis, not at the block device level. Virtualization is done through KVM / libvirt. – Aljoscha Vollmerhaus Dec 10 '12 at 04:28
  • 2
    Are you sure you did not intend to use /dev/nst0 anyway? If things have not radically changed since the time I actually used tapes, /dev/st0 will, upon closing, rewind (and block until rewound) the tape to the beginning and overwrite it with the next file sent to it... – rackandboneman Dec 10 '12 at 07:27
  • sounds cool, i was not aware of /dev/nst0. I will see how that works out. However, I don't think it will really help with the issues mentioned above. – Aljoscha Vollmerhaus Dec 11 '12 at 04:36

0 Answers0