zfs send -R | zfs recv aborted
Derek (freebsd lists)
482254ac at razorfever.net
Wed Jul 19 10:21:15 UTC 2017
On 17-07-18 05:19 PM, Frank Leonhardt wrote:
> On 18/07/2017 11:02, Derek (freebsd lists) wrote:
>> Thanks for the response. Sorry I wasn't clear - those options
>> aren't available in 10.2 - and this is the upgrade path for
>> this machine (i.e. migrate to a new one).
>> Other thoughts still welcome.
> I'm not 100% sure that datasets that appear to be good on a
> failed send will be safe; I presume you've checked!
> So your problem is that you need to free up broken dataset
> snapshots on the receiver. I don't understand why this is a
> problem - why not just "destroy" them?
And here, you've gotten to the heart of the matter. Perhaps the
questions I mean to be asking are:
- How can I tell which datasets/snapshots were received in-tact,
and which are only partial transfers? (I *presume* some are
in-tact, and they superficially appear to be so.)
- Can this be done using only properties/metadata of the zfs
dataset + pool? (like a receive completed flag)
> You might want to consider a differential "send" (with a -I
> (capital i) ) option, which will send the snapshot plus all the
> missing intermediate ones.
I tried this route, and it just spun the CPU for a day - perhaps
meaningful output was coming, just not then.
> I've a dim idea that zxfer might be of some help here, but as you
> say, the OpenZFS from 10.3 onwards has exactly the option you need.
That's a good point. I'll look there for some inspiration - and
see how deep it goes.
> Am I right in thinking these two machines are colocated? Why not
> just export the pool on one and import on the other? (Lack of
> drive bays being one obvious reason - just get a load of
> USB->SATA cables and a hub). Just a thought.
The source machine is active in service.
Thanks for that!
More information about the freebsd-questions