From owner-freebsd-questions@FreeBSD.ORG Fri Apr 3 17:22:27 2015 Return-Path: Delivered-To: freebsd-questions@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 D2DEA366 for ; Fri, 3 Apr 2015 17:22:27 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [74.201.84.162]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1EBD8A7 for ; Fri, 3 Apr 2015 17:22:27 +0000 (UTC) Received: from WorkBox.Home (184-100-67-185.mpls.qwest.net [184.100.67.185]) by mx.zohomail.com with SMTPS id 1428081739483487.50589281406224; Fri, 3 Apr 2015 10:22:19 -0700 (PDT) Date: Fri, 3 Apr 2015 12:22:11 -0500 From: Bigby James To: freebsd-questions@freebsd.org Subject: Re: Dump(8) does not do incremental Message-ID: <20150403172211.GA73894@WorkBox.Home> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 17:22:27 -0000 On 04/03, Olivier Nicole wrote: > I understand one may want to not implement the incremental dumps, but the > default should enable them. There are several reasons full upgrades are the safer and saner default. Incremental backups are convenient because they consume less time in the present, but the fact is that backing up data and restoring it do not deserve equally consideration since restoring data is always a matter of immediate need. Incremental backups require less time to create but are more time-consuming to restore, and without a proper naming scheme incremental backups can significantly raise the possibility of human error during the restoration process. Finally, while the ideal scenario is a backup system that can be automated, one cannot reliably automate a restoration process, so keeping things simpler and more flexible for restoration should be the focus when setting defaults for a backup system. And of course strictly incremental backups just don't make sense in some cases, such as when the base system and/or '/var' are stored on their own partitions. In such a case, making a full backup takes a few minutes at the most on a single-user machine, while if a lot of frequently changed time-sensitive data like mail or specialized logs are stored in '/var' for a cluster or network then incremental backups increase the risk of inconsistencies on restore (unless a filesystem is unmounted when a dump is made, which isn't always an option). Finally, you also need to consider that the manner in which people increment and rotate their backups is a matter of personal preference, so coming to a consensus on a default implementation of incremental backups would probably be a real pain for the developers. Defaulting to "back up everything in one place" is just the smarter option. It lessens the learning curve and chances for error for new users and potentially sacrifices a little convenience now for a big payoff in convenience and assurance when they matter most later on. Although I have to agree that yes, the nature of the /etc/dumpdates file could be more clearly documented. It's mentioned several times in the man page, but perhaps a brief explanation should be given in the 'Description' section near the top. -- "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams