On Thu, Mar 24, 2011 at 7:07 AM, Edward Ned Harvey
<opensolarisisdeadlongliveopensola...@nedharvey.com> wrote:
> When you have a backup server, which does nothing but zfs receive, that's
> probably your best case scenario. Because the data is as nonvolatile as
> possible. But indeed, because all the sends are incremental, fragmentation
> will accumulate. If you want to eliminate it once, but not once and for
> all, then you'll have to occasionally do a full receive instead of
> incremental. If you're more than 50% utilized on the receiving pool, you'll
> have to zfs destroy or zpool destroy everything on the receiving end prior
> to doing the full receive. (zpool destroy is instant, while zfs destroy
> will take a long time). So you pay something in terms of increased
> temporary risk. Or add enough disks to do a full receive without destroying
> first - in which case you pay something in terms of additional hardware.
Unfortunately, capacity is not the limiting factor in some cases.
In my case we do not have the bandwidth to do a FULL send/recv, it
would take weeks. Part of the reason we adopted using zfs send/recv to
accomplish our offsite copies is that once the initial FULL is done
(and we start that when the zpools are almost empty), we can keep up
with incrementals. The data is mostly static and not growing that
fast.
The combination of zfs snapshots and the offsite copy provide all
the backup capability we need. The snapshots provide day to day
operation backups for the occasional "we corrupted that file and need
to get it back from last Wednesday" and the DR protection against
complete loss of the data. We can point the users at the backup copy
across the WAN, and while not as fast, they at least have access to
the data. Then we can do a reverse replication (including a local FULL
and then ship the storage to the other location).
Ahhh, for an online defragment function.
--
{--------1---------2---------3---------4---------5---------6---------7---------}
Paul Kraus
-> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
-> Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
-> Technical Advisor, RPI Players
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
