On 10-Aug-10 13:46, 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.)
More information. The test I started this morning errored out somewhat
similarly, and one set of errors is clearly deleted snapshots (they're
2hr snapshots that some of get deleted every 2 hours). There are also
errors relating to "incremental streams" which is strange since I'm not
using -I or -i at all.
Here are the commands again, and all the output.
+ zfs create -p bup-wrack/fsfs/zp1
+ zfs send -Rp z...@bup-20100810-154542gmt
+ zfs recv -Fud bup-wrack/fsfs/zp1
warning: cannot send 'zp1/d...@bup-2hr-20100731-120000cdt': no such pool
or dataset
warning: cannot send 'zp1/d...@bup-2hr-20100731-140000cdt': no such pool
or dataset
warning: cannot send 'zp1/d...@bup-2hr-20100731-160000cdt': no such pool
or dataset
warning: cannot send 'zp1/d...@bup-20100731-213303gmt': incremental
source (@bup-2hr-20100731-160000CDT) does not exist
warning: cannot send 'zp1/d...@bup-2hr-20100731-180000cdt': no such pool
or dataset
warning: cannot send 'zp1/d...@bup-2hr-20100731-200000cdt': incremental
source (@bup-2hr-20100731-180000CDT) does not exist
cannot receive incremental stream: most recent snapshot of
bup-wrack/fsfs/zp1/ddb does not
match incremental source
Afterward,
bash-4.0$ zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
bup-wrack 928G 687G 241G 73% 1.00x ONLINE /backups/bup-wrack
rpool 149G 10.0G 139G 6% 1.00x ONLINE -
zp1 1.09T 743G 373G 66% 1.00x ONLINE -
So quite a lot did get transferred; but not all.
So, it appears clear that snapshots being deleted during the zfs send -R
causes a warning. A warning is fine, since they're not there it can't
send them, and they were there when the command was given so it makes
sense for it to try.
That last message, which is not tagged as either warning or error,
worries me though. And wondering how complete the transfer is; I
believe the backup copy is compressed whereas the zp1 copy isn't, so the
ALLOC being that different isn't clear-cut evidence of anything.
I'll try to guess a few things that should be recent and see if they in
fact got into the backup.
--
David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
