Also Sprach Anthony A. D. Talltree: > >Its interesting that I was unaware of this dilema ( the possible failure > >of DUMP ) until it was posted on this list > > It's mentioned in the second paragraph of Sun's ufsdump man page. > Despite all the FUD that's been parroted about dump over the years, by > and large it's worked just fine for most people. >
I haven't had any significant problems with ufsdump on Solaris, xfsdump on Solaris, vdump on Tru64 or backup on AIX. Although it is not quite clear to me whether xfsdump, vdump, and backup are file level or block level utilities. Sometimes an active file doesn't make it but I haven't had a totally corrupt dump image. However, I am able to do backups at a time when the filesystems are mostly quiescent, I don't run a 24x7 mail server with hundreds or thousands of users for example. Is anyone actually using dump to backup such a partition without taking the partition offline? The admins I speak with who have such systems usually use snapshotting or mirroring, quiescing and breaking the mirror, and then using dump. > Either the Linux kernel and/or the Linux incarnation of dump is > apparently way broken, and Linus (or whoever) seems to be too lazy or > stubborn to fix it. You left out the possibilities of incompetence and/or cross/recursive linkages in their phylogenetic trees. > Tar is simply not a general-purpose replacement for > something that backs up a whole filesystem without trashing the read > dates on files - and in much less time. > In particular, trying to do incremental backups using a file level util on partitions with files that continually grow like mail spools or syslogs. -- C. Chan <[EMAIL PROTECTED]> GPG Public Key: finger [EMAIL PROTECTED]
