[zfs-discuss] Tape backup of ZFS data streams?

Wieck, Owen Owen.Wieck at ricardo.com
Fri Feb 26 14:06:58 EST 2016


Fully agree, it's not an efficient means to do file recoveries (although online zfs snapshots aren't bad, see further in).  We still run incremental file-level backups for user file recoveries (not to be confused with DR).  But in practice, if the needed tape is not in the changer, we often use the online zfs snapshots for user file recovery.  It's a long walk from our office to the fireproof safe, to the server room and back again.

In the dawn of time before Virtualization and ZFS snapshot technology were available to the 99%, we used file-level (full) backups for DR and bare metal recovery of servers as well.  And OMG did it suck.  It never worked correctly for Windows servers, marginally better for *nix.  And that was using "Enterprise-Grade" backup software.  Much better now, and as an added bonus the "zfs send" stream backups are faster than file level backups!

--O

P.S.:  If anyone is interested I have some Networker-specific notes / horrible hack scripts I'm willing to share.

-----Original Message-----
From: Chris Siebenmann [mailto:cks at cs.toronto.edu]
Sent: Friday, February 26, 2016 1:28 PM
To: zfs-discuss at list.zfsonlinux.org; Wieck, Owen <Owen.Wieck at ricardo.com>
Cc: cks at cs.toronto.edu
Subject: Re: [zfs-discuss] Tape backup of ZFS data streams?

> I have to call shenanigans on the tape nay-sayers. ;-)
>
> There's a reason that tape backup has been used for literally decades.
> It's inexpensive (especially for DR) and it works (if properly
> maintained).

 To be clear: I fully support backups to tape or something tape-like[*].
Offline backups with multiple (redundant) copies of your data are an excellent idea for recovery from disasters small and large, and disasters happen. I just think you should consider carefully before using 'zfs send' streams as your storage format on tape. It may meet your needs, but it also may not.

 For example, here our most common go-to-backups requests are for restoring individual files or small collections of files that have been deleted by users. Given that you can't restore single files from zfs send streams, this would make them a terrible format for us apart from any other considerations. If we had a policy that we didn't do restores for single files (as some places do), this wouldn't be an issue.

(We can't use ZFS snapshots on the live pools for this in general because space usage in them is a real issue.)

- cks
[*: The actual economics may make using disks as your 'tapes' more
    attractive than actual tapes for *backups* (not archives), but
    that's another discussion.  Roughly speaking, tapes have higher
    up-front costs for the tape drives and robots but lower per-unit
    costs for the tapes.
    For archives, where long-term readability is important, there are
    other considerations that probably tilt strongly towards (some)
    tapes. But I would definitely suggest against using 'zfs send'
    streams for archival purposes; you really want a format that is
    better documented and easier to read.
]
--------------------------------------------------------------------------------------------------------------------------------------------------------------
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those
of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Ricardo's
authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and
other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and
any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail.
"Ricardo" means Ricardo Inc. and its affiliated companies.
--------------------------------------------------------------------------------------------------------------------------------------------------------------'.


More information about the zfs-discuss mailing list