[Discuss] Dropping obsolete commands (Linux Pocket Guide) (dump/restore)

[j.natowitz at rcn.com (Jerry Natowitz)]

On 11/10/15 12:02, Bill Bogstad wrote:
> On Tue, Nov 10, 2015 at 11:24 AM, Chuck Anderson <cra at wpi.edu> wrote:
>> On Tue, Nov 10, 2015 at 12:06:03PM +0000, Edward Ned Harvey (blu) wrote:
>>> If you want to backup the entire filesystem in such a way that all the above is unnecessary - you instead boot from rescue media, partition & format the hard disk, and simply run "restore" and boot back into the restored system as if no problem had ever occurred, then assuming you're using ext filesystems, you need dump & restore. (Or you need storage on some snapshotting storage system external to the system you're restoring.)
>>
>> According to Ted Ts'o (filesystem developer), it is NOT a recommended
>> way to backup your filesystem:
>>
>> http://www.gossamer-threads.com/lists/linux/kernel/1197768
>>
>> "It does read the mounted block device directly, and so it's certainly
>> not a _recommended_ way to back up your ext4 filesystem. It should
>> work, though, since it just uses the high-level libext2fs functions
>> --- and a while back, I think I did a quick test and found that it
>> really did work. So I'm not sure what broke, but it might not be that
>> hard to fix. That being said, it may not be worth it to fix it, since
>> with delayed allocation, backups using dump will be even more
>> unreliable than they were before. " - Ted Ts'o
>
> Note that this is from 2010 AND it was for a live (mounted
> filesystem).  I've used the rsync method myself to copy a system disk,
> but I've always been worried that if I didn't get the options just
> right I might lose an ACL or some other extended attribute and not
> know it.    "Runs fine" doesn't mean some subtle problem (possibly
> security related?) hasn't been created.  For stuff in /home, I worry
> much less about this and see no reason not to use rsync.
>
> I'm about to add an SSD to a system with an HD and I'm going to give
> "dump | restore" a try.
> One interesting feature of the Linux dump is that you can specify
> inodes not to backup and if it is a directory the whole subtree will
> not be copied.   The system in question has /, /var, and /home all on
> one partition and I'm going to split them up in the new configuration
> so this will be helpful.   /home is going to stay on the HD while / is
> moving to the SSD.  Not sure about /var yet.

Most of my experience with dump and restore was on Solaris, and SunOS 
before that.  The nice thing about dump is that it could read an 
unmounted filesystem.  The bad thing about dump is that it seemed to get 
more errors when dumping a live filesystem with a lot of activity.

As I recall, 20 errors and the dump would fail.  You could alter that 
value, but the big issue is that dump was not built to recover from 
filesystem changes.  rsync, on the other hand, was better about it.

One other feature of dump is that it supported both full and incremental 
dumps, so that restoring a filesystem to a state that it had in the past 
was possible.  Not quite as elegant as snapshots, but definitely a 
useful feature when something on a system gets broken, and all that is 
know is "it worked three weeks ago".

I did full backups monthly on my main systems, quarterly or yearly on 
quiescent systems.  I saved them all.  I did weekly incrementals, saving 
the last 6 of them.  I did daily incrementals (on the weeklies), saving 
the last 12.  Which seemed like overkill, but saved the butts of some 
cowboy developers a number of times.

One caveat - dump and restore are very filesystem specific.  On Solaris 
they were known as ufsdump/ufsrestore.  That's all they work on.

BTW: keep telnet around.  It is a quick way to ascertain what is on a 
socket, since so many protocols still use it for control purposes.


	Jerry Natowitz
===>    j.natowitz (at) rcn.com
if rcn.com bounces, try gmail.com

> Bill Bogstad
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>