David Dyer-Bennet wrote:
On Tue, August 10, 2010 13:23, Dave Pacheco wrote:
David Dyer-Bennet wrote:
My full backup still doesn't complete. However, instead of hanging the
entire disk subsystem as it did on 111b, it now issues error messages.
Errors at the end.
[...]
cannot receive incremental stream: most recent snapshot of
bup-wrack/fsfs/zp1/ddb does not
match incremental source
bash-4.0$
The bup-wrack pool was newly-created, empty, before this backup started.
The backup commands were:
zfs send -Rv "$srcsnap" | zfs recv -Fudv "$BUPPOOL/$HOSTNAME/$FS"
I don't see how anything could be creating snapshots on bup-wrack while
this was running. That pool is not normally mounted (it's on a single
external USB drive, I plug it in for backups). My script for doing
regular snapshots of zp1 and rpool doesn't reference any of the bup-*
pools.
I don't see how this snapshot mismatch can be coming from anything but
the
send/receive process.
There are quite a lot of snapshots; dailys for some months, 2-hour ones
for a couple of weeks. Most of them are empty or tiny.
Next time I will try WITHOUT -v on both ends, and arrange to capture the
expanded version of the command with all the variables filled in, but I
don't expect any different outcome.
Any other ideas?
Is it possible that snapshots were renamed on the sending pool during
the send operation?
I don't have any scripts that rename a snapshot (in fact I didn't know it
was possible until just now), and I don't have other users with permission
to make snapshots (either delegated or by root access). I'm not using the
Sun auto-snapshot thing, I've got a much-simpler script of my own (hence I
know what it does). So I don't at the moment see how one would be getting
renamed.
It's possible that a snapshot was *deleted* on the sending pool during the
send operation, however. Also that snapshots were created (however, a
newly created one would be after the one specified in the zfs send -R, and
hence should be irrelevant). (In fact it's certain that snapshots were
created and I'm nearly certain of deleted.)
If that turns out to be the problem, that'll be annoying to work around
(I'm making snapshots every two hours and deleting them after a couple of
weeks). Locks between admin scripts rarely end well, in my experience.
But at least I'd know what I had to work around.
Am I looking for too much here? I *thought* I was doing something that
should be simple and basic and frequently used nearly everywhere, and
hence certain to work. "What could go wrong?", I thought :-). If I'm
doing something inherently dicey I can try to find a way to back off; as
my primary backup process, this needs to be rock-solid.
It's certainly a reasonable thing to do and it should work. There have
been a few problems around deleting and renaming snapshots as they're
being sent, but the delete issues were fixed in build 123 by having
zfs_send hold snapshots being sent (as long as you've upgraded your pool
past version 18), and it sounds like you're not doing renames, so your
problem may be unrelated.
-- Dave
--
David Pacheco, Sun Microsystems Fishworks. http://blogs.sun.com/dap/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
