diff options
author | Otto Moerbeek <otto@cvs.openbsd.org> | 2007-11-18 18:56:26 +0000 |
---|---|---|
committer | Otto Moerbeek <otto@cvs.openbsd.org> | 2007-11-18 18:56:26 +0000 |
commit | fd14224a8022d94b542019d91e949fb9b9fca00b (patch) | |
tree | 32776c2e8283e1ffb8cd374355bf4bd730bc3b0a /sbin/dump/dump.8 | |
parent | f970b0c9af1cf5196e7fb67820946c225a628a47 (diff) |
do not confuse the reader telling he should use a towers of hanoi
based scheme when it makes no sense: a weekly schedule does not
benefit from it. ok mbalmer@ jmc@ ray@
Diffstat (limited to 'sbin/dump/dump.8')
-rw-r--r-- | sbin/dump/dump.8 | 47 |
1 files changed, 30 insertions, 17 deletions
diff --git a/sbin/dump/dump.8 b/sbin/dump/dump.8 index c90caac314a..c0afb2d9433 100644 --- a/sbin/dump/dump.8 +++ b/sbin/dump/dump.8 @@ -1,4 +1,4 @@ -.\" $OpenBSD: dump.8,v 1.41 2007/05/31 19:19:44 jmc Exp $ +.\" $OpenBSD: dump.8,v 1.42 2007/11/18 18:56:25 otto Exp $ .\" $NetBSD: dump.8,v 1.17 1997/06/05 11:15:06 lukem Exp $ .\" .\" Copyright (c) 1980, 1991, 1993 @@ -31,7 +31,7 @@ .\" .\" @(#)dump.8 8.1 (Berkeley) 6/16/93 .\" -.Dd $Mdocdate: May 31 2007 $ +.Dd $Mdocdate: November 18 2007 $ .Dt DUMP 8 .Os .Sh NAME @@ -334,9 +334,9 @@ and will be for some time. .Pp In the event of a catastrophic disk event, the time required to restore all the necessary backup tapes or files to disk -can be kept to a minimum by staggering the incremental dumps. -An efficient method of staggering incremental dumps -to minimize the number of tapes follows: +is dependent on the levels of the dumps taken. +A few methods of staggering incremental dumps to either minimize +backup effort or restore effort follow: .Bl -bullet -offset indent .It Always start with a level 0 backup, for example: @@ -347,24 +347,37 @@ Always start with a level 0 backup, for example: This should be done at set intervals, say once a month or once every two months, and on a set of fresh tapes that is saved forever. .It -After a level 0, dumps of active file -systems are taken on a daily basis, -using a modified Tower of Hanoi algorithm, -with this sequence of dump levels: +After the level 0 dump, +backups of active file systems are taken on each day in a cycle of a week. +Once a week, a level 1 dump is taken. +The other days of the week a higher level dump is done. +.Pp +The following cycle needs at most three tapes to restore to a given point +in time, +but the dumps at the end of the weekly cycle will require more +time and space: .Bd -literal -offset indent -3 2 5 4 7 6 9 8 9 9 ... +1 2 2 2 2 2 2 .Ed .Pp -For the daily dumps, it should be possible to use a fixed number of tapes -for each day, used on a weekly basis. -Each week, a level 1 dump is taken, and -the daily Hanoi sequence repeats beginning with 3. -For weekly dumps, another fixed set of tapes per dumped file system is -used, also on a cyclical basis. -.El +This sequence requires at most eight tapes to restore, +but the size of the individual dumps will be smaller: +.Bd -literal -offset indent +1 2 3 4 5 6 7 +.Ed .Pp +This sequence seeks a compromise between backup and restore effort: +.Bd -literal -offset indent +1 2 2 3 3 4 4 +.Ed +.Pp +The weekly level 1 dumps should be done on a set of tapes that +is used cyclically. +For the daily dumps a tape per day of the week can be used. +.It After several months or so, the daily and weekly tapes should get rotated out of the dump cycle and fresh tapes brought in. +.El .Pp If .Nm |