On Thu, Jul 26, 2012 at 10:53 AM, Marcelo Leal <[email protected]> wrote:
> Hi,
>
> A common problem I have experienced (not identified the cause), in an
> incremental send/receive, was that the previous snapshot on the destination
> was not "zero" sized.
> I don't know why the previous snap was retaining some data (a few "K"s),
> if the live filesystem did not changed (believe me ;-).
>
>
The filesystem did change, perhaps due to atime modifications. "zfs diff"
can tell you what changed. You can prevent changes with "zfs set
readonly=on <filesystem>".
> Well, to fix this specific case, you just need to do a "rollback" for the
> previous snapshot on the destination.
> The problem is that the incremental send does not complain on the
> begining of the process, but just after a random time.
> If you have a big incremental stream to send, can be really annoying.
>
Rather than explicitly rolling back, use "zfs receive -F". This will
ensure that the receive does not fail even if you modify the filesystem in
the middle of the receive. As the manpage says:
-F
Force a rollback of the file system to the most
recent snapshot before performing the receive opera-
tion. If receiving an incremental replication stream
(for example, one generated by zfs send -R -[iI]),
destroy snapshots and file systems that do not exist
on the sending side.
--matt
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
