Re: mkisofs aborts but exit value is 0
> >> And how is this related to a filesystem snapshot?
> > Volker Kuhlmann wrote :
> > Not, I believe he was talking about checkreading the burnt disks, sorry
> > if I misunderstood.
> Possibly my fault.
> I meant to be talking about the large time window of
> a real world DVD (or CD) level 0 backup. The remark about
> checkreading on a second PC was mainly intended to
> illustrate time optimization which can be applied by
> the operator.
As long as you have enough disk space, there is no problem.
I would be able to hold a snapshot for Berlios for aprox.
> 1) Can i uphold the snapshot long enough ?
See above. If you can't you definitely don't have
enough disk space.
> My main concerns are an eventual shutdown, or the
> disk space needed to uphold two versions of an agile
> filesystem over a few days. The changes resp. saved
> old states of changes have to be stored somewhere,
> don't they ?
You need to restart the backup in case the machine reboots
(if you run FreeBSD, you could even restart an old snapshot).
But Solaris is stable enough so there is no problem
with a possible crash.
> 2) Does a snapshot really decrease the probability
> of backing up a file while it is in an ill state ?
> "Ill" in the sense that it does not comply to a
> valid persistent state as expected by its applications
> when they open it.
> Not "ill" in the sense of "a case for fsck".
If you have an ill designed application, you are lost.
decent applications should write files in a way that
does not create ill states.
> Of course, the backup program's life is much more
> easy if it does not have to be aware of vanishing
> files which it saw in its planning phase and cannot
> find when it's time for reading.
> Insofar, snapshots are very desirable.
If you like to create reliable backups without bringing the
machine down, you need them but they are available since
4 years now. Star supports using snapshots since about a year.
> I wish i knew how to do some.
Start with man fssnap
> Another advantage: a snapshot does not solve problems
> with files of busy databases. But one can shutdown
> the database server, do the snapshot and restart the
> database immediately.
A decent DB should support a way of doing own internal
snapshots that result in reliable backups.
> A snapshot does not keep you safe if you don't know
> exactly what particular services need to be shutdown
When using snapshots, you don't need to shutdown services
while running a backup.
EMail:email@example.com (home) Jörg Schilling D-13353 Berlin
firstname.lastname@example.org (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily