FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 03-01-2010, 05:29 PM
Jeffrey Metcalf
 
Default Risks of backing up live mounted filesystems using dump(8)

Hi,

I'm hoping I can start a brief thread discussing the potential risks involved with backing up live mounted (RW) ext2/3/4 filesystems using dump(8). Here are the reasons I ask this:

1. My understanding is that it is safest to dump unmounted filesystems to ensure all buffers are flushed and all files on the device are consistent and up-to-date. However...
2. Performing filesystem dumps can be a time consuming process and therefore taking the extra time to boot to level 1 and mount / RO to access utilities just adds additional work. Booting to read-only media with utilities is just as time consuming.
3. If / is mounted RO, it is not possible to write records to /etc/dumpdates as would occur with /sbin/dump -u. Obviously one can mount / RW to dump other filesystems, but it still seems awkward and time consuming to have to drop to level 1 anyway, which may be necessary to unmount and dump /home say.
4. Obviously dropping the runlevel to 1 or booting to RO media such as Fedora Live also prevents anyone other than root from using the system.

Clearly dumping backups of live mounted RW filesystems will not guarantee that file data written between dump passes are completely consistent, but I am looking to better understand the risks. Clearly databases on filesystems being dumped should be closed and unmounted due to the extra software-level buffering that many databases perform, but if the mounted filesystems are generally idle, are there any gotchas one can expect when restoring such backups. Also, my filesystems are all ext4 on Fedora Core 12. Any additional protection that the journaling and journal checksum features can provide in this regard?

Cheers,

-J




--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-01-2010, 09:23 PM
Phil Meyer
 
Default Risks of backing up live mounted filesystems using dump(8)

On 03/01/2010 11:29 AM, Jeffrey Metcalf wrote:
> Hi,
>
> I'm hoping I can start a brief thread discussing the potential risks involved with backing up live mounted (RW) ext2/3/4 filesystems using dump(8). Here are the reasons I ask this:
>
> 1. My understanding is that it is safest to dump unmounted filesystems to ensure all buffers are flushed and all files on the device are consistent and up-to-date. However...
> 2. Performing filesystem dumps can be a time consuming process and therefore taking the extra time to boot to level 1 and mount / RO to access utilities just adds additional work. Booting to read-only media with utilities is just as time consuming.
> 3. If / is mounted RO, it is not possible to write records to /etc/dumpdates as would occur with /sbin/dump -u. Obviously one can mount / RW to dump other filesystems, but it still seems awkward and time consuming to have to drop to level 1 anyway, which may be necessary to unmount and dump /home say.
> 4. Obviously dropping the runlevel to 1 or booting to RO media such as Fedora Live also prevents anyone other than root from using the system.
>
> Clearly dumping backups of live mounted RW filesystems will not guarantee that file data written between dump passes are completely consistent, but I am looking to better understand the risks. Clearly databases on filesystems being dumped should be closed and unmounted due to the extra software-level buffering that many databases perform, but if the mounted filesystems are generally idle, are there any gotchas one can expect when restoring such backups. Also, my filesystems are all ext4 on Fedora Core 12. Any additional protection that the journaling and journal checksum features can provide in this regard?
>
> Cheers,
>
> -J
>
>
>
>
>

Many here have done this many times. Your risk assessment is acurate.
As long as there are no writes pending, the dumps/backups or good.

In disaster recovery, a cold backup is preferred over nothing, right?

In the dozen or so times when I personally have had to restore broken
systems from tape, whether that was Veritas, dump, tar, or cpio, the
basics are the same:

Re-install the system to base.
Recover from tape.
Reboot.
Pray.

If those steps are acceptable, then you are on track.

Also, if you are interested in single file recovery, cold backups are
actually the best for most things.

These days, there are several interesting alternatives to cold backups.
The best of those get between the operating system driver and the disk
itself.

When the first snapshot is triggered, the disk drivers are forced to
write to temporary space for the duration of the snapshot, and then the
changes are merged back in.

From that moment on, the special backup software tags all disk blocks
that get modified going forward. When the next snapshot is triggered,
not only do the disk writes go to temporary space, but only the tagged
blocks are replicated, thus giving a very near perfect incremental backup.

As you can guess, this works with raw database partitions as well.

Combine that type of snapshot with a memory dump of the system at the
moment the snapshot is triggered, and you can migrate the system to any
point in time a snapshot was performed.

Move those critical applications to Virtual Machines, and you can 'live
migrate' a system back to any point in time when a ' pause VM/memory
dump/snapshot' occurred. Neat stuff!

I give these examples only to show the progress in general from the cold
backups of yesteryear to what is available and in use today.

Good luck!


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-01-2010, 09:51 PM
Alan Cox
 
Default Risks of backing up live mounted filesystems using dump(8)

Journals make the problem far worse.

On restore you will restore a journal log no longer related to whats on
the media, then risk replaying it and causing further damage.

Block reallocation is also nasty with a dump done that way because you
may end up with undetected data corruption including leaks of data
between uids.

A file system based backup is a good deal safer.

You should also know if it works or not. Sct (one of the ext2 designers)
always said there were three approaches to backups

- "I ought to do it" (people who've not had a catastrophic failure)
- "We back it up" (people who've not had a catastrophic restore failure)
- "We back it up and test the backup/restore process
regularly" (battle scarred veterans)

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-01-2010, 10:49 PM
Mike McCarty
 
Default Risks of backing up live mounted filesystems using dump(8)

Jeffrey Metcalf wrote:
> Hi,
>
> I'm hoping I can start a brief thread discussing the potential risks involved with backing up live mounted (RW) ext2/3/4 filesystems using dump(8). Here are the reasons I ask this:
>
> 1. My understanding is that it is safest to dump unmounted
> filesystems to ensure all buffers are flushed and all files on the
> device are consistent and up-to-date. However...
> 2. Performing filesystem dumps can be a time consuming process and
> therefore taking the extra time to boot to level 1 and mount / RO to
> access utilities just adds additional work. Booting to read-only
> media with utilities is just as time consuming.

If you put the filesystem of interest on its own partition, then
ISTM you can mount -o remount,ro that one file system, and it should
remain static during the backup. All data will still be available,
though unmodifiable. Clearly, one would need to do something like
an lsof to ensure that nobody is using it when the remount takes
place.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){pri ntf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-01-2010, 11:35 PM
Jeff Metcalf
 
Default Risks of backing up live mounted filesystems using dump(8)

<alan@lxorguk.ukuu.org.uk> wrote:

Journals make the problem far worse.

Good to know and understand.


On restore you will restore a journal log no longer related to whats on
the media, then risk replaying it and causing further damage.

This makes sense. It was not clear to me that the journal was being stored in the "dump data". If so, can it be disabled immediately before dump(8) and then reenabled immediately after? Some highly volatile file systems (like the Oracle file-based database) claim to support hot backups. Assuming their marketing claim is actually valid, what would it take for the ext filesystem to support it?

Block reallocation is also nasty with a dump done that way because you
may end up with undetected data corruption including leaks of data
between uids.

With all these issues, it seems like 'man 8 dump' should advise against its use with mounted filesystems. The only mention of mount status is in the usage description, which indicates that mount points can only be used instead of block device names when calling dump when the filesystem is mounted.

A file system based backup is a good deal safer.

Isn't dump(8) considered a filesystem based backup? Are you refering to something more specialized?


Thanks.



--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-02-2010, 12:05 AM
Paul
 
Default Risks of backing up live mounted filesystems using dump(8)

Jeff Metcalf wrote:
> A file system based backup is a good deal safer.
>
> Isn't dump(8) considered a filesystem based backup? Are you refering to something more specialized?
>
>
A file system based backup is one that uses the file system to pick up
the blocks of a file and store it contiguously in the backup. dump
literally dumps the raw disk contents to a file as a stream, complete
with any fragmentation and what-have-you.


--


Paul


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-02-2010, 02:30 AM
Mike McCarty
 
Default Risks of backing up live mounted filesystems using dump(8)

Jeff Metcalf wrote:
> <alan@lxorguk.ukuu.org.uk> wrote:

[...]

> A file system based backup is a good deal safer.
>
> Isn't dump(8) considered a filesystem based backup? Are you refering to something more specialized?

Yes, it is. I suspect he meant a files based backup. With
dump, what one gets is a dump of the file system itself,
as opposed to the data it contains. With a files based
backup, one gets a copy of the data saved, but not the
file system. So, for example, using tar, or cpio, one can
back up a system using ext3, and recover to a system which
uses reiserfs. One cannot do that with dump and restore,
which store the file system itself. The dump and restore
work at a lower level than files based backup.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){pri ntf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-02-2010, 02:40 AM
Cameron Simpson
 
Default Risks of backing up live mounted filesystems using dump(8)

On 01Mar2010 21:30, Mike McCarty <Mike.McCarty@sbcglobal.net> wrote:
| Jeff Metcalf wrote:
| > <alan@lxorguk.ukuu.org.uk> wrote:
| > Isn't dump(8) considered a filesystem based backup? Are you refering to something more specialized?
|
| Yes, it is. I suspect he meant a files based backup. With
| dump, what one gets is a dump of the file system itself,
| as opposed to the data it contains. With a files based
| backup, one gets a copy of the data saved, but not the
| file system. So, for example, using tar, or cpio, one can
| back up a system using ext3, and recover to a system which
| uses reiserfs. One cannot do that with dump and restore,
| which store the file system itself. The dump and restore
| work at a lower level than files based backup.

I was pretty sure restore pulls "files" from the dump and writes to an
arbitrary filesystem (eg xfs or reiser etc). Dump accesses the filesystem
directly, but restore doesn't have that issue.
--
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

SGI's are like F18's.
SUN's are like F16's.
Mac's are like Cessna 150's.
PC's .... Well....PC's are like a bumble bee with only one wing.
- Kip J. Mussatt <hampster@matt.ksu.ksu.edu>
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-02-2010, 03:33 AM
Jeffrey Metcalf
 
Default Risks of backing up live mounted filesystems using dump(8)

>
> If you put the filesystem of interest on its own partition, then
> ISTM you can mount -o remount,ro that one file system, and it should
> remain static during the backup. All data will still be available,
> though unmodifiable. Clearly, one would need to do something like
> an lsof to ensure that nobody is using it when the remount takes
> place.
>
> Mike
>

Thanks Mike. Could be useful for my needs. Just curious. Would such a mount -o remount,ro flush any dirty filesystem buffers like sync, or would it discard them.

Cheers,

-J




--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 03-02-2010, 03:45 AM
Russell Miller
 
Default Risks of backing up live mounted filesystems using dump(8)

On Monday 01 March 2010 08:33:20 pm Jeffrey Metcalf wrote:
> > If you put the filesystem of interest on its own partition, then
> > ISTM you can mount -o remount,ro that one file system, and it should
> > remain static during the backup. All data will still be available,
> > though unmodifiable. Clearly, one would need to do something like
> > an lsof to ensure that nobody is using it when the remount takes
> > place.
> >
> > Mike
>
> Thanks Mike. Could be useful for my needs. Just curious. Would such a
> mount -o remount,ro flush any dirty filesystem buffers like sync, or would
> it discard them.
>
In my experience, a remount can be done on a running system, so I imagine that
loss of data isn't something designed into that particular operation.

I've done it successfully on each server in a running cluster of about 50 when
I wanted to set it to noatime.

--Russell
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 

Thread Tools




All times are GMT. The time now is 04:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org