Do automated full backup in custom runlevel
Creating your own run-level HACK First, a word of caution. Do not do this on a production machine, period! This section is a VERY dirty hack that you should only use on a virtual machine you can experiment with, or a machine you don't mind rebuilding.. It is always a good idea to do testing inside of a virtual machine before doing something that could potentially render a box unbootable. This is a very quick and dirty way to alter a run-level for the purposes of learning, but perhaps you can get some ideas from it that can be used in a more production-oriented way. Ideally, some of the readers of this article will post some production quality hacks to creating custom run levels.
cd to /etc/rc.d/rc4.d/
do a sanity check to make sure you are running Red Hat: cat /etc/redhat-release backup existing run-level directory:
mkdir /tmp/rc4.d.original/ cp /etc/rc.d/rc4.d/* /tmp/rc4.d.original/ rm -f /etc/rc.d/rc4.d/*
At this point
cp /etc/rc.d/rc1.d/* /etc/rc.d/rc4.d/
We have now copied the run-level scripts for single user mode into our own custom run-level 4. We can hijack the the S99single script and tell it to do something different. In this example, we are going to write a custom Python script that gets forked to the background and backs up the machine over rsync. Let's edit that file we copied:
vim /etc/rc.d/rc4.d/S99single
Change the last part of it to look like this:
# Now go to the single user level. echo $"Telling INIT to go to single user mode." echo "This is a custom code. Forking custom script" /custom.py & exec init -t1 S
We've inserted two lines. One echoes that we are forking off a custom script. The second line forks a python script, shown below, that backs up the machine via rsync. Note that this assumes you have set up ssh keys on the remote backup server.
custom.py script: <python>
- !/usr/bin/env python
import time import subprocess
rsync = "rsync -av / 10.0.1.3:/Volumes/Backup/server_backup/" network = "service network start" init = "init 3"
cmds = [rsync, network]
def single_user_backup():
"""Starts network service, creates backup and returns to init 3"""
try:
subprocess.call(network, shell=True)
subprocess.call(rsync, shell=True)
finally:
subprocess.call(init, shell=True)
def main():
"""Runs program""" print "sleeping for 60 seconds" #time.sleep(60) #Gives machine time to quiesce single_user_backup()
main() </python> The main function runs a sleep command for 60 seconds, just to give the single user mode scripts time to quiesce the box. Remember, this script is forked to the background. Next, function single_user_backup attempts to start network services and run rsync to remotely back up the whole / volume to another server. This is obviously crude and there will be lots of errors trying to back up /proc, for example, but it give you an idea of how an automated backup could work with a custom run-level. Finally, the machine gets called back to init 3, which is console only multi-user mode.
Tip: Again, this is just an idea for a backup script, but not one I would actually run in production in my wildest dreams. One problem with this technique is that because of symbolic links in run level 1, we actually, changed run level 1 and our run level 4. This is not acceptable, obviously, for any sane user, but it is acceptable as a way to have fun with a disposable virtual machine! If you can think of a more realistic backup script that would work from a custom run-level, I would love to see it. Create a how to on your blog, and then post a response to this article. Also, it would interesting to see other things such as database backups and migration done with custom run-levels as well. Leave a comment and let me know what you'd do.
SRC: http://www.redhatmagazine.com/2008/06/03/run-levels-create-use-modify-and-master/
Note: this is a bit dirty and the of this server are also stopped. if you search a quick, dirty and elegant way to solve this problem, look at my lvm backup scripts
http://www.bitbull.ch/dl/scripts/lvm_back.sh
http://www.bitbull.ch/dl/scripts/lvm-snap-sync.sh
