From owner-freebsd-fs@FreeBSD.ORG Mon Jan 5 20:45:39 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 BC58FCA7 for ; Mon, 5 Jan 2015 20:45:39 +0000 (UTC) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77BE52B8A for ; Mon, 5 Jan 2015 20:45:39 +0000 (UTC) Received: by mail-yk0-f172.google.com with SMTP id 131so10653125ykp.31 for ; Mon, 05 Jan 2015 12:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eU8YY3OAa1lZyL5yEXIqrmVxwbRO7TsWYshc4D3tuPI=; b=MtH9Ja8Wy22fKfgyKFZflNNTQfEN63PWueB9YgwHG4HMMqHK82HMbSQygzEO4sfPvl z9C2PVOGPvO5NOi5WSmuajOgtYVwTfmDBL6A8PUhQgrIstFhYvW9F0Y1FyiuPtAwVzRu 3P962oVPo75/SplqZc7fG6VTcH8O4f3F02L5cXJ7fw//bORqpM3YL7EzyxG4YQ0d+S1Q y3lIfYq1l1JUjdVPHj0HINv7Er1atXOq60X6liHMXSS01qeKofTBKwwWjNtaEjxq+kqq AY+8/mjtr5SDOhTiY1in8uniZCZ5cAbSHUGDE5t02Lbv6r6oaNUKqKsYo/M/mmJx6a1E 0/bA== MIME-Version: 1.0 X-Received: by 10.236.40.14 with SMTP id e14mr61102273yhb.81.1420490738683; Mon, 05 Jan 2015 12:45:38 -0800 (PST) Received: by 10.170.48.136 with HTTP; Mon, 5 Jan 2015 12:45:38 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Jan 2015 14:45:38 -0600 Message-ID: Subject: Re: ZFS Send / Receive Recursively Without Properties From: "Eric A. Borisch" To: Tim Gustafson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-fs@freebsd.org" 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: Mon, 05 Jan 2015 20:45:39 -0000 On Monday, January 5, 2015, Tim Gustafson wrote: > > If I drop the -R parameter to ZFS send, then it does not overwrite the > mountpoints, but it also does not destroy the non-existent snapshots > on the server "B". Snapshots on server "A" are automatically > destroyed by a script after 7 days, and we don't want to accumulate > snapshots on server "B" that have been destroyed from server "A". We > also would prefer to not run a snapshot purging script on server "B" > because ultimately this solution will be used for multiple source > servers, and each of them have different snapshot retention policies > that I'd like to not have to maintain in two separate places. > I was doing this too, until I realized that an accidental (fat fingered) removal of file systems/snapshots on the source side then flows through to remove it on the backup side as well. Granted, you may want the removal to happen on both sides, but for my tastes, removals of whole file systems on the backup shouldn't happen without user interaction. This concern led me to avoid -R for automated transfers, and necessitated a snapshot expiry script on the backup side. I like my backup to protect me from at least one level of fat-fingers. :) This has the added benefit that you can have a smaller retain count on the active source, but keep files longer on the backup side. I've also started using holds on the backup side as a belts-and-suspenders approach. Just my 2c. - Eric