slevy@uf.msc.umn.edu (Stuart Levy) (12/10/88)
Has anyone tried using "dd" for file system dumps? Alternatively, does anyone know of a way restore could be made to run at a reasonable speed? The problem is this. Our Sun disk needs are growing. We'll soon have about 1.5GB on one of our servers. Dumping these takes a while; we could probably improve this by bringing up 4.3BSD dump. More worrying, though, is the speed of restore, which we found by painful experience after a flurry of disk controller failures last spring to average around 50 Kbytes/s -- on a 3/280, Ciprico controller and pretty fast Fujitsu Swallow disks. At that rate, even if all goes well, it'll take a full 12 hours to reload a wrecked file server. I suspect the far slower restore speed is because the file system code is taking care to do directory and inode updates synchronously to ensure consistency, a laudable feature but one I wish we could defeat at times like that. So it's tempting to switch to using "dd" rather than "dump" for dumps. It would have some advantages... - dumps would be much faster, maybe 2-3x SunOS 3.3's dump - restores would be at least an order of magnitude faster - inode numbers would not be changed by a restore so NFS clients wouldn't need to be rebooted but some disadvantages... - restoring individual files from a backup would be a pain, we'd need to keep a large free disk partition for the purpose - dumps would be somewhat larger, though since our file systems normally run close to full we probably wouldn't waste much - incrementals wouldn't work as well; we could use tar, sort of (but with full dumps being much faster we could do them more often) - they might be inconsistent when done on (even slightly) active file systems Of course potential inconsistency is the most worrisome. I've tried a couple such dumps and found nothing which fsck won't fix routinely. But can anyone suggest a reason why "dd" dumps should do much worse than "dump" dumps on live file systems? Should files which weren't changing during the dump be affected? Stuart Levy, Minnesota Supercomputer Center slevy@uc.msc.umn.edu
bzs@encore.com (Barry Shein) (12/30/88)
A problem you would run into with using dd for full dumps and some sort of find/tar command for incrementals is that you won't backup deletions. This means that if a file is deleted between the full and the tar incremental there will be no real record of that. This poses three problems: 1. If, as you say, you tend to run nearly full partitions then when you restore the incremental tar tapes you may run out of disk space and not be able to complete the restoral. VERY annoying and time-consuming to work around! 2. The reappearance of deleted files could be considered a security problem (for example, Joe Prof deletes some sensitive files before going away for a while because he wants to let someone use his acct while away, or knows eventually his amazing grad students will find a way into everything he leaves around only to discover on returning the files were put back onto his account the day after he left and copies now hang on the bathroom walls.) 3. Similarly, users get *very* confused when deleted versions of files re-appear and you'll waste the time saved responding to frantic (although usually not totally justified) mail. See, I went thru this on a 3B5 in another life where we were forced to use this type of backup scheme due to the non-existence of a backup utility under SYSV. Ugh, think it through (note you probably could cobble something together which restores deletions, I think we eventually did by putting directory listings of changed dirs onto the tar tape and running something over them on a restore to delete any files which needed deletion, or at least we talked about it, it's been a while.) Then again by the time you're finished you'd probably be only slightly ahead of using dump/restore. -Barry Shein, ||Encore||