Bug 89849
Summary: | dump/restore incorrectly criticized | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Stelian Pop <stelian> |
Component: | rhl-sap | Assignee: | Ed Bailey <ed> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Tammy Fox <tammy.c.fox> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | maharig |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/admin-primer/s1-disaster-rhlspec.html | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-05-30 17:27:16 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Stelian Pop
2003-04-28 21:33:25 UTC
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. |