" />
« décembre 2003 | Main | février 2004 »
/usr/local/psa/bin/psadump -F -f - | split -b 1000m - dump.backup your old plesk system and restore to another clean pesk system using
cat dump.* | /usr/local/psa/bin/psarestore -m map_file -s shells_map_file -f -
#!/bin/sh
# This script does personal backups to a rsync backup server. You will end up
# with a 7 day rotating incremental backup. The incrementals will go
# into subdirectories named after the day of the week, and the current
# full backup goes into a directory called "current"
# tridge@linuxcare.com
# directory to backup
BDIR=/home/$USER
# excludes file - this contains a wildcard pattern per line of files to exclude
EXCLUDES=$HOME/cron/excludes
# the name of the backup machine
BSERVER=owl
# your password on the backup server
export RSYNC_PASSWORD=XXXXXX
########################################################################
BACKUPDIR=`date %A`
OPTS="--force --ignore-errors --delete-excluded --exclude-from=$EXCLUDES
--delete --backup --backup-dir=/$BACKUPDIR -a"
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin
# the following line clears the last weeks incremental directory
[ -d $HOME/emptydir ] || mkdir $HOME/emptydir
rsync --delete -a $HOME/emptydir/ $BSERVER::$USER/$BACKUPDIR/
rmdir $HOME/emptydir
# now the actual transfer
rsync $OPTS $BDIR $BSERVER::$USER/current
backup to a spare disk
I do local backups on several of my machines using rsync. I have an
extra disk installed that can hold all the contents of the main
disk. I then have a nightly cron job that backs up the main disk to
the backup. This is the script I use on one of those machines.
#!/bin/sh
export PATH=/usr/local/bin:/usr/bin:/bin
LIST="rootfs usr data data2"
for d in $LIST; do
mount /backup/$d
rsync -ax --exclude fstab --delete /$d/ /backup/$d/
umount /backup/$d
done
DAY=`date " %A"`
rsync -a --delete /usr/local/apache /data2/backups/$DAY
rsync -a --delete /data/solid /data2/backups/$DAY
The first part does the backup on the spare disk. The second part
backs up the critical parts to daily directories. I also backup the
critical parts using a rsync over ssh to a remote machine.
mirroring vger CVS tree
The vger.rutgers.edu cvs tree is mirrored onto cvs.samba.org via
anonymous rsync using the following script.
#!/bin/bash
cd /var/www/cvs/vger/
PATH=/usr/local/bin:/usr/freeware/bin:/usr/bin:/bin
RUN=`lps x | grep rsync | grep -v grep | wc -l`
if [ "$RUN" -gt 0 ]; then
echo already running
exit 1
fi
rsync -az vger.rutgers.edu::cvs/CVSROOT/ChangeLog $HOME/ChangeLog
sum1=`sum $HOME/ChangeLog`
sum2=`sum /var/www/cvs/vger/CVSROOT/ChangeLog`
if [ "$sum1" = "$sum2" ]; then
echo nothing to do
exit 0
fi
rsync -az --delete --force vger.rutgers.edu::cvs/ /var/www/cvs/vger/
exit 0
Note in particular the initial rsync of the ChangeLog to determine if
anything has changed. This could be omitted but it would mean that the
rsyncd on vger would have to build a complete listing of the cvs area
at each run. As most of the time nothing will have changed I wanted to
save the time on vger by only doing a full rsync if the ChangeLog has
changed. This helped quite a lot because vger is low on memory and
generally quite heavily loaded, so doing a listing on such a large
tree every hour would have been excessive.
automated backup at home
I use rsync to backup my wifes home directory across a modem link each
night. The cron job looks like this
#!/bin/sh
cd ~susan
{
echo
date
dest=~/backup/`date %A`
mkdir $dest.new
find . -xdev -type f \( -mtime 0 -or -mtime 1 \) -exec cp -aPv "{}"
$dest.new \;
cnt=`find $dest.new -type f | wc -l`
if [ $cnt -gt 0 ]; then
rm -rf $dest
mv $dest.new $dest
fi
rm -rf $dest.new
rsync -Cavze ssh . samba:backup
} >> ~/backup/backup.log 2>&1
note that most of this script isn't anything to do with rsync, it just
creates a daily backup of Susans work in a ~susan/backup/ directory so
she can retrieve any version from the last week. The last line does
the rsync of her directory across the modem link to the host
samba. Note that I am using the -C option which allows me to add
entries to .cvsignore for stuff that doesn't need to be backed up.
Fancy footwork with remote file lists
One little known feature of rsync is the fact that when run over a
remote shell (such as rsh or ssh) you can give any shell command as
the remote file list. The shell command is expanded by your remote
shell before rsync is called. For example, see if you can work out
what this does:
rsync -avR remote:'`find /home -name "*.[ch]"`' /tmp/note that that is backquotes enclosed by quotes (some browsers don't show that correctly).
boot=/dev/hda # boot loader to MBR root=/dev/hda1 # root partition install=/boot/boot.b map=/boot/map delay=50 # 5 second delay before auto-boot image=/vmlinuz # kernel label=linux # name to refer to entry read-only image=/vmlinuz.old # backup entry label=old read-onlyIn this example, there are two possible kernels to boot: /vmlinuz and /vmlinuz.old. At the LILO prompt you can select between them by entering linux to select the current one or old to select the backup one. Pressing the TAB key at the LILO prompt will list these options. If you rebuild your kernel or want to make any other change you will need to rerun the lilo command to re-read the configuration file and re-install LILO with this new configuration information. GRUB reads the configuration file at boot time. The MBR is only 512 bytes. The portion of GRUB that is installed in the MBR does some basic initialization of the system, figures out how to access the boot drive and then loads the rest of GRUB from the drive. GRUB is installed by the grub-install program. There should be a man or info page available with the details. The grub info page is also very helpful. The configuration file is generally located in the /boot/grub directory. SuSE puts it in menu.lst and Red Hat in grub.conf. Here is a sample configuration file:
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
title Linux
kernel (hd0,1)/boot/vmlinuz root=/dev/hda2 desktop showopts
initrd (hd0,1)/boot/initrd
title Failsafe
kernel (hd0,1)/boot/vmlinuz root=/dev/hda2 showopts ide=nodma apm=off acpi=o
ff vga=normal nosmp noapic maxcpus=0 3
initrd (hd0,1)/boot/initrd
title Memory Test
kernel (hd0,1)/boot/memtest.bin
If you are sharing the computer with a proprietary OS from Redmond, take note that those people don't realize there are other operating systems available. That means that when you install their system the just overwrite the MBR. If you install their software first followed by Linux, all should be okay and you will be able to boot either OS.
Run Levels
Run levels offer you an array of system configurations. Unless told otherwise, the system will come up at the default run level which is typically level 3 or level 5. You can alter this behavior by entering the label name in LILO or the word boot in GRUB followed by the word single at the boot loader prompt.
There are seven standard run levels: 0 through 6. Level 0 means shutdown, level 1 is single-user mode and level 6 means reboot. The other levels are available at your discretion to set up various system configurations. The most typical is to use run level 3 as a fully-operational system without the GUI (X) running and level 5 like level 3 with the GUI. On many systems, there is a run level called S which is like run level 1 but requires the root password to be entered. This is there for security reasons.
The contents of the file /etc/inittab determine what action is to be taken at each run level and also specifies the default run level. Here is a sample of what might appear in /etc/inittab:
# # /etc/inittab # # This is the main configuration file of /sbin/init, which # is executed by the kernel on startup. # # The default runlevel id:5:initdefault: # /etc/init.d/rc takes care of runlevel handling # # runlevel 0 is System halt (Do not use this for initdefault!) # runlevel 1 is Single user mode # runlevel 2 is Local multiuser without remote network (e.g. NFS) # runlevel 3 is Full multiuser with network # runlevel 4 is Not used # runlevel 5 is Full multiuser with network and xdm # runlevel 6 is System reboot # l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 # what to do in single-user mode ls:S:wait:/etc/init.d/rc S ~~:S:respawn:/sbin/sulogin # what to do when CTRL-ALT-DEL is pressed ca::ctrlaltdel:/sbin/shutdown -r -t 4 now # getty-programs for the normal runlevels # ::: # The "id" field MUST be the same as the last # characters of the device (after "tty"). 1:2345:respawn:/sbin/mingetty --noclear tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6The line id:5:initdefault: sets the default run level to 5. The lines of this form l1:1:wait:/etc/init.d/rc 1 invoke the script /etc/init.d/rc passing it the run level as an argument. This script then starts the processes associated with the specific run level (and stops other processes). All of the scripts to control each process are also located in the /etc/init.d directory. Typically, which processes are to be started and stopped at each run level are located in sub-directories (for example, rc5.d for run level 5) of /etc/init.d. In each of these runlevel-specific directories, symbolic links are used to identify the processes. Link names starting with K refer to processes that are to be stopped (killed) and link names starting with S refer to those which are to be started. The links are accessed alphabetically which means the kill scripts are run first and the order of the scripts within the kill and start lists are controlled by using a 2-digit number immediately following the K or S. I said typically as this is the standard way to handle this information. Some vendors use slightly different schemes but, in all cases, the generainit program are what controls the whole process. If you are familiar with how UNIX handles startup, this is very similar to System V Init. If there were no problems encountered along the way your system should now be at the chosen run level. Once the system is up and running you can change run levels by logging on as root and using the init command. For example, to change to run level 3, you would enter init 3.