Bug 89849 - dump/restore incorrectly criticized
dump/restore incorrectly criticized
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: rhl-sap (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ed Bailey
Tammy Fox
http://www.redhat.com/docs/manuals/li...
:
: 99185 99186 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-28 17:33 EDT by Stelian Pop
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-30 13:27:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stelian Pop 2003-04-28 17:33:25 EDT
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:
Comment 1 Ed Bailey 2003-05-30 13:27:16 EDT
I have changed this section to note that the issue is with mounted filesystems.
 Thanks for letting me know your thoughts on this matter...
Comment 2 Ed Bailey 2003-07-15 12:56:20 EDT
*** Bug 99186 has been marked as a duplicate of this bug. ***
Comment 3 Ed Bailey 2003-07-15 12:56:51 EDT
*** Bug 99185 has been marked as a duplicate of this bug. ***
Comment 4 Mark Harig 2003-07-29 18:25:19 EDT
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/
Comment 5 Ed Bailey 2003-07-30 12:40:14 EDT
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.
Comment 6 Mark Harig 2003-07-30 13:30:46 EDT
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.)
Comment 7 Ed Bailey 2003-07-31 13:45:11 EDT
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).
Comment 8 Stelian Pop 2003-08-01 06:05:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.