From owner-freebsd-fs@FreeBSD.ORG Tue Mar 10 11:02:37 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90DF2CA3 for ; Tue, 10 Mar 2015 11:02:37 +0000 (UTC) Received: from mx.tetcu.info (mx.tetcu.info [217.19.15.179]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9C587D for ; Tue, 10 Mar 2015 11:02:37 +0000 (UTC) Received: from localhost (f1e.forteasig.com [81.181.146.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.tetcu.info (Postfix) with ESMTPSA id A698C2BFEF7 for ; Tue, 10 Mar 2015 13:01:13 +0200 (EET) Date: Tue, 10 Mar 2015 12:55:28 +0200 From: Ion-Mihai Tetcu To: freebsd-fs@FreeBSD.org Subject: Recovering zfs send | recv Message-ID: <20150310125528.000025b2@FreeBSD.org> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 11:02:37 -0000 Hi, Is there a way to "recover" from deleting a filesystem on the receiving side (also deleted on the sending side) so that replication can go on without receive -F? Now it fails with 'Filesystem modified since most recent snapshot'. I have no problem with rolling back (destroying) some last snapshots on the receiving side, but I can't use -F because it would remove about a year of "archived" snapshots that are no longer present on the sending side (where only the snapshots from the last 4 months are kept, mostly for space and performance reason - recursive snaps are being created each 10 minutes and their "archive" on the receving side currently numbers about 400.000 snaps.). On the sending side: pool/fs@s1 pool/fs/sfsA@s1 pool/fs/sfsB@s1 pool/fs/sfsD@s1 pool/fs@s2 pool/fs/sfsA@s2 pool/fs/sfsB@s2 pool/fs/sfsD@s2 <--- moment in time when 'zfs destroy -r pool/fs/sfsC' pool/fs@s3 pool/fs/sfsA@s3 pool/fs/sfsB@s3 pool/fs/sfsD@s3 pool/fs@s4 pool/fs/sfsA@s4 pool/fs/sfsB@s4 pool/fs/sfsD@s4 On the receiving side: BK/pool/fs@s1 BK/pool/fs/sfsA@s1 BK/pool/fs/sfsB@s1 BK/pool/fs/sfsD@s1 BK/pool/fs@s2 BK/pool/fs/sfsA@s2 BK/pool/fs/sfsB@s2 BK/pool/fs/sfsD@s2 <--- moment in time when 'zfs destroy -r BK/pool/fs/sfsC' zfs send -R -I pool/fs@s1 poll/fs@s2 | zfs receive -v -d BK works zfs send -R -I pool/fs@s2 poll/fs@s3 | zfs receive -v -d BK doens't In the worse case I could send | recv the child filesystems sfsA, sfsB, etc. (with I know it works) but given their number (and rather frequent zfs rename'ing of them on the sending side) it would be rather inconvenient. And, if it is not possible, what is the correct way of removing a filesystem on both sides that would allow replication to continue? Thanks, -- IOnut