Date: Mon, 22 Aug 2005 10:34:53 +0100 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: Ilari Laitinen <ilari.laitinen@iki.fi> Cc: questions@freebsd.org Subject: Re: dump(8), incremental backups, Tower of Hanoi sequence, don't get it Message-ID: <43099C3D.7010809@dial.pipex.com> In-Reply-To: <20050819173337.GA2722@lohi.local> References: <20050819141535.GA62513@lohi.local> <4305F92C.9080001@dial.pipex.com> <20050819173337.GA2722@lohi.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Ilari Laitinen wrote:
>On Fri, Aug 19, 2005 at 04:22:20PM +0100, Alex Zbyslaw wrote:
> =20
>
>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.
> =20
>
Yes, that looks correct. Like I said, for a lightly used computer you=20
might want to keep it simpler. It really depends how *big* the files=20
which change are and how big your backup disk is compared to your real=20
one. You can figure out what was dumped on each backup using "restore=20
-ivf {path_to_backup}" and typing "ls"* at the prompt. A simpler scheme =
makes it easier to find a random single file which you deleted by=20
accident, as opposed to recovering your whole disk.
If you are backing up to disk, then you could also consider compressing=20
you backups. Instead of doing
dump -NuaL -f [path_to_backup]
you could do
dump -Nual -f - | gzip -9 > [path_to_backup].gz
Then to check what is on it:
gunzip -9 [path_to_backup].gz | restore -ivf -
(*) Actually, that will just show the top level directories. What you=20
get is a *very* simple shell with ls, cd and a few restore specific=20
options. Depressingly, restore isn't set up to use the readline=20
library, so you get no command editing.
>>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 =
>>machine is. Anything from weekly to quarterly.
>> =20
>>
>
>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.
> =20
>
That's fine. Certainly nothing changes when the machine is off :-) =20
Beware of "I was just surfing the net" though, as you may have had email =
coming in, and have bookmarked somewhere that you'll never manage to=20
find again :-) Regrettably, even trivial sessions can generate=20
important data. But like you say, that's your call. From experience I=20
know that there is a strong tendency for laziness to kick in.
--Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43099C3D.7010809>