SUMMARY: Backup while in multi-user mode

Nicole Delbecque & Paul Bijnens FFAAC09 at cc1.kuleuven.ac.be
Thu May 23 21:48:32 AEST 1991


In article <1991May21.172208.281 at erg.sri.com>, zwicky at erg.sri.com (Elizabeth
Zwicky) says:
>
>Using tar instead of dump buys you extremely little. tar will skip
>active files, which means they won't corrupt your backup.

What is meant by "active files" in the context of tar.  How does
tar know when a file is opened by another program (it cannot read
/dev/kmem, can it)?  Do you mean it skips the files, not putting them
on the tape?

I thought the fundamental difference between dump and tar/cpio was
that tar/cpio just read the files through the block-device while
dump reads the raw device.

In the light of "internal" consistency of the backup (i.e. the tape
can always be restored) using tar, can somebody explain what happens
in these cases:
1. While tar reads through the file, the file grows at the end.
   e.g. log files frequently do this.  Where does tar stop?  At the
   old end of the file (so that the inode information on the tape is
   consistent with the length of the data following it) or when it
   encounters EOF of the disk-file (but now the tape is inconsistent)?
2. Someone truncates the file (to 0 or with the syscall trunc()).
   Tar just reads the block-device.
   Will tar add zero-filled blocks to match the recorded file-length?
3. Let's suppose a dbm-file. Tar just reads sequentially. Some other
   program updates the dbm-file.  I think the tape will contain
   some file (it will restore without problems), but you cannot
   do anything useful with the restored file.

Our version of cpio maintains it consistency: it can always restore
the files.  But, like in case 3, the restored file could be useless.
How does tar behave in this respect?

p.s. Another "advantage" of tar/cpio to do the backups is that you
     can restore the files on a different system (e.g. from a BSD
     to a SysV machine) without much hassle.
     This becomes more important for the archived backups.  You
     never know what machine you will have in 5 years from now.
--
Polleke   (Paul Bijnens)
Linguistics dept., K. University Leuven, Belgium
FFAAC09 at cc1.kuleuven.ac.be



More information about the Comp.unix.admin mailing list