Date: Mon, 5 Jan 2015 14:45:38 -0600 From: "Eric A. Borisch" <eborisch@gmail.com> To: Tim Gustafson <tjg@ucsc.edu> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: ZFS Send / Receive Recursively Without Properties Message-ID: <CAASnNnphL%2By9C-BJXQrvdabJTav3NDjg3yOmyxgLufs6Oa0WsQ@mail.gmail.com> In-Reply-To: <CAPyBAS728yuSbze%2BmtUTpC97qoo1O8NJtYfoaafKO-ibSEnkpw@mail.gmail.com> References: <CAPyBAS728yuSbze%2BmtUTpC97qoo1O8NJtYfoaafKO-ibSEnkpw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, January 5, 2015, Tim Gustafson <tjg@ucsc.edu> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAASnNnphL%2By9C-BJXQrvdabJTav3NDjg3yOmyxgLufs6Oa0WsQ>