Solved Tape backup strategy question using dd and a zpool

[big_girl]

Hello,

I was thinking about borrowing an LTO-5 tape drive, which has an uncompressed capacity of 1.5TB, in order to make some backups. I was wondering if this backup strategy should work-

1) Take two 2TB disks and create a 1.5TB partition on each (b/c I have the 2TB disks already).
2) Use geli to init the 1.5TB partitions.
3) Create a zfs mirror from those 2 partitions.
4) Fill the mirror with data to back up.
5) Use dd to copy the block range that holds the geli partition to the tape drive.

I was wondering if this could give the benefits of encryption and also data integrity to the tape backups?

Thanks for any thoughts,
-bg

 

[SirDice]

I wouldn't use dd(1). Create a snapshot and use zfs send to create a file. This file can be encrypted and/or compressed if you want. Then stream it to tape. Using dd(1) is going to cause issues if the destination disk is a different size. You'd also need to dd(1) both disks as there's no single device.

 

[cpm@]

Besides SirDice's tip, I recommend to read this article written by Akira Ohsone for a better approach

 

[big_girl]

Thanks very much for the thoughtful replies.

Using dd(1) is going to cause issues if the destination disk is a different size.

Only if the destination disk isn't big enough; otherwise I should be able to just dd(1) out the tape back to any disk that is bigger than the tape, right? So if I partition a volume that is 1.5TB I should be able to dump it to a 1.5TB tape and back to any disk bigger than 1.5TB(?)

You'd also need to dd(1) both disks as there's no single device.

That is true, but at least this way, using an extra tape, I would be able to correct errors.

My other concern is that encrypting a stream (e.g. via AES-CBC) on the fly is not as efficient space-wise as a GELI volume. Regardless, I'll probably do what you recommended, but was thinking about some other ideas.

Thanks again for the comments.

 

[freebuser]

Hi,

I am trying to adapt this to my situations, but I have two pools (tank1 and tank2).

How can I send both snapshots continuously to tape, as my tape has more capacity than both pools combined:
# zfs send -R tank1@backup | dd of=/dev/sa0 obs=64k

Thanks

 

[wblock@]

# zfs send -R tank1@backup | dd of=/dev/sa0 obs=64k

What is the reason to use dd(1) there at all? Seems like zfs send -R tank1@backup > /dev/sa0 would be fine. If it is a buffering issue, there are other buffering programs that would probably be better.

mt(1) can help to control the tape drive, so you can write multiple files to it. Be warned that any home-developed backup system like this is a pain. Bigger systems like Bacula have the advantage of more power and testing, both of which take a long time to develop.

 

[big_girl]

Hi,

I am trying to adapt this to my situations, but I have two pools (tank1 and tank2).

How can I send both snapshots continuously to tape, as my tape has more capacity than both pools combined:
# zfs send -R tank1@backup | dd of=/dev/sa0 obs=64k

Thanks

I've not done it, but it is my understanding that you can send multiple snapshots at once, e.g.

# zfs send -R tank1@backup tank2@backup | ...

 

[freebuser]

What is the reason to use dd(1) there at all? Seems like zfs send -R tank1@backup > /dev/sa0 would be fine. If it is a buffering issue, there are other buffering programs that would probably be better.

mt(1) can help to control the tape drive, so you can write multiple files to it. Be warned that any home-developed backup system like this is a pain. Bigger systems like Bacula have the advantage of more power and testing, both of which take a long time to develop.

1. zfs send -R tank1@backup > /dev/sa0 didn't work on my system, I believe due to blocksize different, so I am using dd(1).

2. I believe using /dev/nsa0 solve the issue of continuous writing

3. Bacula seems to be an overkill for a homeserver. I used to use tar(1) with mbuffer() but found out that zfs send with dd nearly writing at 73MB/s where tar(1) used to write at 53MB/s.

I had several times restored from tar(1) archive so fairly happy with the reliability. But is there anyway I can check the zfs recv part?

for eg. is it possible to destroy the snapshot data@today and do a dd if=/dev/nsa0 ibs=64k | zfs recv data@today , will this replace my snapshot or the current files in the pool?