|
|
Never restore files back into their original location! Doing so is wrong and can crash your system even worse than a regular crash. If you use tar or dump, always create a special RESTORE directory wherein you put your restored files in. Then as you need to place system or data files back into place, just use cp - a to copy them from place to place.
Also, when restoring system files, you must be in single-user mode. You may have to remount your root partition in r/w mode; however, this is a must for a stable full restore.
Tar is very straightforward. If done from a file, it looks like this:
# pwd /root/RESTORE # ls home.tgz # tar xzvf home.tgz home/bob/ home/bob/.kde/ home/bob/.kde/Autostart/ [...] home/bob/.htpasswd-BAJ home/bob/.Xauthority # cd ./home # pwd /root/RESTORE/home
We put the backup tar-ball into /root/RESTORE/, untarred it, and cd'd into /root/RESTORE/ home/ before we starting doing file copying around the system.
Un-tarring from tape usage is pretty much the same, but you should do so to a clearly marked RESTORE directory of some type. Here's an example of rewinding the tape with mt, then restoring some files for a user's (bob) tape. The operation shows how you can have tar eXtract with compreZsion Verbosely (xzv) from the file /dev/tape, into the directory /home/bob/ RESTORE/:
# mt -f /dev/tape rewind # tar xzvf /dev/tape /home/bob/RESTORE/
It's that simple.
For system-wide restores, the same words of wisdom regarding the RESTORE directory apply here. The idea is to restore files into a temporary holding place that is clear in its purpose, but not viewable by the world. This is why we're putting the RESTORE directory in /root/ in this case:
# cd /root/RESTORE/
The usage of the dump package's restore command is rather strange. It's a real time, interactive restore where you are in the restore shell, interacting with the backup file in real time. The idea is that you look around the inside of the backup file, pass the restore package parameters, and have it add the files to your restore (or extraction list). Then when you're ready to restore, you just type extract and the files pop out of the dump archive and into your current directory with a new relative path from your current location.
It's easier to show than to describe:
This restore command we tell to go into interactive mode (-i) and to source (-s) the first file on the tape. This source file number is simply the sequential order of the data files on the tape. If we had three backed up partitions on the system of /dev/hda2 /dev/hda3 and /dev/hda6, they were laid down to tape in that order, and we wanted to restore from the second partition file on tape, we would tell restore to source -s2 this time.
Now that we're in the restore environment looking at the dump archive in real time, we can browse it as if it were a live file system:
restore > ls .: System.map lost+found/ System.map-2.4.18-24.7.x message System.map-2.4.18-26.7.x module-info System.map-2.4.18-27.7.x module-info-2.4.18-24.7.x System.map-2.4.18-27.7.xsmp module-info-2.4.18-26.7.x System.map-2.4.18-3smp module-info-2.4.18-27.7.x boot.b module-info-2.4.18-27.7.xsmp chain.b module-info-2.4.18-3smp config-2.4.18-24.7.x os2_d.b config-2.4.18-26.7.x vmlinux-2.4.18-24.7.x config-2.4.18-27.7.x vmlinux-2.4.18-26.7.x config-2.4.18-27.7.xsmp vmlinux-2.4.18-27.7.x config-2.4.18-3smp vmlinux-2.4.18-27.7.xsmp grub/ vmlinux-2.4.18-3smp initrd-2.4.18-24.7.x.img vmlinuz initrd-2.4.18-26.7.x.img vmlinuz-2.4.18-24.7.x initrd-2.4.18-27.7.x.img vmlinuz-2.4.18-26.7.x initrd-2.4.18-27.7.xsmp.img vmlinuz-2.4.18-27.7.x initrd-2.4.18-3smp.img vmlinuz-2.4.18-27.7.xsmp kernel.h vmlinuz-2.4.18-3smp restore > cd grub/ restore > ls ./grub: device.map jfs_stage1_5 stage1 e2fs_stage1_5 menu.lst stage2 fat_stage1_5 minix_stage1_5 tnt_whitemount.xpm.gz ffs_stage1_5 reiserfs_stage1_5 vstafs_stage1_5 grub.conf splash.xpm.gz xfs_stage1_5
After we find what we're looking for (grub.confin this case), we add it to our archive extraction list, add any other files or directories that we might want, and then we extract them.
restore > add grub.conf restore > extract You have not read any volumes yet. Unless you know which volume your file(s) are on you should start with the last volume and work towards the first. Specify next volume # (none if no more volumes): 1 set owner/mode for '.'? [yn] y restore > quit
Now we're out of the interactive restore session and back in our shell:
# pwd /root/RESTORE # ls -la total 1204 drwxr-xr-x 3 root root 4096 Mar 15 04:00 . drwxr-xr-x 29 root root 4096 Mar 15 04:00 .. drwxr-xr-x 2 root root 4096 Apr 10 2003 grub # cd grub/ # ls grub.conf #ls -la total 12 drwxr-xr-x 2 root root 4096 Apr 26 06:29 . drwxr-xr-x 3 root root 4096 Apr 26 06:29 .. -rw-r--r-- 1 root root 884 Mar 21 23:13 grub.conf # pwd /root/RESTORE/grub #
That's about all there is to restore. Just remember that you need to add all of the files that you want while in the restore shell before you run the extract command. Also, remember that it will create a relative set of directories to contain the file(s) that you added for extraction. This is another reason that we use a RESTORE directory; it's safer. We wouldn't want to happen to be in the / directory and extract backup files over top live operating OS files. That would be a bad thing.
To restore a backed up database from a mysqldump-created .sql file requires only a one line command:
# mysql < all-databases_2004-03-15.sql
Just make sure that your database is running when you issue this mysql client command. If the mysql client cannot talk to the mysql server database, it will not be able to recreate all the tables and data.
To restore a backed-up database from mysqlhotcopy cloned files (or restored files from tape), use the following command:
# /bin/rm -rf /root/mysql-backup/*old
This makes sure that any old copies of databases are wiped out. Then shut off the mysqld service, copy the files back, and turn the service back on like this:
# /etc/init.d/mysqld stop Stopping MySQL: [ OK ] # cp -af /root/mysql-backup/* /var/lib/mysql / # /etc/init.d/mysqld start Starting MySQL: [ OK ]
The database is now restored and operational.
|
|