[zfs-discuss] Permanent errors in older snapshots

Bjoern Kahl mls at bjoern-kahl.de
Mon Dec 12 17:41:38 EST 2016

 Just a common pitfall to watch out for:

On Mon, Dec 12, 2016 at 02:00:57PM -0800, Håkan Johansson via zfs-discuss wrote:
> On Mon, Dec 12, 2016, at 01:21 PM, devsk wrote:
> > Hakan,
> > 
> > How about I create a clone (C1) from the buggy snapshot (S1), modify it, 
> > create a snapshot (S2) of the clone, create clone (C2) of that snapshot 
> > (S2) and then, delete the original clone (C1), original snapshot (S1) 
> > and clone C2? I will be left with clean snapshot. Will this work?
> > 
> > I think it translates to this: Can I snapshot a clone?
> A clone can be snapshot, but attempting to delete the original snapshot
> requires all dependent clones and snapshots to be deleted first.
> --
> I suppose that you would like to keep some existing old snapshots in the
> ZFS pool, to make use of the fact that share most space with the active
> filesystem and  they only use space for differences?  If the setup is
> not too complicated (many filesystems), this may be a workable approach
> (quite close to restore from backup):
> 1) Create a new pool (of same / larger size), and filesystem(s) on top
> of that.
> 2) rsync the first snapshot you want to keep from the existing (old)
> filesystem to the new pool.
> 3) make a snapshot of the new pool (same name as snapshot just
> transferred).
> 4) repeat 2) and 3) for any further snapshots to keep
> 5) finally rsync the existing filesystem to the new pool
>     (during this time, there shall be no activity on the existing file
>     system)
> The subsequent rsync operations also of course need to --delete files in
> the destination.

 if you go this route, make sure to include the "--inplace" option in all
 rsync calls.  Else rsync would first construct a temporary copy of any
 updated file under a random name, and then unlink the old files and rename
 the new in place.  That essentially voids the whole idea of snapshots
 sharing unchanged data blocks with eachother and the live filesstem, since
 with this default rsync update scheme the updated file and the old file
 are completely independent entities, which just happen to have the same

> I do not know how difficult it is to make rsync ignore the I/O errors it
> get when passing the broken file.

 To my understanding, rsync ignores it while doing the transfer and
 complains afterwards with something like "Some files/attributes could not
 be transfered, see log for details". 


|     Bjoern Kahl   +++   Siegburg   +++    Germany     |
|     "mls at -my-domain-"   +++    www.bjoern-kahl.de     |
| Languages: German, English, Ancient Latin (a bit :-)) |

More information about the zfs-discuss mailing list