home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!gatech!destroyer!mudos!mudos!not-for-mail
- From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
- Newsgroups: comp.unix.sys5.r4
- Subject: Re: backup / problems ??
- Date: 20 Jan 1993 19:59:28 -0500
- Organization: The Programmers' Pit Stop, Ann Arbor MI
- Lines: 26
- Message-ID: <1jkshgINN7qp@mudos.ann-arbor.mi.us>
- References: <1993Jan18.235240.4933@cactus.org> <C13t15.H9t@news.rn.com>
- NNTP-Posting-Host: mudos.ann-arbor.mi.us
-
- In article <C13t15.H9t@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
- >with find . -depth -print -mount | dd bs=5k | cpio -ocB > /dev/tape
- ^^^^^^
- This is why you don't have any problems. The -mount flag to find(1)
- tells it not to recurse into other filesystems. Since both /proc and
- /dev/fd are implemented as separate filesystems under SVR4, cpio never
- tries to back them up.
-
- But I agree with Larry that you generally don't want to try to back up
- pseudo-filesystems such as /proc; their contents will generally be
- invalid by the time you go to restore. /dev/fd is different; it
- consists of regular character device files, and you should back it up
- just like you back up the rest of /dev. Of course, tar won't handle
- this correctly, but then again tar doesn't handle *any* device files
- correctly, and thus shouldn't really be used for a backup of your root
- filesystem.
-
- Me, I prefer ufsdump -- nice and fast, and the interactive ufsrestore
- mode is a godsend when you can't quite remember the name of the file
- you need to restore.
-
- --
- Marc Unangst, N8VRH | "Of course, in order to understand this you
- mju@mudos.ann-arbor.mi.us | have to remember that the nucleus of the atom
- | is squishy."
- | -W. Scheider, from a Physics lecture
-