Date: Tue, 15 Jan 2002 12:22:36 -0600 From: "Mike Meyer" <mwm-dated-1011550956.5131e2@mired.org> To: Brian T.Schellenberger <bts@babbleon.org> Cc: swear@blarg.net (Gary W. Swearingen), questions@freebsd.org Subject: Re: HOWTO -- backup onto CDRs? Message-ID: <15428.29548.346178.21655@guru.mired.org> In-Reply-To: <001601531120f12FE6@Mail6.nc.rr.com> References: <15426.33499.296182.78699@guru.mired.org> <15426.63500.847866.284422@guru.mired.org> <ukk7ukwzrk.7uk@localhost.localdomain> <001601531120f12FE6@Mail6.nc.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian T. Schellenberger <bts@babbleon.org> types: > On Monday 14 January 2002 01:31 pm, Gary W. Swearingen wrote: > > Or maybe he meant to avoid saving the archive to hard disk by piping > > it to the CD burning program. I don't know if even the fastest system > > could do that, but it's easy enough to test and should be safe enough > > since the burning program will tell you if you don't feed it data fast > > enough. > I did this all the time under Linux; even with a P-450 it worked just fine as > long as the system wasn't overtaxed (as in, load < 2), using the stdin > feature of cdrecord. I tried with burncd under FreeBSD and had no success, > though. Of course, cdrecord doesn't support stdin input so I had to set up a > named pipe but I don't know why that would be a problem in and of itself. cdrecord supports stdin - just use the file name "-". I pipe the output from mkisofs to cdrecord on a regular basis, and in general it works fairly well so long as I'm not loading the system to heavily (as in, load < 5). The slowest system I've had a CDRW on had dual Xeon 400s, though. > > A NOTE ON "dump" USAGE: I see a problem with using dump in that the man > > page says it doesn't dump files and directories with the "nodump" file > > flag set. That seems to mean that to do a backup with confidence, one > > would need to run "chflags" on everything one intends to dump. Not a > > big problem if one remembers to do it; it just lengthens the process. > This would normally be considered a feature. I certainly agree with that. > PS: Another drawback of dump is that I, for one, have been known to switch > O/S's on a semi-regular basis, so an O/S-specific format naturally goes > against the grain. Dump was designed for file system backup and restoration, not for sharing files with other systems. So naturally there are tools that do the latter better. Since the files that give those tools problems when used for backup and restoration are generally ones that aren't used on a different OS, have a non-portable format, or non-portable attributes that get lost, you use one of the others for moving files between systems. The last time I did a system upgrade like that, I used tar feeding an rsh to untar them on the other system. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15428.29548.346178.21655>