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>