From owner-freebsd-questions@FreeBSD.ORG Fri Aug 19 15:22:24 2005 Return-Path: X-Original-To: questions@freebsd.org Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C6FA16A41F for ; Fri, 19 Aug 2005 15:22:24 +0000 (GMT) (envelope-from xfb52@dial.pipex.com) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9247E43D49 for ; Fri, 19 Aug 2005 15:22:22 +0000 (GMT) (envelope-from xfb52@dial.pipex.com) Received: from [82.41.37.55] ([82.41.37.55]) by smtp-out5.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Aug 2005 16:23:08 +0100 Message-ID: <4305F92C.9080001@dial.pipex.com> Date: Fri, 19 Aug 2005 16:22:20 +0100 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7.8) Gecko/20050530 X-Accept-Language: en, en-us, pl MIME-Version: 1.0 To: Ilari Laitinen References: <20050819141535.GA62513@lohi.local> In-Reply-To: <20050819141535.GA62513@lohi.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2005 15:23:08.0804 (UTC) FILETIME=[E771C440:01C5A4D1] Cc: questions@freebsd.org Subject: Re: dump(8), incremental backups, Tower of Hanoi sequence, don't get it X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2005 15:22:24 -0000 Ilari Laitinen wrote: >Handbook reads dump(8) is the best backup program there is. So I am >giving it a try - only to find out that I don't understand at all the >meaning of that modified Tower of Hanoi algorithm descibed in the >manual page and elsewhere. The manual page says it is "an efficient >method of staggering incremental dumps to minimize the number of >tapes." I just don't get the picture here. > >So, could somebody please give an idiot-proof explanation why "3 2 5 >4 7 6 9 8 9 9" is such a tape-number-minimizing dump level sequence >(with helpful examples, if at all possible)? How does it work? > >Am I relatively safe doing level 0 dump every two months and >increasing dump level for weekly backups like the following, given >two separate harddrives storing them? > >Date Dump level >2005-09-01 0 >2005-09-08 1 >2005-09-15 2 >... >2005-10-27 8 >2005-11-03 0 > > No, your sequence is the worst possible. If you have a crash on 2005-10-27 then you will need to recover files from *every* dump from your last level 0. A level 0 dumps everything. A level 1 everything since the last 0 a level 2, everything since the last 0 or 1 a level 3 everything since the last 0, 1 or 2 A level 4, everything since the last 0, 1, 2, or 3 etc. The idea is is to make the numbers rise and fall to minimise the number of backups needed to do a full restore. Write yourself some sequences and figure out for yourself which ones you would need for a full backup. Try to figure out for each backup whether the same files will be dumped by a later backup. They will, if a later backup number is *lower*. The algorithm your aiming to create is: Start with a level 0 and ignore everything before. from end of list, find the lowest number before you reach the starting dump. You'll need this backup. Make it the new start of list. from end of list, find the lowest number before you reach the starting dump. You'll need this backup. Make it the new start of list. etc. E.g. Given 0 3 2 5 4 7 6 9 To restore everything you need the 0, 2, 4 and 6. I.e. every second dump. You'll see that wherever you stop in that sequence, no more than 3 backups are required to recover everything. I have never liked the 9 9 9 trailing off to infinity. If you are not doing a full backup by then, then you should be restarting your sequence from the dump after the full backup. E.g. 3 2 5 4 7 6 9 8 then back to 3 2 5 4 7 6 9 8 and repeat. Personally I use a much shorter sequence: 0 1 3 2 1 3 2 1 3 2. But that's because I don't usually change vast amounts of data. I would also consider doing your backups daily, not weekly as your example suggests. The timing of full backups depends on how busy your machine is. Anything from weekly to quarterly. --Alex