Hello all, I need to backup some zpools to tape. I currently have two servers, for the purpose of this conversation we will call them server1 and server2 respectively. Server1, has several zpools which are replicated to a single zpool on server2 through a zfs send/recv script. This part works perfectly. I now need to get this backed up to tape. My origional plan was to have a disk set up which would hold a file based zpool, and then do zfs send/recv to this pool. My problem however is I run into this bug: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6929751 In my case where I reboot the server I cannot get the pool to come back up. It shows UNAVAIL, I have tried to export before reboot and reimport it and have not been successful and I dont like this in the case a power issue of some sort happens. My other option was to mount using lofiadm however I cannot get it to mount on boot, so the same thing happens. Does anyone have any experience with backing up zpools to tape? Please any ideas would be greatly beneficial. Thanks, Greg
>>>>> "gd" == Gregory Durham <gregory.durham at gmail.com> writes:gd> it to mount on boot I do not understand why you have a different at-boot-mounting problem with and without lofiadm: either way it''s your script doing the importing explicitly, right? so just add lofiadm to your script. I guess you were exporting pools explicitly at shutdown because you didn''t trust solaris to unmount the two levels of zfs in the right order? Anyway I would guess it doesn''t matter because my ``back up file zpools to tape'''' suggestion seems to be bogus bad advice. The other bug referenced in the one you quoted, 6915127, seems a lot more disruptive and says there are weird corruption problems with using file vdev''s directly, and then there are deadlock problems with lofiadm from the two layers of zfs that haven''t been ironed out yet. I guess file-based zpools do not work, and we''re back to having no good plan that I can see to back up zpools to tape that preserves dedup, snapshots/clones, NFSv4 acl''s, u.s.w. I assumed they did work because it looked like regression tests people were quoting and many examples depended upon them, but now it seems they don''t, which explains some problems I had last month extracting an s10brand image from a .VDI. :( (iirc i got the image out using lofiadm and just assumed I was confused, banging away at things until they work and then forgetting about them. not good on me.) There is only zfs send which is made with replication in mind ( * it''ll intentionally destroy the entire stream and any incremental descendents if there''s a single bit-flip, which is a good feature to make sure the replication is retried if the copy''s not faithful but a bad feature for tape. If ZFS rallies against other filesystems for their fragile lack of metadata copies and checksums, why should the tape format be so oddly fragile that tape archives become massive gamma gremlin detectors? * and it has no scrub-like method analagous to ''tar t'' or ''cpio -it'' because it''s assumed you''ll always recv it in a situation where you''ve the opportunity to re-send, while a tape is something you might like to validate after transporting it or every few years. If pools need scrubing why don''t tapes? * and no partial-restore feature because it assumes if you don''t have enough space on the destination for the entire dataset you''ll use rsync or cpio or some other tree-granularity tool instead of the replication toolkit. a tool which does not fully exist (sparse files, >4GB files, NFSv4 ACL''s), but that''s a separate problem. ). how about zpools on zvol''s. Does that avoid the deadlock/corruption bugs with file vdevs? It''s not a workaround for the cases in the bug becuase they wanted to use NFS to replace iSCSI, but for backups, zvols might be okay, if they work? It''s certainly possible to write them onto a tape (dd was originally meant for such things). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100309/e1df39cf/attachment.bin>
Thank you for such a thorough look into my issue. As you said, I guess I am down to trying to backup to a zvol and then backing that up to tape. Has anyone tried this solution? I would be very interested to find out. Anyone else with any other solutions? Thanks! Greg -- This message posted from opensolaris.org
> In my case where I reboot the server I cannot get the pool to come > back up. It shows UNAVAIL, I have tried to export before reboot and > reimport it and have not been successful and I dont like this in the > case a power issue of some sort happens. My other option was to mount > using lofiadm however I cannot get it to mount on boot, so the same > thing happens. Does anyone have any experience with backing up zpools > to tape? Please any ideas would be greatly beneficial.I have a similar setup. "zfs send | ssh somehost ''zfs receive''" works perfectly, and the 2nd host is attached to a tape library. I''m running Netbackup on the 2nd host because we could afford it, and then I have an honest-to-goodness support channel. But if you don''t want to spend the money for netbackup, I''ve heard good things about using Amanda or Bacula to get this stuff onto tape. FWIW, since I hate tapes so much, there''s one more thing I''m doing. I use external hard drives, attached to the 2nd server, and periodically "zfs send | zfs receive" from the 2nd server main disks to the 2nd server removable disks. Then export the removable disks, and take ''em offsite in a backup rotation with the tapes. The advantage of the tapes is an official support channel, and much greater archive life. The advantage of the removable disks is that you need no special software to do a restore, and you could just as easily restore a single file or the whole filesystem. So let''s see... I have two different types of offline backup for the backup server, which itself is just a backup of the main server. So I''m feeling pretty well covered. ;-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10.03.2010 18:18, Edward Ned Harvey wrote:> The advantage of the tapes is an official support channel, and much greater > archive life. The advantage of the removable disks is that you need no > special software to do a restore, and you could just as easily restore a > single file or the whole filesystem.There is another advantage as well, but I''ll let you try that one for yourself. - -Make two backups. One to a HDD, one to a modern LTO or similar tape. - -Walk up the stairs to the first floor. - -Open the window. - -Drop both backups onto the ground. - -Try to restore both backups... See any differences in reliability for disasters here? ;) //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein at d80.iso100.no \ / |Solberg ?stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein at jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein at stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail at stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein at jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile at stillbilde.net This mailbox goes directly to my cellphone and is checked even when I''m not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuX92kACgkQSBMQn1jNM7Y+7QCfZx1Nt9qOsnCvOkwnmbXq5Ql5 AS4AoIS+m9F4r9Eowh7tXQK8IYS/N1lr =/kwT -----END PGP SIGNATURE-----
Hey Ed, Thanks for the comment, I have been thinking along the lines of the same thing, I am going to continue to try to use bacula but we will see. Out of curiosity, what version of netbackup are you using? I would love to feel pretty well covered haha. Thanks a lot! Greg On Wed, Mar 10, 2010 at 9:18 AM, Edward Ned Harvey <solaris2 at nedharvey.com> wrote:>> In my case where I reboot the server I cannot get the pool to come >> back up. It shows UNAVAIL, I have tried to export before reboot and >> reimport it and have not been successful and I dont like this in the >> case a power issue of some sort happens. My other option was to mount >> using lofiadm however I cannot get it to mount on boot, so the same >> thing happens. Does anyone have any experience with backing up zpools >> to tape? Please any ideas would be greatly beneficial. > > I have a similar setup. ?"zfs send | ssh somehost ''zfs receive''" works > perfectly, and the 2nd host is attached to a tape library. ?I''m running > Netbackup on the 2nd host because we could afford it, and then I have an > honest-to-goodness support channel. > > But if you don''t want to spend the money for netbackup, I''ve heard good > things about using Amanda or Bacula to get this stuff onto tape. > > FWIW, since I hate tapes so much, there''s one more thing I''m doing. ?I use > external hard drives, attached to the 2nd server, and periodically "zfs send > | zfs receive" from the 2nd server main disks to the 2nd server removable > disks. ?Then export the removable disks, and take ''em offsite in a backup > rotation with the tapes. > > The advantage of the tapes is an official support channel, and much greater > archive life. ?The advantage of the removable disks is that you need no > special software to do a restore, and you could just as easily restore a > single file or the whole filesystem. > > So let''s see... ?I have two different types of offline backup for the backup > server, which itself is just a backup of the main server. ?So I''m feeling > pretty well covered. ?;-) > >
On Wed, March 10, 2010 14:47, Svein Skogen wrote:> On 10.03.2010 18:18, Edward Ned Harvey wrote: >> The advantage of the tapes is an official support channel, and much >> greater >> archive life. The advantage of the removable disks is that you need no >> special software to do a restore, and you could just as easily restore a >> single file or the whole filesystem. > > There is another advantage as well, but I''ll let you try that one for > yourself. > > - -Make two backups. One to a HDD, one to a modern LTO or similar tape. > - -Walk up the stairs to the first floor. > - -Open the window. > - -Drop both backups onto the ground. > - -Try to restore both backups... > > See any differences in reliability for disasters here? > > ;)Slightly OT, but it should also be noted that you need to generally need to put disks in front of most modern tape systems (LTO-3, -4, upcoming -5). It''s a matter of tape being "too fast": LTO-4 = 120 MB/s; LTO-5 = 140 MB/s; LTO-6 = planned 270 MB/s. (Speeds are native, not compressed.) It''s very challenging to stream directly from a client to a tape drive over the network. Most modern backup architectures go to disk first (e.g. VTL), and then clone to tape for longer term storage (or off site) needs. The UER are also better for tapes than disks (though this is mitigated with ZFS'' checksums).
Hey Miles, Do you have any idea if there is a way to backup a zvol in the manner you speak of with bacula? Is DD a secure way to do this or are there better methods to do this? Otherwise I will just use dd. Thanks again! Thanks! Greg -- This message posted from opensolaris.org
Wouldn''t his scripts in the other thread (zfs send plugin for Bacula) work with zvol as well? //Svein -- This message posted from opensolaris.org
Yes it would, however we only have the restore/verify portion. Unless of course I am overlooking something. Thanks, Greg -- This message posted from opensolaris.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12.03.2010 21:34, Greg wrote:> Yes it would, however we only have the restore/verify portion. Unless of course I am overlooking something.I think those can be tweaked further, now that I know Bacula accepts plugins in this fashion (I didn''t know, maybe I should have RTFMmed more). I''ll look into it, as soon as I figure WTF?!? this tapeloader is up to. //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein at d80.iso100.no \ / |Solberg ?stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein at jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein at stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail at stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein at jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile at stillbilde.net This mailbox goes directly to my cellphone and is checked even when I''m not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuapiIACgkQSBMQn1jNM7ZutQCgrBQq11lEjpVNlKUa5mZKkZF4 87UAn0ZNR4tdbVjasBK4cK0ezUHTOvft =9FKv -----END PGP SIGNATURE-----
Greg, I am using NetBackup 6.5.3.1 (7.x is out) with fine results. Nice and fast. -Scott -- This message posted from opensolaris.org