Hello Netters,
some Days ago I posted a Question about Level 0 dumps on SUNs; I had read on
comp.unix.admin that there *are* Reasons to do it single-User, but OTOH Sun
Manuals showed Level 0 performed in multi-User.
I received 10 Replies, and here is the Result for the uninterested Readers:
Use many rotating Tapes, dump multi 2
single-User / un-/remount Filesystems 3
there's no Problem unless you're in *BAD* Luck 2
Use a Backup Software that does Locking 1
What's so special about Level 0 (vs. Level >0), anyway? 1
(I. e., nine gave Recommendations, one enumerated the Possibilities and
their Cons and Pros.)
============================================================================
To be more detailed: The Problem in Level 0 (as probably most of you will
know) is that dump expects the Filesystem to be "silent", i. e., it isn't
able to ward off Changes between the Times it looked up the Inodes and the
Times where it actually dumps them. The two IMHO most flagrant Results are
-- File of User A gets replaced by File of User B: restore will create a
File owned by A but with (Part of) the Data of B --> Security Breach
-- Directory gets replaced by File: restore expects only Files to come as
soon as it meets the first File. Thus, all Dirs behind the affected
dump Record can't be restored as Dirs, so the Files in them can't be
restored at all. Note that this proves that a Change may trash other
(unchanged) Inodes!
There is no special Magic in SUNs which protects them from such Effects.
The Fact that a SUN Manual shows a multi-User full Dump is explained by
the Fact that *all* Levels of Precaution can be found *somewhere* in the
Manuals, from multi Level 0 (SunSys&NetMangerGuide) to single even for
Incrementals (dump Manpage).
A Filesystem can be made silent by several Means:
-- dumping when nobody's working on the Filesystem
(watch the not-so-obvious Types like cron, mail or FTP!)
-- umount (or [re]mount read-only) the Filesystem
-- go single-User
-- lock the Filesystem (as many sophisticated Backup Tools do).
Talking of Locks: There is Software which locks individual Files (for what-
ever Reason), so these Files won't be backed up as long as the App is run-
ning. Since there are Database Management Daemons in this Category, you
might find that you have to kill them during the Backup.
As you see, there is "perfectly silent" and "probably silent". Those who
make it perfect have Lots of Downtime, but low Risk. Those who keep the
System accessible (e. g., because there are *always* long-Term Jobs run-
ning) have a Risk depending on the actual Usage; Some rely on Probability
alone, others minimize the Risk by keeping Lots of old Backups available.
A last Detail: There are elaborated Ways how to do fully automatic Backups
in single-User, both for BSD and SysV Unixes. The SysV World introduces
an additional Run Level which then does the Backup. BSD Variants do the
like with the /etc/rc* Scripts. In the latter Case, be sure to
-- rename your "Flag File" so that a Crash won't loop,
-- dump before exporting Filesystems,
-- check that the "Flag File" was indeed created by the Admin before you
execute it (which is the easiest Way of selecting one from several
Dump Scripts).
Having said all this, the Decision is *still* up to your own Ideas of what
Risks you will take at which Price. :-)
Thanx again,
J. Bern
-- / \ I hate NN rejecting .sigs >4 lines. Even though *I* set up this one. /\ / J. \ EMail: bern@[TI.]Uni-Trier.DE / ham: DD0KZ / More Infos on me from / \ \Bern/ X.400 Mail: S=BERN;P=Uni-Trier;A=dbp;C=de / X.400 Directory, see \ / \ / Zurmaiener Str. 98-100, D-W-5500 Trier / X.29 # 45050230303. \/
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:38 CDT