Date: Fri, 19 Aug 2005 20:33:37 +0300 From: Ilari Laitinen <ilari.laitinen@iki.fi> To: questions@freebsd.org Cc: Alex Zbyslaw <xfb52@dial.pipex.com> Subject: Re: dump(8), incremental backups, Tower of Hanoi sequence, don't get it Message-ID: <20050819173337.GA2722@lohi.local> In-Reply-To: <4305F92C.9080001@dial.pipex.com> References: <20050819141535.GA62513@lohi.local> <4305F92C.9080001@dial.pipex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 19, 2005 at 04:22:20PM +0100, Alex Zbyslaw wrote:
> Ilari Laitinen wrote:
>=20
> >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
> >=20
> >
> No, your sequence is the worst possible. If you have a crash on =20
> 2005-10-27 then you will need to recover files from *every* dump from=20
> your last level 0.
>=20
> A level 0 dumps everything.=20
>=20
> A level 1 everything since the last 0
>=20
> a level 2, everything since the last 0 or 1
>=20
> a level 3 everything since the last 0, 1 or 2
>=20
> A level 4, everything since the last 0, 1, 2, or 3
>=20
> etc.
>=20
> The idea is is to make the numbers rise and fall to minimise the number=
=20
> of backups needed to do a full restore. Write yourself some sequences=20
> and figure out for yourself which ones you would need for a full=20
> backup. Try to figure out for each backup whether the same files will=20
> be dumped by a later backup. They will, if a later backup number is=20
> *lower*.
>=20
> 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=20
> 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=20
> starting dump. You'll need this backup. Make it the new start of list.
> etc.
>=20
> E.g. Given 0 3 2 5 4 7 6 9
>=20
> To restore everything you need the 0, 2, 4 and 6. I.e. every second=20
> dump. You'll see that wherever you stop in that sequence, no more than=
=20
> 3 backups are required to recover everything.
This pretty much cleared it up. Now that I read the manual page again,
enlightened, it seems quite easy to follow. Nice.
Using the algorithm above I get the following:
Sequence Dumps needed
0 3 0 3
0 3 2 0 2
0 3 2 5 0 2 5
0 3 2 5 4 0 2 4
0 3 2 5 4 7 0 2 4 7
0 3 2 5 4 7 6 0 2 4 6
0 3 2 5 4 7 6 9 0 2 4 6 9
0 3 2 5 4 7 6 9 8 0 2 4 6 8
0 3 2 5 4 7 6 9=B98 9=B2 0 2 4 6 8 9=B2
Am I doing this right? Every time a dump of level N is, eh, taken,
earlier tapes of level >N become obsolete and are free to go(*). In this
case, that happens every other time.
(*) Unless one would like to have those file versions around for a
longer time, of course.
> clip
>
> I would also consider doing your backups daily, not weekly as your=20
> example suggests. The timing of full backups depends on how busy your=20
> machine is. Anything from weekly to quarterly.
Well, I am the only active user on this computer. And I know when there
is something to back up, so it will be a bit irregular in reality. If I
only surf the Net all weekend long, there is nothing to worry about. Or
if I am not physically around, the computer will have no power to mess
with.
Thank you, Alex, and others who replied (Jerry, Charles)! Now I only
have to buy those harddrives to start my new, shiny life with less fear
for random data loss. :)
Ilari
--=20
Ilari Laitinen - ilari.laitinen@iki.fi - http://iki.fi/ilari.laitinen/
--6TrnltStXW4iwmi0
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)
iD8DBQFDBhfxQj4nNFSfK+YRAhQsAJ9ShOHrQ6Tmdcck7/oMR1oaKbqEBACfcmgI
ebE5lXiF8xcqtLcPW3WR3Us=
=Ld+D
-----END PGP SIGNATURE-----
--6TrnltStXW4iwmi0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050819173337.GA2722>