[SLE] backup, repartition, and restore
Folks, I have SuSE 6.2 running on a box that I am using as a web server, dhcp server, samba server, firewall, NIS server, NFS server, and to IP Masquerade. It has a 10 gig HD in it... The first question, what is the ideal way to partation the drive? How much space should each partition have and how should each partition be mounted? The second question: (I have a DAT drive) what is the best way to back the whole box? --> tar cvf /dev/st0 / How do I restore the box once I have created the partitions and formated them? How do I boot the machine and what should the command line be to extract from the tape? Sam -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
Sam Carleton wrote:
Folks,
I have SuSE 6.2 running on a box that I am using as a web server, dhcp server, samba server, firewall, NIS server, NFS server, and to IP Masquerade. It has a 10 gig HD in it...
The first question, what is the ideal way to partation the drive? How much space should each partition have and how should each partition be mounted?
Two general approaches: 1. Make it one big partition from / onwards. This is really handy if you need to hassle later on with the sizes of the partitions. It makes the system vulnerable because the system can easily be brought to it's knees, if all diskspace is claimed 2. Give each major direcoty it's own partition: / /usr /usr/local /var to name a few. When you run out of disk space, it can be a pain to get increase it. For private desktops 1 is recommended. For infrastructure systems 2 is recommended.
The second question: (I have a DAT drive) what is the best way to back the whole box? --> tar cvf /dev/st0 /
One can not easily restore a *entire* system. Unless *all* disks are umounted. This is usually not possible. Even worse, restoring a *complete* system which was backed up while in a running state, can be dangerous! If you have a critical machine, then general approach is: 1. Do all you can to prevent your system from crashing: keep enough space for log files, keep the permissions of the system files proper, use a UPS to overcome a powerfailure, etc. 2. Backup the most important system and data files: /etc /boot /sbin/init.d. (I think these are the most important). After a crash, you will want these files at your fingertips Am I forgetting some? Good luck. Koos Pol ---------------------------------------------------------------------- S.C. Pol T: +31 20 3116122 Systems Administrator F: +31 20 3116200 Compuware Europe B.V. E: koos_pol@nl.compuware.com Amsterdam PGP public key available -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
On Fri, 31 Dec 1999, Koos Pol wrote:
Sam Carleton wrote:
Folks,
I have SuSE 6.2 running on a box that I am using as a web server, dhcp server, samba server, firewall, NIS server, NFS server, and to IP Masquerade. It has a 10 gig HD in it...
The first question, what is the ideal way to partation the drive? How much space should each partition have and how should each partition be mounted?
Two general approaches: 1. Make it one big partition from / onwards. This is really handy if you need to hassle later on with the sizes of the partitions. It makes the system vulnerable because the system can easily be brought to it's knees, if all diskspace is claimed
2. Give each major direcoty it's own partition: / /usr /usr/local /var to name a few. When you run out of disk space, it can be a pain to get increase it.
For private desktops 1 is recommended. For infrastructure systems 2 is recommended.
The second question: (I have a DAT drive) what is the best way to back the whole box? --> tar cvf /dev/st0 /
One can not easily restore a *entire* system. Unless *all* disks are umounted. This is usually not possible. Even worse, restoring a *complete* system which was backed up while in a running state, can be dangerous! If you have a critical machine, then general approach is: 1. Do all you can to prevent your system from crashing: keep enough space for log files, keep the permissions of the system files proper, use a UPS to overcome a powerfailure, etc. 2. Backup the most important system and data files: /etc /boot /sbin/init.d. (I think these are the most important). After a crash, you will want these files at your fingertips Am I forgetting some?
Ok your message prompted me to ask a few questions here. What do you consider to be the big danger in backing up a running system? I thought the great advantage (or one of them) of the ext2 filesystem is the ability to copy files that are in use by the system. If that is the case then where is the danger? Why can't you in the case of a major catastrophy do a basic install and then restore from tape? I'm not trying to cause arguments here I'm really curious. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Darren R. Weber drw@linuxfan.com ICQ# 2849193 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
weberdr@bellsouth.net said:
Ok your message prompted me to ask a few questions here. What do you consider to be the big danger in backing up a running system? I thought the great advantage (or one of them) of the ext2 filesystem is the ability to copy files that are in use by the system. If that is the case then where is the danger? Why can't you in the case of a major catastrophy do a basic install and then restore from tape?
Things can go wrong if data is being written and or files are being created during the backup. I'm assuming your talking about dump here. It does several passes before actually writing the partition data to whatever media you are using. During these passes it get directory, file and inode info. It uses this data to dump the partition. If you backup when the system is quiet you most likely will not have any problem. If there is a lot of write activity then the chances of having restore problems increase. I have backed up live file systems using dump for about 10 years (mainly Suns). The only time I had any problem was on a workstation where the user had a cron job which did a 'make clean; make' each night on a project with over 2GB of source, objects and executables. The user had been warned not to do this (it wasn't necessary) and when the disk died I couldn't restore it from the backup. I have successfully restored hundreds of times from dumps made on live systems with no problem. The rule is to do it regularly and when the system(s) are quietest. Regards, Roy -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
participants (4)
-
activex1＠one.net -
koos.pol＠nl.compuware.com -
tgdcuro1＠gd2.swissptt.ch -
weberdr＠bellsouth.net