Back-up and Restore:
Having a backup depends upon the scope of your server, for a MySQL server you need to backup /var/lib/mysql
#!/bin/bash
rm /opt/backup/set_a/server/gfps04/mysql.* -Rf
find /var/lib/mysql -mtime -31 -depth \! -type d > /tmp/modified_mysql.files
tar cT /tmp/modified_mysql.files > /opt/backup/set_a/server/gfps04/mysql.`date '+%d%b'`.tar
gzip -9f /opt/backup/set_a/server/gfps04/mysql.`date '+%d%b'`.tar
Restoration will require you more likely to use a separate test server, first examine the files to be restored so you may not damage the existing file system. If you are certain then you may copy the files in any way, but best is via scp (secure file copy) to maintain file ownership and permissions.
File System Health:
Place your Red Hat Enterprise 4 disk # 1 to CDROM drive and reboot. Following the loaded prompt enter: linux rescue
If it ask for file system mount answer NO. This will let you check file systems freely without any hard. Mount file system or choosing no is preferred only if you intend to change settings or edit files on your system.
Afterwards the bash prompt will appear and now your ready to examine your file system. This applicable on many cases, such as before having a backup, or having a corrupted disk and you are attempting to recover from it.
bash# fsck /dev/hda1 bash# fsck /dev/hda2
If your hard disk is an ide it will be /dev/had device, for scsi or sata it will be /dev/sda. Fsck might find corrupted files, if so it will ask you to fix it, press “Y” for yes if it does check inconsistency. After having checked all file systems, you may reboot.
Automatic Backup:
As you learned in CRON you may create a script to backup necessary service location. You may design your very own backup system as long as you can restore it.
[root@ server01 ~]# mkdir scripts
[root@ server01 ~]# mkdir /opt/backup
[root@ server01 ~]# cd scripts
[root@ scripts]# vi sql_backup.sh
#!/bin/bash
rm /opt/backup/mysql.* -Rf
find /var/lib/mysql -mtime -31 -depth \! -type d > /tmp/modified_mysql.files
tar cT /tmp/modified_mysql.files > /opt/backup/mysql.`date '+%d%b'`.tar
gzip -9f /opt/backup/mysql.`date '+%d%b'`.tar
[root@ scripts]# vi /var/spool/cron/root
30 15 * * * sh /root/scripts/sql_backup.sh
[root@ scripts]# chmod 744 sql_backup.sh
You may want to try to script yourself by executing sh sql_backup.sh
[root@ scripts]# sh sql_backup.sh
Monitor the disk Space: df –h -7
Monitor system Load: [root@ server01 ~]# top
To monitor CPU Usage press Shift + P / Memory Usage press Shift + M
If ever you had pin point a service that is causing trouble, all you had to do is pin point the PID number. And using kill command to terminate the service.
[root@ server01 ~]# kill 8888
8888 is assumed to be the PID; you may check your own to get real service number. A leaky program such as those needing updates can cause memory or CPU leakage leaving it to use more memory or CPU resources than it should.
Having a backup depends upon the scope of your server, for a MySQL server you need to backup /var/lib/mysql
#!/bin/bash
rm /opt/backup/set_a/server/gfps04/mysql.* -Rf
find /var/lib/mysql -mtime -31 -depth \! -type d > /tmp/modified_mysql.files
tar cT /tmp/modified_mysql.files > /opt/backup/set_a/server/gfps04/mysql.`date '+%d%b'`.tar
gzip -9f /opt/backup/set_a/server/gfps04/mysql.`date '+%d%b'`.tar
Restoration will require you more likely to use a separate test server, first examine the files to be restored so you may not damage the existing file system. If you are certain then you may copy the files in any way, but best is via scp (secure file copy) to maintain file ownership and permissions.
File System Health:
Place your Red Hat Enterprise 4 disk # 1 to CDROM drive and reboot. Following the loaded prompt enter: linux rescue
If it ask for file system mount answer NO. This will let you check file systems freely without any hard. Mount file system or choosing no is preferred only if you intend to change settings or edit files on your system.
Afterwards the bash prompt will appear and now your ready to examine your file system. This applicable on many cases, such as before having a backup, or having a corrupted disk and you are attempting to recover from it.
bash# fsck /dev/hda1 bash# fsck /dev/hda2
If your hard disk is an ide it will be /dev/had device, for scsi or sata it will be /dev/sda. Fsck might find corrupted files, if so it will ask you to fix it, press “Y” for yes if it does check inconsistency. After having checked all file systems, you may reboot.
Automatic Backup:
As you learned in CRON you may create a script to backup necessary service location. You may design your very own backup system as long as you can restore it.
[root@ server01 ~]# mkdir scripts
[root@ server01 ~]# mkdir /opt/backup
[root@ server01 ~]# cd scripts
[root@ scripts]# vi sql_backup.sh
#!/bin/bash
rm /opt/backup/mysql.* -Rf
find /var/lib/mysql -mtime -31 -depth \! -type d > /tmp/modified_mysql.files
tar cT /tmp/modified_mysql.files > /opt/backup/mysql.`date '+%d%b'`.tar
gzip -9f /opt/backup/mysql.`date '+%d%b'`.tar
[root@ scripts]# vi /var/spool/cron/root
30 15 * * * sh /root/scripts/sql_backup.sh
[root@ scripts]# chmod 744 sql_backup.sh
You may want to try to script yourself by executing sh sql_backup.sh
[root@ scripts]# sh sql_backup.sh
Monitor the disk Space: df –h -7
Monitor system Load: [root@ server01 ~]# top
To monitor CPU Usage press Shift + P / Memory Usage press Shift + M
If ever you had pin point a service that is causing trouble, all you had to do is pin point the PID number. And using kill command to terminate the service.
[root@ server01 ~]# kill 8888
8888 is assumed to be the PID; you may check your own to get real service number. A leaky program such as those needing updates can cause memory or CPU leakage leaving it to use more memory or CPU resources than it should.
Comments (0)
Post a Comment