On Jan 19, 2010, at 4:26 PM, Allen Eastwood wrote:
>> Message: 3
>> Date: Tue, 19 Jan 2010 15:48:52 -0500
>> From: Miles Nordin <car...@ivy.net>
>> To: zfs-discuss@opensolaris.org
>> Subject: Re: [zfs-discuss] zfs send/receive as backup - reliability?
>> Message-ID: <oqpr55lt1n....@castrovalva.ivy.net>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> 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.
>
>
> While this idea may be fine for a home user…those us of who have customers in
> the enterprise still have a need for tape backups.
>
> And some of those enterprises require backup mechanism that can be easily
> used in a DR situation.
>
> ufsdump/restore was perfect in that regard. The lack of equivalent
> functionality is a big problem for the situations where this functionality is
> a business requirement.
How quickly we forget ufsdump's limitations :-). For example, it is not
supported
for use on an active file system (known data corruption possibility) and
UFS snapshots are, well, a poor hack and often not usable for backups.
As the ufsdump(1m) manpage says,
The ufsdump command can only be used on unmounted file sys-
tems, or those mounted read-only. Attempting to dump a
mounted, read-write file system might result in a system
disruption or the inability to restore files from the dump.
Consider using the fssnap(1M) command to create a file sys-
tem snapshot if you need a point-in-time image of a file
system that is mounted.
So, if you are taking ufsdumps of an active file system for business
requirements,
then perhaps you should rethink the solution.
> For example, one customer, local government, requires a backup that can be
> taken offsite and used in a DR situation. They have 2 sun servers. They
> have very little Solaris knowledge. So whatever I provide them has to be easy
> and easily documented. Lack of "zfsdump/restore" means I either have to
> forgo moving them to ZFS root, or have to add in a third party
> application…like I'm really going to meet their requirements with Amanda or
> Backula…
Many people use send/recv or AVS for disaster recovery on the inexpensive
side. Obviously, enterprise backup systems also provide DR capabilities.
Since ZFS has snapshots that actually work, and you can use send/receive
or other backup solutions on snapshots, I assert the "problem" is low priority.
> This lack in Solaris is just plain ludicrous to at least some parts of the
> business/enterprise world.
Methinks you never read the ufsdump man page? :-)
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
