>>>>> "jk" == Jerry K <sun.mail.lis...@oryx.cc> writes:
jk> +1
jk> for zfsdump/zfsrestore
-1
I don't think a replacement for the ufsdump/ufsrestore tool is really
needed. From now on, backups just go into Another Zpool.
We need the zfs send stream format commitment (stream format depends
only on zfs version, not on zpool version or kernel version), but
that's enough.
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. The requirement that your backup be staged on a disk
isn't an obstacle in the backup direction: Amanda already has this
requirement. Amanda, when I used it, did *not* have this requirement
in the restore direction so one would have to keep that in mind: if
using tapes, he needs a scratch disk as big as the biggest tape file
on the DR site or the development environment or Compliance Extractor
Station or wherever the restore is happening.
File vdev's have all the wanted characteristics: bitflip resiliency,
checksums, ability to represent all the opaque mysteryfeatures of
inner ZFS's, snapshot/clone efficiency, and importability by future
ZFS kernels ~forever. It still has the all-or-nothing-restore
downside, but maybe we can live with that. Those who can't might
stick to spinning-disk backups.
It might be nice to have a ``read-only vdev'' like a mac os compressed
disk image that can occupy the same pool next to a read-write
vdev---this would be neat for livecd's and incrementals---but it's a
neat feature, not something blocking a frequent/unavoidable sysadmin
task.
What's needed IMHO is non-ZFS-specific tools like tar/pax/cpio/rsync
that understand all this new ACL and opaque-fork garbage that
filesystems are growing (and not just Sun's either). It's needed to
copy between NFSv4 and ZFS, and also to split/combine subdirectories
into separate/common ZFS filesystems without losing any of the
newfangled mysterybaggage. It has as much to do with shaking corner
cases and awkwardnesses out of the newfangled API's as it does with
actually accomplishing a sysadmin task: the best documentation for the
weird appendages in various modern Unix filesystems would probably be
the tool itself, if we had it.
Without this kind of tool and the API shakeout that making it would
require, our systems are slowly turning into shitty Windows boxes that
need some black magic proprietary tool like Ghost or PQDI to capture
all the silly out-of-band garbage their installations depend on and/or
accumulate.
pgpnDeqTYeOuV.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
