>>>>> "ae" == Allen Eastwood <mi...@paconet.us> writes: >>>>> "ic" == Ian Collins <i...@ianshome.com> writes:
>> If people are really still backing up to tapes or DVD's, just
>> use file vdev's, export the pool, and then copy the unmounted
>> vdev onto the tape or DVD.
ae> And some of those enterprises require backup mechanism that
ae> can be easily used in a DR situation.
ae> ufsdump/restore was perfect in that regard. The lack of
ae> equivalent functionality is a big problem for the situations
ae> where this functionality is a business requirement.
ae> For example, one customer, local government, requires a backup
ae> that can be taken offsite and used in a DR situation.
Were you confused by some part of:
Use file vdevs, epxort the pool, and then copy the unmounted vdev
onto the tape.
or do you find that this doesn't do what you want? because it seems
fine to me. And the fact that it doesn't need any extra tools means
it's unlikely to break (1) far into the future or (2) for a few
unlucky builds, and (3) that the restore environment is simple and
doesn't involve prepopulating some Legato Database with the TOC of
every tape in the library or some such nonsense, which ought to all be
among your ``requirements'' but if you're substituting for those,
``works in exactly the way we were used to it working before'' then
you may as well use 'zfs send' since you're more concerned with
identical-feeling invocatoin syntax than the problems I mentioned.
ic> For a full recovery, you can archive a send stream and receive
ic> it back.
You can send the stream to the tape, transport the tape to the DR
site, and receive it. You can do this weekly as part of your offsite
backup plan provided that you receive each tape you transport
immediately. Then the data should be permanently stored on disk at
the DR site, and the tapes used only for transport.
If you store the backup permanently on tape then it's a step backwards
from tar/cpio/ufsrestore because the 'zfs send' format is more fragile
and has to be restored entire. If you receive the tape immediately
this is an improvement because under the old convention tapes could be
damaged in transit, or over the years by heat/dust/sunlight, without
your knowledge, while on disks it's simple to scrub periodically.
I am not trying to take away your tapes, Allen, so please quote Ian
instead if that's the thing you object to. I've instead suggested a
different way to use them if you really do need them archivally: store
file vdev's on them. If you're just using them to replicate data to
the DR site then you needn't even go as far as my workaround.
I do agree that there's a missing tool: it's not possible to copy one
subdirectory to another while preserving holes, forkey extended
attributes, and ACL's. Also if Windows ACL's are going to be stored
right in the filesystem, then Windows ACL's probably ought to be
preserved over an rsync pipe between Solaris and EnTee, or a
futuristic tarball written on one and extracted on the other. I don't
agree that the missing tool is designed primarily for the narrow
use-case of writing to ancient backup tapes: it's a more general tool.
or, really, it's just a matter of documenting and committing the
extra-OOB-gunk APIs and then fixing rsync and GNUtar.
pgpk5wk2koJcZ.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
