[CentOS] Filesystem backup?

Mon Jun 22 06:26:22 UTC 2009
Rafał Radecki <radecki.rafal at gmail.com>

Could You please explain what exactly that line means:

# dump 0f - / | (cd /seconddisk; restore -rf -)

You are very helpful.

With regards,
R.

2009/6/21 Robert Heller <heller at deepsoft.com>

> At Sun, 21 Jun 2009 15:06:35 +0200 CentOS mailing list <centos at centos.org>
> wrote:
>
> >
> >
> >
> > I think about using dd instead of dump? Is this an acceptable idea?
>
> *NO!*.  dd is NOT a proper backup tool...  I don't know where the idea
> that it is comes from (probably some really old UNIX sys admin book or
> something). dd has many uses, but it is not normally considered a
> backup tool.  Dump is a perfectly acceptable backup tool.  Dump was
> *designed* as the backup tool of choice. And it works just fine on a
> read-write file system, with the *standard* disclaimer that if used on
> a file system that is 'active', it (*like all backup tools*) will miss
> files that are being created/writen to during the backup.  Generally,
> the missed files will be gotten on a later backup.  On a normal, typical
> system, one would run the full backup at a 'quiet' time (a time frame
> of low activity, with the idea of avoiding having the backup interfere
> with normal activities and of normal activities interfering with the
> backup. On a typical normal system, the missed files will likely be
> things like the tail end of log files or various trasienent files (like
> mail queue files and the like).
>
> If you want a non-live mirror on the second does do this:
>
> Pick a 'quiet' time (say on a quiet Sunday morning) and do this:
>
> (Assume that /dev/sdb1 is the sole partition on the second disk):
>
> # mkfs.ext3 -L SecondDisk /dev/sdb1
> # mkdir /seconddisk
> # mount -v -t ext3 LABEL=SecondDisk /seconddisk
> # dump 0f - / | (cd /seconddisk; restore -rf -)
>
> At this point pick out a good book to read and get comfortable and read
> a chapter or three or you can do whatever you would do to kill some time
> -- ie go for a walk (or walk the dog), play a game of hoops or go for a
> swim or whatever.  I am assuming that the disk is probably good sized,
> so full dump may take some time.  You could stare at the screen for an
> hour, if that floats your boat...  Dump will display a progress report
> every 5 minutes.
>
> # umount -v /seconddisk
>
> Now create a script (Let's call it '/usr/local/sbin/dailybackup'):
>
>
> #!/bin/sh
> /sbin/e2fsck -C -T -a LABEL=SecondDisk
> mount -v -t ext3 LABEL=SecondDisk /seconddisk
> rsync -v -a -x -H --delete --delete-after --exclude=lost+found/ /
> /seconddisk
> umount -v /seconddisk
>
>
>
> # chmod +x /usr/local/sbin/dailybackup
>
> Now create a daily cron job:
>
> # crontab -e
>
> Add the line:
>
> 10 0 * * * /usr/local/sbin/dailybackup
>
>
> And you are all set.  Once a day an 10 past midnight, the backup disk
> will be sync'ed to the live system disk.  Every morning you will get a
> message from cron with the output.
>
> If you really want to, you can change the '0' above to '0,6,12,18' and
> the sync'ing will happen every 6 hours.  This is *probably* overkill.
>
>
>
> >
> > 2009/6/21 Robert Heller <heller at deepsoft.com>
> >
> > > At Sun, 21 Jun 2009 11:49:09 +0200 CentOS mailing list <
> centos at centos.org>
> > > wrote:
> > >
> > > >
> > > >
> > > >
> > > > Hi all. I'm currently having a following problem: I have only ssh
> > > connection
> > > > to a CentOS 5.2 system, there are two harddiscs on it. One stores the
> > > system
> > > > (/ filesystem) and the other should be used to help restore the
> system in
> > > > case of first disks' failure. I thought that maybe dump would be a
> good
> > > > utility to make it. But in only works on read-only filesystems. In
> one
> > >
> > > Dump works just fine on a read-write file system.  There is the pretty
> > > much standard limitation (that applies to *all* backup methods) that
> > > when backing up an 'active' file system: there will always be files
> that
> > > will miss the backup because they were being written during the backup
> > > process.
> > >
> > > > article I've read that making a snapshot of the / filesystem (then it
> > > > wouldbe read-only) and backing it could help. But aren't snapshots
> > > limited
> > > > to logical volumes (LVM)?  My friend told me to use rsync to back up
> the
> > > > entire / filesystem to the second disk and then in case o failure the
> > > system
> > > > from the copy should boot ok.
> > > >
> > > > Could anyone provide any suggestions? I don't have physical contact
> with
> > > the
> > > > machine so for example RAID 1 isn't a possible option/
> > > >
> > > > Any help will be very kindly appreciated.
> > >
> > > Make an initial dump to get the base system copied, then set up a cron
> > > job to sync the disks once a day (or more frequently) with rsync.
> > >
> > > >
> > > > With regards,
> > > > R.
> > > >
> > > > MIME-Version: 1.0
> > > >
> > > > _______________________________________________
> > > > CentOS mailing list
> > > > CentOS at centos.org
> > > > http://lists.centos.org/mailman/listinfo/centos
> > > >
> > > >
> > >
> > > --
> > > Robert Heller             -- 978-544-6933
> > > Deepwoods Software        -- Download the Model Railroad System
> > > http://www.deepsoft.com/  -- Binaries for Linux and MS-Windows
> > > heller at deepsoft.com       --
> http://www.deepsoft.com/ModelRailroadSystem/
> > >
> > > _______________________________________________
> > > CentOS mailing list
> > > CentOS at centos.org
> > > http://lists.centos.org/mailman/listinfo/centos
> > >
> >
> > MIME-Version: 1.0
> >
> > _______________________________________________
> > CentOS mailing list
> > CentOS at centos.org
> > http://lists.centos.org/mailman/listinfo/centos
> >
> >
>
> --
> Robert Heller             -- 978-544-6933
> Deepwoods Software        -- Download the Model Railroad System
> http://www.deepsoft.com/  -- Binaries for Linux and MS-Windows
> heller at deepsoft.com       -- http://www.deepsoft.com/ModelRailroadSystem/
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos/attachments/20090622/6754285e/attachment-0005.html>