From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 Description of problem: In the backup/restore section of the manual, several tools are presented: tar, cpio, dump, amanda. See the above URL for the actual section. In this section dump is heavily criticised. As the upstream maintainer of this tool, I have to protest :) First of all, dump was designed since the beginning to be run on unmounted filesystems (or mounted R/O). When backuping unmounted filesystems, dump will work perfectly. As a matter of fact, dump is the only tool capable of doing that: tar, cpio etc needs to access a mounted filesystem. If umounting the filesystem is not an option, dump will also work correctly if some filesystem snapshot technique is used (like the LVM snapshots). There is hope that in future kernels there will be possible to have filesystem snapshots even outside LVM. If umounting the filesystem is not possible and snapshots aren't available either, dump can be run on the active filesystem. In this case, and in this case only, Linus is right: given the right timing, disk occupation, level of activeness etc, dump will fail. However, experience has shown that this failure is rather rare, and will be detected anyway if the operator care to verify the backups. And since there is very good practice to always verify the backups (bad tapes occur quite frequently...), the risk is minimal. I could add that, even for the other backup tools like tar, if the filesystem is mounted and active, the state of the backup will not be coherent, because tar will save files being modified, and depending on how the files are being modified the result could be corrupt and useless (think about saving a database without shutting down the database server...). I should also add that dump/restore has some features very useful that are not in the other solutions you propose: interactive restore (you can walk in a shell-like through the list of directories and files and interactively select what you want to restore), good at incrementals (tar sucks in this area), correct handling of files with holes (dump is the only tool to be able to do this, by its very own design), speed of dump, etc... In the light of all this, I would ask you to modify the section on dump/restore to correctly reflect the truth. If you want, add a warning telling that if the filesystem is mounted there is always the possiblity to have bad backups. But in this case add also a note saying that dump has some unique features that can select it as a viable candidate as the backup tool of choice. Thanks, Stelian. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Read the manual Additional info:
I have changed this section to note that the issue is with mounted filesystems. Thanks for letting me know your thoughts on this matter...
*** Bug 99186 has been marked as a duplicate of this bug. ***
*** Bug 99185 has been marked as a duplicate of this bug. ***
Are there any plans to add an errata for this? At present, there is no errata for the System Administration Primer at: http://www.redhat.com/docs/errata/RHL-9-Manual/
No, there are no plans WRT an errata. To be honest, the change to that section is limited almost entirely to the title: dump/restore: Not Recommended for Mounted File Systems! and this sentence: However, dump was originally designed to backup unmounted file systems; therefore, in situations where it is possible to take a file system offline with umount, dump remains a viable backup technology.
OK. My impression of this issue is that dump/restore remains as good a solution, or better, than tar, cpio, etc. The comment by Stelian Pop said that the "coherency" problem that was originally described by L. Torvalds exists for those utilities as well. So, what Red Hat is providing is a large warning about dump/restore, but leaving readers with the impression that if they simply use tar, cpio, etc. then they will be safe, when the reality is that all software has the risk of producing an "incoherent" backup when run on mounted filesystems. (I am non-religious on this question. I simply want a good backup/recovery solution.)
Mark, I appreciate your opinion, and personally, I really like dump/restore (I particularly like the interactive restore capability). However, I don't think you're 100% correct in your interpretation of the situation. The issue (as outlined by Linus) is that there is an aspect of 2.4 and later kernels that can result in dump doing the wrong thing when backing up a mounted, actively read/written, filesystem. Stelian notes that this is the case, although he says that this is rare (and can be detected by always verifying backups). Stelian then goes on to say that, when backing up filesystems that are being actively read/written, other backup tools (like tar and cpio) also have problems, due to the files changing "underneath" them. This aspect of backups (backing up a filesystem that is currently in active use) is a fact of life on *all* operating systems for *all* backup tools -- not just Linux and tar/cpio. I imagine it would impact dump, as well (Stelian, feel free to correct me if I'm wrong). So, there are two issues -- the "backing up active filesystems" issue shared by all operating systems and backup tools, and the other issue, raised by Linus (and acknowledged by Stelian) as affecting dump. As a writer employed by Red Hat, what I write is seen to carry the weight of our company; in many ways, my documentation "speaks" for the company. Therefore, I must be careful about what I say in the documentation. What would happen if I wrote "dump is a great tool to use whenever you need to backup your data", and then a customer loses data? That's a possible lawsuit in the making -- *particularly* when a widely-recognized expert in the field says very explicitly "do not use dump". Given this, I feel the section (as amended) strikes an appropriate balance -- it acknowledges that dump exists, that there exists the possibility of data loss (and quotes the source of that statement), and that the problem affects filesystems that are not unmounted. To go any further would, in my opinion, be a mistake on Red Hat's part; to say any less would also be a mistake (which is why I amended the section in response to this bug report).
Ed, I do understand your point of this 'official RedHat recommandation' thing. However, go read that section again! The section on 'dump' is twice as big then the entry for any other tool, and contains only negative items. What I would like is something like 3-4 lines showing the dumps advantages (incrementals, interactive restore, etc etc). Next, you can add a 'tip' or '!' section saying that dump is safe only when run against a unmounted filesystem or a LVM/EVMS snapshot, and otherwise the data could be corrupted, and there you can add a pointer to the Linus' message (I think a pointer would be enough, no need to reproduce the full message). Stelian.