Re: Backup problem of a linux system
From: Fred Phase (fredphase_at_my-deja.com)
Date: 04/29/04
- Next message: A. L. Meyers: "Re: State of the GnuCash project, a call for help"
- Previous message: Chris: "Syslog-ng - log to different file"
- In reply to: MatB: "Re: Backup problem of a linux system"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 29 Apr 2004 01:51:01 -0700
MatB <miagiCutThis@tiscali.it> wrote in message news:<Xns94D9BDB4C5E3AmiagiCUTtiscaliit@62.153.159.134>...
> Hi Fred, thanks for the answer.
> So, your recovery plan looks like:
> - get a new hard drive or clean up the corrupted one
Yes.
You will also need the Knoppix CD and the Mandrake Move CD. These run
whole Linux systems off a CD ROM while your hard drive is on the
operating table. Mandrake Move IMHO has the best disk partitioning
tool and Knoppix I find better for just about anything else.
> - install linux on it
Specifically the _same_ distro/version of Linux on it, but a minimum
install. However, with a bit of coaxing it is possible to replicate
the whole system. There are only a few files that need adjusting. More
on that later...
> - update the folders with the backup data, possibly with the target
> partition not being the running one
Yes, simply overwrite the dummy Linux install with the old files. Keep
a copy of /etc/fstab from the dummy Linux install as this may provide
you with important clues later on. Also keep /boot/grub/grub.conf or
/etc/lilo.conf as they may also provide clues if your new partition
arrangement is different to the original.
> A few questions arise from this schema:
> - if, as you wrote, I backup everything and restore the data to partitions
> that have a different size, i think that i could mess up some special file
> (correct me if i'm wrong) that contain references to the phisical location
> on the disk. I suppose that in /boot something like this should be present.
> How do you deal with it?
The actual size of the restored partitions doesn't matter, as long as
it all fits and meets your expected future storage requirements. What
does matter is the physical names of the partitions. These are in the
/etc/fstab file. I always try to keep the same partition arrangement
e.g. /boot is on /dev/hda1 and / is on /dev/hda5 (extended partition)
as the original system. If it is different then it is important to
understand how it is different and be able to adjust the recovered
/etc/fsab accordingly.
The next challenge is to make the thing boot. If you are overwriting a
dummy Linux install with the recovered data then it should already
boot. Most Linux distos have a rescue mode with the install disks
which can re-install the boot loader. You will need to do this so the
that the BIOS knows what to do when you switch the machine on.
> - What about opened files like a mysql database? Do i get dirty data, should
> i exclude them and dump explicitly the whole db?
Yes, you will get problems. What I do is run a cron job on the server
being backed up once a day to dump the whole MySQL database to a file
(with drop tables). This can then be used to re-insert clean data into
MySQL once the restore is complete.
Here is the script I use...
#!/bin/sh
rm -f /root/mysql.full.dump.sql.gz
mysqldump --user=postnuke --password=SECRET --all --add-drop-table \
--flush-logs --all-databases > /root/mysql.full.dump.sql
gzip /root/mysql.full.dump.sql
exit 0
I keep it in /usr/local/sbin and not readable by anyone except root as
it contains the MySQL root password :-O
It stores the file in /root, again because it is very private.
>
> I like your file oriented approach, because I don't have to put offline the
> machine and i could do a nice cronjob for it. However it looks to me that if
> done incorrectly i will get a dirty-installed system.
Yes, only if done incorrectly ;-) Most problems will be quite evident
because the system won't boot (fstab, grub or lilo need adjusting).
Just make sure you can recover any database with cleanly backed up
data if there is a risk involved in just backing up files which could
be changing. If it is a mail server then MailDir format (1 email=1
file instead of 1 inbox=1 file) will offer more safety.
Hope that helps :-)
- Next message: A. L. Meyers: "Re: State of the GnuCash project, a call for help"
- Previous message: Chris: "Syslog-ng - log to different file"
- In reply to: MatB: "Re: Backup problem of a linux system"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
