Topic: Backup Solutions for SME7

[i4daniels]

Hi,

I'm interested in hearing people's views on how they backup their own SME7 system.

Rather than using the backup2ws contrib or the bundled Flexbackup util, does anyone use anything more *ahem* solid.

I am backing up, potentially 600Gb of SCSI storage with an existing HP Ultrium 1 backup tape drive.  Yes, I know the U1 only holds 100/200Gb!

Under SME6.5 I used the Yosemite Tapeware Software which did a good job.  Now that SME7 uses the 2.6 Kernel my original copy no longer works unless I upgrade (Centos not supported apparently) to Backup Standard 8.

I've started looking into Bacula, www.bacula.org, which gobbles tapes.

Anyone recommend anything? like Amanda? or using Backup Standard 8?

Thanks!

Dan Scannell
www.i4tech.co.uk

[raymondw]

Dan,
I used SME 6.01 with Tapeware 7C and a external DLT1 autoloader.
After a upgrade to SME7 Pre4 i'm used Tapeware 7D (hd backup enabled) and a external USB2 HD.
Yesterday I did a upgrade to SME7 RC1 via yum and I just saw a mail from twadmin that my backup was succesfull

On 2 other servers i'm running a SME7 Alpha27 with a kernel adapted for Sata raid. They both backup to DAT72 via Tapeware 7D.
In the future I will update the machines to Tapeware 8, awaiting a nice deal to appeare from my reseller

Anyway, my advise is to stick with Yosemite  

[CharlieBrady]

Under SME6.5 I used the Yosemite Tapeware Software which did a good job.  Now that SME7 uses the 2.6 Kernel my original copy no longer works unless I upgrade (Centos not supported apparently) to Backup Standard 8.

Tell them it's Red Hat Enterprise Linux 4. If that's not supported, they can't claim to support linux.

[fpausp]

Hi,

I use the "IOMEGA REV DRIVE" 35GB atapi paralell (~210€), on a sme7pre4 with rsync.

regards
fpausp

[Kydoimus]

Hi,

I use the "IOMEGA REV DRIVE" 35GB atapi paralell (~210€), on a sme7pre4 with rsync.

regards
fpausp

I also want to buy that one. Only the S-ata of IDE internal version. Did everything worked fine installing the rev drive?

[dave_d]

The simple answer, I've found, is "Don't use tape"!

Computers and hard disks are now so cheap that obtaining a reliable PC and turning it into a continuous backup device seems to me to be the only way to go.

There's a piece of GPL software that does the trick - it's called BoxBackup.  Search the forums for 'boxbackup' and you'll find several entries that I've made on the subject.  Today - as it happens - I've just finished the implementation of a SME7 box acting as on-line, continuous, encrypted backup for an SME6 box.  I've written a detailed set of instructions on how to go about doing this - it's just that I'm too dumb to work the WiKi.  As soon as someone points me in the right direction, I'll post the document.

In the meantime, look at www.fluffy.co.uk/boxbackup  - yes! Really!

Dave

[calisun]

dave_d the whole point of putting it on tape is to get the backup out of the building just in case of fire or theft. Plus why would you get a separate computer for a backup? That is a point of RAID, if you have a good server with redundant power supply and RAID, no need for separate computer. But you still need a way to keep a backup in a different location/ storage just in case and you can't beat tape in that if you have hundred's of GIG's of data.

[jcoleman]

Dave,

See my post at:  

http://forums.contribs.org/index.php?topic=31214.0

It will answer your wiki issues....

Calisun - there are many ways to get data offsite without having to deal with tapes.  Take a look at the same post....

-jeff

[dave_d]

Hello Jeff,

Thanks for the WiKi information - but that just demonstrates how dense I'm being.  I've read all the documentation - but nowhere can I find a link to 'Add a new page'.  I can find 'Pageinfo' and 'Edit' - but no 'Add a page'.  Furthermore, I can't log in - I don't know if that's correct or not.

So... please have pity on someone who is clearly becoming a mental degenerate and point me to the URL that will enable me to add this page.
Or maybe I could e-Mail the document to you and you could do the addition - but I have just learned to wipe my own nose and I consider that an achievement!

Hello Calisun

The whole point of continuous backup is that the data goes off site all the time!  I'm maybe luckier than most, but all the sites I manage are huge with as much as 1 Km between server and backup - safe enough methinks.  And with broadband now readily available I'm sure that a transmission solution to remote locations can be cobbled together.


Regards,

Dave

[jcoleman]

Dave,

Can't help you on the login or page issues, but you can certainly post your howto right here in the forum.  That way the knowledge is shared without you having to become a wikimaster

Just post it in a message and share the wealth....

-jeff

[dave_d]

OK Jeff - you asked for it .........

Installing BoxBackup 0.10

In this HowTo I'll explain how to install BoxBackup 0.10 to backup a 6.0.1-01 (fully updated) SME server onto a 7.0rc1 SME server.  Since I last wrote about how to use BoxBackup, the BoxBackup software has been upgraded.  This upgrade means that BoxBackup is now quite tricky to build on the 6.0.1-01 server, but fairly straightforward on the 7.0rc1 server.

The two servers have different versions of RedHat as their base operating systems and this means that the build processes are not quite the same.

BoxBackup is a continuous computer to computer backup system.  For any two computers, one is the backup server - the place where files are safely stored as backups, and the other is a backup client - the computer whose files are to be transferred to the backup server for safe storage.  For full information, visit www.fluffy.co.uk/boxbackup.

Building BoxBackup on any system means that both client and server software is build.  Where both client and server are computers based on the same base operating system, this is a very handy feature as it means that only one build process has to be gone through.  However, where the two systems are different, a build process has to be undertaken on each computer.

The purpose of this document is to show how the BoxBackup builds and installations are achieved on each of the server types.

Building on a 6.0.1-01 server.

Stock servers are not development machines and so some development software has to be downloaded and installed.  Note that all operations are carried out whilst logged on as 'root'.

# mkdir /downloads
# cd downloads
# mkdir devel
# cd devel
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/autoconf-2.13-17.noarch.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/automake-1.4p5-4.noarch.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/cpp-2.96-113.i386.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/gcc-2.96-113.i386.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/gcc-c++-2.96-113.i386.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/glibc-devel-2.2.5-44.i386.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/glibc-kernheaders-2.4-7.16.i386.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/m4-1.4.1-7.i386.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/glibc-headers-2.4-7.16.i386.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/ncurses-devel-5.2-26.i386.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/zlib-devel-1.1.4-8.7x.i386.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/readline-devel-4.2a-4.i386.rpm
# wget -c http://mirror.contribs.org/smeserver/contribs/hpe/devtools-6.01/dev-rpms/libstdc++-devel-2.96-113.i386.rpm

Now install these as follows

# rpm -Uvh glibc-headers-2.4-7.16.i386.rpm
# rpm -Uvh glibc-kernheaders-2.4-7.16.i386.rpm
# rpm -Uvh glibc-devel-2.2.5-44.i386.rpm
# rpm -Uvh cpp-2.96-113.i386.rpm
# rpm -Uvh gcc-c++-2.96-113.i386.rpm
# rpm -Uvh gcc-2.96-113.i386.rpm
# rpm -Uvh m4-1.4.1-7.i386.rpm
# rpm -Uvh ncurses-devel-5.2-26.i386.rpm
# rpm -Uvh autoconf-2.13-17.noarch.rpm
# rpm -Uvh automake-1.4p5-4.noarch.rpm
# rpm -Uvh libstdc++-devel-2.96-113.i386.rpm
# rpm -Uvh readline-devel-4.2a-4.i386.rpm
# rpm -Uvh zlib-devel-1.1.4-8.7x.i386.rpm

So far, so good!  All we've done is added some software that will enable us to build some more.

Getting and building Berkeley DB

Get and make the Berkeley Database as follows.

# cd /downloads
# mkdir BerkeleyDB
# cd BerkeleyDB
# wget -c ftp://ftp.sleepycat.com/releases/db-4.4.20.NC.tar.gz
# wget -c http://www.sleepycat.com/update/4/4/20/patch.4.4.20.1
# wget -c http://www.sleepycat.com/update/4/4/20/patch.4.4.20.2
# tar -zxvf db-4.4.20.NC.tar.gz
# cd db-4.4.20.NC
# patch -p0 < ../patch.4.4.20.1
# patch -p0 < ../patch.4.4.20.2
cd build_unix
../dist/configure
make
make install

This leaves BerkeleyDB installed into /usr/local/BerkeleyDB.4.4/

Making and installing a new compiler

The current version of BoxBackup cannot be built using the 2.96 version compiler and so the next job is to get and install a new compiler.  I did this from source - and it's a   L O N G   process.  Best do it overnight or when there's something else to do at the same time.  (Note: I may have fetched too many source files - I'm not an expert on how these compilers are built. In hindsight you can probably do without gcc-g77-3.4.6.tar.gz, gcc-java-3.4.6.tar.gz, gcc-objc-3.4.6.tar.gz, and gcc-testsuite-3.4.6.tar.gz)

# cd /downloads
# mkdir gcc3
# cd gcc3
# wget -c ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/releases/gcc-3.4.6/gcc-3.4.6.tar.gz
# wget -c ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/releases/gcc-3.4.6/gcc-3.4.6.tar.gz
# wget -c ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/releases/gcc-3.4.6/gcc-g++-3.4.6.tar.gz
# wget -c ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/releases/gcc-3.4.6/gcc-g77-3.4.6.tar.gz
# wget -c ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/releases/gcc-3.4.6/gcc-java-3.4.6.tar.gz
# wget -c ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/releases/gcc-3.4.6/gcc-objc-3.4.6.tar.gz
# wget -c ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/releases/gcc-3.4.6/gcc-testsuite-3.4.6.tar.gz

# tar -zxvf gcc-3.4.6.tar.gz
# tar -zxvf gcc-3.4.6.tar.gz
# tar -zxvf gcc-g++-3.4.6.tar.gz
# tar -zxvf gcc-g77-3.4.6.tar.gz
# tar -zxvf gcc-java-3.4.6.tar.gz
# tar -zxvf gcc-objc-3.4.6.tar.gz
# tar -zxvf gcc-testsuite-3.4.6.tar.gz

# mkdir gcc-3.4.6-obj

# cd gcc-3.4.6-obj
# /downloads/gcc3/gcc-3.4.6/configure --prefix=/usr/local/gcc-3.4.6
# make
# make install

Now you have a new compiler that is capable of compiling the latest BoxBackup.  Note that a new version of binutils was not created and this leads to a slight problem later on.  However, on any working server it's best to keep to the rule that only the very minimum changes should be made to installed software.

We can now remove some of the rpms that were installed earlier. This ensures that no cross version contamination takes place.

# rpm -e libstdc++-devel-2.96-113.i386.rpm
# rpm -e cpp-2.96-113.i386.rpm
# rpm -e gcc-c++-2.96-113.i386.rpm
# rpm -e gcc-2.96-113.i386.rpm

Installing an updated OpenSSL

The BoxBackup system requires a later version of OpenSSL than is installed on a stock 6.0.1-01 server.  To build a version for the use of BoxBackup, do the following:  (Note: The no-sse2 parameter is required because of a weakness in the binutils shipped with RH7.3)

# export LD_LIBRARY_PATH=/usr/local/gcc-3.4.6/lib
# export PATH=/usr/local/gcc-3.4.6/bin:$PATH
# cd /downloads
# wget -c http://www.openssl.org/source/openssl-0.9.8a.tar.gz
# tar -zxvf openssl-0.9.8a.tar.gz
# cd openssl-0.9.8a
# ./Configure shared no-sse2 --prefix=/opt/openssl-0.9.8a linux-elf
# make
# make test
# make install

This has given us a version of openssl in /opt/openssl-0.9.8a

Building BoxBackup 0.10

All the elements required to build and run BoxBackup are now in place.  Get and build the software as follows:

# cd /downloads
# export LD_LIBRARY_PATH=/opt/openssl-0.9.8a/lib:/usr/local/BerkeleyDB.4.4/lib:/usr/local/gcc-3.4.6/lib

<Check that PATH is still defined with /usr/local/gcc-3.4.6/bin as the first element.  If not, fix it!>

# wget -c http://kent.dl.sourceforge.net/sourceforge/boxbackup/boxbackup-0.10.tgz
# tar -zxvf boxbackup-0.10.tgz
# cd boxbackup-0.10
# ./configure --prefix=/usr/local/boxbackup-0.10 \
>             --enable-gnu-readline \
>             --with-dbd-dir=/usr/local/BerkeleyDB.4.4 \
>             --with-ssl-lib=/opt/openssl-0/9.8a/lib \
>             --with-ssl-headers=/opt/openssl-0.9.8a/include

Note that the Extended Attributes feature was not included.  Getting this included depends on a file called /usr/include/sys/xattr.h being present.  I spent half a day searching for a RH7.3 rpm that would give me this - but to no avail!  Anyone finding out how to do this is invited to update this document.

# make
# make test

An error in the installation procedure means that the target directory has to be manually created.

# mkdir -p /usr/local/boxbackup-0.10/bin
# make install-backup-client

That's all there is to do for the present for the client part of the BoxBackup installation.  More work will be needed once the server part of the BoxBackup has been made.

Building on a 7.0rc1 server

The software mis-match between SME server 7.0rc1 and BoxBackup 0.10 is not nearly as bad as the mismatch on SME server 6.0.1-01.  If both boxes were SME server 7.0 boxes there would be no need to create a separate openssl installation for Boxbackup.  However, because we built the client side to use openssl-0.9.8a we'll build the server side to do the same.

The compiler available for use on SME server 7.0rc1 is up to date enough for the build of Boxbackup and so there's no need to build a new compiler.

Stock servers are not development machines and so some development software has to be downloaded and installed.  Note that all operations are carried out whilst logged on as 'root'.

# mkdir /downloads
# cd downloads
# mkdir devel
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/glibc-kernheaders-2.4-9.1.98.EL.i386.rpm
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/glibc-headers-2.3.4-2.13.i386.rpm
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/glibc-devel-2.3.4-2.13.i386.rpm
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/cpp-3.4.4-2.i386.rpm
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/gcc-3.4.4-2.i386.rpm
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/patch-2.5.4-20.i386.rpm
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/libstdc++-devel-3.4.4-2.i386.rpm
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/gcc-c++-3.4.4-2.i386.rpm
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/zlib-devel-1.2.1.2-1.2.i386.rpm
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/libtermcap-devel-2.0.8-39.i386.rpm
# wget -c http://mirror.centos.org/centos/4.2/os/i386/CentOS/RPMS/readline-devel-4.3-13.i386.rpm

Now install these as follows

# rpm -Uvh glibc-kernheaders-2.4-9.1.98.EL.i386.rpm
# rpm -Uvh glibc-headers-2.3.4-2.13.i386.rpm
# rpm -Uvh glibc-devel-2.3.4-2.13.i386.rpm
# rpm -Uvh cpp-3.4.4-2.i386.rpm
# rpm -Uvh gcc-3.4.4-2.i386.rpm
# rpm -Uvh patch-2.5.4-20.i386.rpm
# rpm -Uvh libstdc++-devel-3.4.4-2.i386.rpm
# rpm -Uvh gcc-c++-3.4.4-2.i386.rpm
# rpm -Uvh zlib-devel-1.2.1.2-1.2.i386.rpm
# rpm -Uvh libtermcap-devel-2.0.8-39.i386.rpm
# rpm -Uvh readline-devel-4.3-13.i386.rpm

Getting and building Berkeley DB

Get and make the Berkeley Database as follows.

# cd /downloads
# mkdir BerkeleyDB
# cd BerkeleyDB
# wget -c ftp://ftp.sleepycat.com/releases/db-4.4.20.NC.tar.gz
# wget -c http://www.sleepycat.com/update/4/4/20/patch.4.4.20.1
# wget -c http://www.sleepycat.com/update/4/4/20/patch.4.4.20.2
# tar -zxvf db-4.4.20.NC.tar.gz
# cd db-4.4.20.NC
# patch -p0 < ../patch.4.4.20.1
# patch -p0 < ../patch.4.4.20.2
cd build_unix
../dist/configure
make
make install

This leaves BerkeleyDB installed into /usr/local/BerkeleyDB.4.4/

Installing an updated OpenSSL

The BoxBackup system can be built using the stocj OpenSSL included with the SME server 7.0rc1.  However, just to be consistent with the update required on the SME server 6.0.1-01 box we'll build a version od OpenSSL that is exclusively for use by Boxbackup.

# cd /downloads
# wget -c http://www.openssl.org/source/openssl-0.9.8a.tar.gz
# tar -zxvf openssl-0.9.8a.tar.gz
# cd openssl-0.9.8a
# ./Configure shared --prefix=/opt/openssl-0.9.8a linux-elf

Note that the configuration is slightly differnt from that used for the 6.0.1-01 box

# make
# make test
# make install

This has given us a version of openssl in /opt/openssl-0.9.8a

Building BoxBackup 0.10

All the elements required to build and run BoxBackup are now in place.  Get and build the software as follows:

# cd /downloads
# export LD_LIBRARY_PATH=/opt/openssl-0.9.8a/lib:/usr/local/BerkeleyDB.4.4/lib
# wget -c http://kent.dl.sourceforge.net/sourceforge/boxbackup/boxbackup-0.10.tgz
# tar -zxvf boxbackup-0.10.tgz
# cd boxbackup-0.10      
# ./configure --prefix=/usr/local/boxbackup-0.10 --enable-gnu-readline --with-dbd-dir=/usr/local/BerkeleyDB.4.4/ --with-ssl-headers=/opt/openssl-0.9.8a/include --with-ssl-lib=/opt/openssl-0.9.8a/lib
# make

Note that there are many more warnings produced on this system than on the 6.0.1-01 system.  Anyone finding a way to reduce these is invited to edit this document.

# make test

An error in the installation procedure means that the target directory has to be manually created.

# mkdir -p /usr/local/boxbackup-0.10/bin
# make install-backup-server

Putting the system to work

So far, all we've done is to build, test and install BoxBackup 0.10 on each of the servers that we want to link together as a backup client/server pair.  No part of BoxBackup is running and no amount of re-booting will cause BoxBackup to run.

Because we're dealing with SME server, and because SME server provides us with a mechanism for properly integrating new services, that's what we'll do.  To start with we'll use some harmless dummy software to test that we've correctly defined and integrated the BoxBackup services.

To make life easy, the BoxBackup distribution contains startup/shutdown scripts that are ideal for our purposes.  However, because we want to test the service definition and operation in a safe way we'll start by using dummy scripts.

On the SME server 6.0.1-01 box - the BoxBackup client

The script that will eventually be used to start and stop the Baxbackup client daemon is called bbackupd.  We'll make a dummy version of this file that is used exclusively for testing the new SME service definition.

Create the following file (bbackupd) (in /downloads for the time being) :

############################################

#!/bin/sh
#
# This is the control script for the Boxbackup
# client on this machine.

# source function library
. /etc/rc.d/init.d/functions

RETVAL=0

start() {
        echo -n "Starting boxbackup "
        /usr/bin/logger -t "Dummy boxbackup" "Starting ...."
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/bbackupd
}

stop() {
        echo -n "Stopping boxbackup "
        /usr/bin/logger -t "Dummy boxbackup" "Stopping ...."
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/bbackupd
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        stop
        start
        ;;
  status)
        echo -n "Status boxbackup "
        /usr/bin/logger -t "Dummy boxbackup" "Status ...."
        echo
        ;;
  *)
        echo "*** Usage: boxbackup {start|stop|restart|status}"
        exit 1
esac

exit 0

############################################

This file has the correct structure for starting and stopping the real Baxbackup client daemon but instead of starting or stopping the service it simply makes some entries in the system log.  This enables the definition and functioning of the new SME service to be checked.

Creating the bbackupd service

(For more general information about how services are implemented in SME server, see the official documentation accessible via contribs.org)

We'll create a new SME service called bbackupd in the configuration database.  To do this, create a directory called bbackupd in the directory /etc/e-smith/db/configuration/defaults.

# cd /etc/e-smith/db/configuration/defaults
# mkdir bbackupd

To define bbackupd as a service, simply create a file called 'type' in the newly created directory.  This new file contains the single line 'service' (no new line at the end)

# cd bbackupd
# echo "service" > type

To define the default status of the new service 'bbackupd', create a file called 'status' in the bbackupd directory containing the single line 'enabled'.

# echo "enabled" > status

In order to get this new service added to the configuration database, the database has to be re-initialised.  Do this by causing the 'console-save' event to be signalled.

# /sbin/e-smith/signal-event console-save

Check that the new service has been added to the configuration database.

# /sbin/e-smith/config show bbackupd

... and look for an entry of the form

bbackupd=service
    status=enabled

Getting control of the backup system

The start/stop script will be created in /etc/rc.d/init.d.  Copy the dummy file bbackupd that was created in /downloads.

# cd /etc/rc.d/init.d
# cp /downloads/bbackupd .
# chmod 755 bbackupd

We want to call the Boxbackup client daemon startup right at the end of the system startup process.  To do this we add a symbolic link to /etc/rc.d/init.d/e-smith-service into /etc/rc.d/rc7.d under the name S99bbackupd

# cd /etc/rc.d/rc7.d/
# ln -s /etc/rc.d/init.d/e-smith-service S99bbackupd

In order that the service is properly stopped whan a reboot is requested, we need to add the following to /etc/rc.d/rc6.d.  This stops the BoxBackup client at the start of the shutdown (during reboot) process.

# cd /etc/rc.d/rc6.d
# ln -s ../init.d/bbackupd K02bbackupd

To ensure that the same shutdown occurs when a straighforward shutdown (as opposed to a reboot) is requested, add an entry to /etc/rc/d/rc0.d

# cd /etc/rc.d/rc0.d
# ln -s ../init.d/bbackupd K02bbackupd

Now is the time to test that the new service structure is in place and functioning.  Reboot the system and then look in /var/log/messages.  If all is working you should see messages like this ....

Mar 21 14:02:52 spc-server rc: Starting smb:  succeeded
Mar 21 14:02:52 spc-server bbackupd: Starting boxbackup
Mar 21 14:02:52 spc-server Dummy boxbackup: Starting ....
Mar 21 14:02:53 spc-server bbackupd:
Mar 21 14:02:53 spc-server rc: Starting bbackupd:  succeeded

That's all we'll do for now on the client.  There's more to do later!

On the SME server 7.0rc1 box - the BoxBackup server

Refer back to the section "On the SME server 6.0.1-01 box - the BoxBackup client".  Create the same dummy startup/shutdown script in /downloads, but this time call it 'bbstored'.

Creating the bbackupd service

We'll create a new SME service called bbstored in the configuration database.  To do this, create a directory called bbstored in the directory /etc/e-smith/db/configuration/defaults.

# cd /etc/e-smith/db/configuration/defaults
# mkdir bbstored

To define bbstored as a service, simply create a file called 'type' in the newly created directory.  This new file contains the single line 'service' (no new line at the end)

# cd bbstored
# echo "service" > type

To define the default status of the new service 'bbstored', create a file called 'status' in the bbstored directory containing the single line 'enabled'.

# echo "enabled" > status

In order to get this new service added to the configuration database, the database has to be re-initialised.  Do this by causing the 'console-save' event to be signalled.

# /sbin/e-smith/signal-event console-save

Check that the new service has been added to the configuration database.

# /sbin/e-smith/config show bbstored

... and look for an entry of the form

bbstored=service
    status=enabled

Getting control of the backup system

The start/stop script will be created in /etc/rc.d/init.d.  Copy the dummy file bbstored that was created in /downloads.

# cd /etc/rc.d/init.d
# cp /downloads/bbstored .
# chmod 755 bbstored

Using your favourite editor, change all occurrences of 'bbackupd' to 'bbstored' in the new bbstored startup/shutdown script.

We want to call the Boxbackup client daemon startup right at the end of the system startup process.  To do this we add a symbolic link to /etc/rc.d/init.d/e-smith-service into /etc/rc.d/rc7.d under the name S99bbackupd

# cd /etc/rc.d/rc7.d/
# ln -s /etc/rc.d/init.d/e-smith-service S99bbstored

In order that the service is properly stopped whan a reboot is requested, we need to add the following to /etc/rc.d/rc6.d.  This stops the BoxBackup client at the start of the shutdown (during reboot) process.

# cd /etc/rc.d/rc6.d
# ln -s ../init.d/bbackupd K02bbstored

To ensure that the same shutdown occurs when a straighforward shutdown (as opposed to a reboot) is requested, add an entry to /etc/rc/d/rc0.d

# cd /etc/rc.d/rc0.d
# ln -s ../init.d/bbstored K02bbstored

Now is the time to test that the new service structure is in place and functioning.  Reboot the system and then look in /var/log/messages.  If all is working you should see messages like this ....

Mar 22 11:28:15 omf-server Dummy boxbackup: Startup and shutdown procedure
Mar 22 11:28:15 omf-server bbstored: Starting boxbackup
Mar 22 11:28:15 omf-server Dummy boxbackup: Starting ....
Mar 22 11:28:15 omf-server bbstored:
Mar 22 11:28:15 omf-server rc.e-smith: Starting bbstored:  succeeded

Getting it all to work

So far we've built all the required software on both client and server machines and we've defined and tested a new service on each of the machines.  Now is the time to get it all working.

The first thing to do is to decide where the backups are to reside.  Ideally, the backups would reside on a separate disc or RAID volume mounted on the backup server - particularly if this server were to be used for anything else.  There's plenty of documentation around that describes how an additional disc is added to an SME server and mounted at startup time.  However, as this particular server exists only for the purpose of holding backups for a single client the backup files are held on the server main volume.

To make life a bit easier we'll call the SME server 6.0.1-01 client machine 'spc-server' and the SME server 7.0rc1 server machine 'omf-server'.

Boxbackup should run as a user apart from the normal users defined on the SME server. The first steps are to make a user for the backup server create a top level directory to hold the backups.

On the 7.0rc1 boxbackup server (omf-server) .....

# useradd boxbackup
# mkdir -p /spc-server-backup
# chmod -R 766 /spc-server-backup
# chown -R boxbackup:boxbackup /spc-server-backup

Boxbackup uses a RAID system that is not useful on an SME server. See the Boxbackup documentation for further details.  To disable the boxbackup specific RAID, do the following:

# /usr/local/boxbackup-0.10/bin/raidfile-config /etc/box 2048 /spc-server-backup
Creating /etc/box...
WARNING: userland RAID is disabled.
Config file written.

Now the server can be configured.  Use the 'bbstored-config' to do this.

# /usr/local/boxbackup-0.10/bin/bbstored-config /etc/box omf-server boxbackup
Checking permissions on /spc-server-backup
Checking permissions on /spc-server-backup
Checking permissions on /spc-server-backup

Setup bbstored config utility.

Configuration:
   Writing configuration file: /etc/box/bbstored.conf
   Writing empty accounts file: /etc/box/bbstored/accounts.txt
   Server hostname: omf-server
   RaidFile config: /etc/box/raidfile.conf

Creating /etc/box/bbstored
Creating blank accounts file
Generating private key...
Generating RSA private key, 2048 bit long modulus
..................................................................+++
.....................................................................................................+++
e is 65537 (0x10001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:State or Province Name (full name) [Berkshire]:Locality Name (eg, city) [Newbury]:Organization Name (eg, company) [My Company Ltd]:Organizational Unit Name (eg, section) []:Common Name (eg, your name or your server's hostname) []:Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:An optional company name []:

Writing configuration file /etc/box/bbstored.conf

===================================================================

bbstored basic configuration complete.

What you need to do now...

1) Sign /etc/box/bbstored/omf-server-csr.pem
   using the bbstored-certs utility.

2) Install the server certificate and root CA certificate as
      /etc/box/bbstored/omf-server-cert.pem
      /etc/box/bbstored/clientCA.pem

3) You may wish to read the configuration file
      /etc/box/bbstored.conf
   and adjust as appropraite.

4) Create accounts with bbstoreaccounts

5) Start the backup store daemon with the command
      /usr/local/bin/bbstored
   in /etc/rc.local, or your local equivalent.

===================================================================

We'll now set up some of the keys required to run the system securely. The documentation warns against what I'm going to do here on security grounds, but, again, this is done in the interest of getting a test system working.
I guess you could simply copy the following directory structure to a floppy and delete it off the hard drive and achieve the same result!

Note too the requirement to have LD_LIBRARY_PATH  AND PATH set correctly.

# export LD_LIBRARY_PATH=/opt/openssl-0.9.8a/lib:/usr/local/BerkeleyDB.4.4/lib/
# PATH=/opt/openssl-0.9.8a/bin:$PATH
# cd /root
# mkdir boxkeys
# cd boxkeys
# cp /etc/box/bbstored/omf-server-csr.pem .
# /usr/local/boxbackup-0.10/bin/bbstored-certs ca init
# /usr/local/boxbackup-0.10/bin/bbstored-certs ca sign-server omf-server-csr.pem
# cp ca/servers/omf-server-cert.pem /etc/box/bbstored/
# cp ca/roots/clientCA.pem /etc/box/bbstored

Now choose a positive 31 bit account number out of thin air. For this exercise I chose to use 704747.
Create the account - check the user documentation at http://www.fluffy.co.uk/boxbackup/accounts.html for details.

# /usr/local/boxbackup-0.10/bin/bbstoreaccounts create 704747 0 35G 37G

That's all there is to do on the backup server at present.

On the 6.0.1-01 boxbackup client (spc-server) .....

Log on as 'root'. Before going further, you need to establish that spc-server can ping omf-server. If 'ping omf-server' works, then skip this next bit. Otherwise, establish the IP address of omf-server and do the following ...

# export LD_LIBRARY_PATH=/opt/openssl-0.9.8a/lib:/usr/local/BerkeleyDB.4.4/lib/
# export PATH=/opt/openssl-0.9.8a/bin:$PATH
# mkdir -p /etc/e-smith/templates-custom/etc/hosts
# cd /etc/e-smith/templates-custom/etc/hosts

Make a file called 30backuphostmars containing this one line:
192.168.40.4 omf-server  

# echo "192.168.40.4 omf-server" > 30boxbackuphost

Then ...

# /sbin/e-smith/expand-template /etc/hosts

Now 'ping omf-server' again and this time it should work. If not, fix it!

Configure the client to backup all the user areas and an iBay called 'shared files'.

# /usr/local/boxbackup-0.10/bin/bbackupd-config /etc/box lazy 704747 omf-server \
> /var/backupd /home/e-smith/files/users/ /home/e-smith/files/ibays/shared-files/


Setup bbackupd config utility.

Configuration:
   Writing configuration file: /etc/box/bbackupd.conf
   Account: 704747
   Server hostname: omf-server
   Directories to back up:
      /home/e-smith/files/users/
      /home/e-smith/files/ibays/shared-files/

Note: If other file systems are mounted inside these directories, then problems may occur
with files on the store server being renamed incorrectly. This will cause efficiency
problems, but not affect the integrity of the backups.

WARNING: Directories not checked against mountpoints. Check mounted filesystems manually.

Generating keys for file backup
Writing notify script /etc/box/bbackupd/NotifySysadmin.sh
Writing configuration file /etc/box/bbackupd.conf

===================================================================

bbackupd basic configuration complete.

What you need to do now...

1) Make a backup of /etc/box/bbackupd/704747-FileEncKeys.raw
   This should be a secure offsite backup.
   Without it, you cannot restore backups. Everything else can
   be replaced. But this cannot.
   KEEP IT IN A SAFE PLACE, OTHERWISE YOUR BACKUPS ARE USELESS.

2) Send /etc/box/bbackupd/704747-csr.pem
   to the administrator of the backup server, and ask for it to
   be signed.

3) The administrator will send you two files. Install them as
      /etc/box/bbackupd/704747-cert.pem
      /etc/box/bbackupd/serverCA.pem
   after checking their authenticity.

4) You may wish to read the configuration file
      /etc/box/bbackupd.conf
   and adjust as appropraite.

   There are some notes in it on excluding files you do not
   wish to be backed up.

5) Review the script
      /etc/box/bbackupd/NotifySysadmin.sh
   and check that it will email the right person when the store
   becomes full. This is important -- when the store is full, no
   more files will be backed up. You want to know about this.

6) Start the backup daemon with the command
      /usr/local/bin/bbackupd
   in /etc/rc.local, or your local equivalent.
   Note that bbackupd must run as root.

===================================================================

Remember to make a secure, offsite backup of your backup keys,
as described in step 1 above. If you do not, you have no backups.
Really!  Do it! Make a secure, offsite backup of /etc/box/bbackupd/704747-FileEncKeys.raw
Without this file you have NO BACKUP!!!!

You've done the backup of the keys, right?  OK - to continue .....

Copy (from spc-server) /etc/box/bbackupd/704747-csr.pem to (on omf-server) /root/boxkeys.  Being lazy I copied these files via a home dorectory on each server using a Windoze box.

On omf-server (making sure that PATH and LD_LIBRARY_PATH are still correct) do:

# cd/root/boxkeys
# /usr/local/boxbackup-0.10/bin/bbstored-certs ca sign 704747-csr.pem


This certificate is for backup account

   704747

Ensure this matches the account number you are expecting. The filename is

   704747-csr.pem

which should include this account number, and additionally, you should check
that you received it from the right person.

Signing the wrong certificate compromises the security of your backup system.

Would you like to sign this certificate? (type 'yes' to confirm)
yes
Signature ok
subject=/CN=BACKUP-704747
Getting CA Private Key


Certificate signed.

Send the files

   ca/clients/704747-cert.pem
   ca/roots/serverCA.pem

to the client.

Copy (From omf-server) /root/boxkeys/ca/clients/704747-cert.pem and /root/boxkeys/roots/serverCA.pem to (on spc-server) /etc/box/bbackupd/704747-cert.pem and /etc/box/bbackupd/serverCA.pem

Edit /etc/box/bbackupd/NotifySysadmin.sh to make sure that error reports are e-mailed to the right place. (Or leave it alone for testing!!)

That's it!. All you need to do now is start the server on omf-server and the client on sme-server.  To do this, we'll replace the dummy startup/shutdown scripts used to test the new services 'bbackupd' and 'bbstored'.

On the SME server 7.0rc1 backup server

Create the following file and use it to replace /etc/rc.d/init.d/bbstored

##################################################

#! /bin/bash
#
# bbstored          Start/Stop the box backup daemon.
#
# chkconfig: 345 93 07
# description: bbstore is the server side deamon for Box Backup, a completely \
#              automatic on-line backup system
# processname: bbstored
# config: /etc/box
# pidfile: /var/run/bbstored.pid

# Source function library.
. /etc/rc.d/init.d/functions

# Modified for use on an SME7 server system
# Added the two 'export' lines below
# Changed 'daemon $prog' to just '$prog' in the start() section

export LD_LIBRARY_PATH=/opt/openssl-0.9.8a/lib:/usr/local/BerkeleyDB.4.4/lib/
export PATH=/opt/openssl-0.9.8a/bin:/usr/local/boxbackup-0.10/bin:$PATH

RETVAL=0

# See how we were called.

prog="bbstored"

# Check that configuration exists.
[ -f /etc/box/$prog.conf ] || exit 0

start() {
        echo -n $"Starting $prog: "
        $prog
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
        return $RETVAL
}

stop() {
        echo -n $"Stopping $prog: "
        killproc $prog
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
        return $RETVAL
}

rhstatus() {
        status $prog
}

restart() {
        stop
        start
}

reload() {
        echo -n $"Reloading $prog daemon configuration: "
        killproc $prog -HUP
        retval=$?
        echo
        return $RETVAL
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        restart
        ;;
  reload)
        reload
        ;;
  status)
        rhstatus
        ;;
  condrestart)
        [ -f /var/lock/subsys/$prog ] && restart || :
        ;;
  *)
        echo $"Usage: $0 {start|stop|status|reload|restart|condrestart}"
        exit 1
esac

exit $?

##################################################

Test that the server part starts and stops as required.

# ./bbstored start
Starting bbstored: Box Backup Store Server v0.10, (c) Ben Summers and contributors 2003-2006

# ./bbstored stop
Stopping bbstored:                                         [  OK  ]
# ./bbstored stop
Stopping bbstored:                                         [FAILED]
# ./bbstored start
Starting bbstored: Box Backup Store Server v0.10, (c) Ben Summers and contributors 2003-2006

#

Now re-boot the system and check that things start up as required.

# shutdown -r now

On restart, check the content of /var/log/messages and also confirm that the system is running by

# ps -aux

..... And finally, on the SME server 6.0.1-01 client box

Create the following file and use it to replace /etc/rc.d/init.d/bbackupd

################################################

#! /bin/bash
#
# bbackupd          Start/Stop the box backup daemon.
#
# chkconfig: 345 93 07
# description: bbackup is the client side deamon for Box Backup, a completely \
#              automatic on-line backup system
# processname: bbackupd
# config: /etc/box
# pidfile: /var/run/bbackupd.pid

# Source function library.
. /etc/init.d/functions

# Modified for use on an SME6 server system
# Added the two 'export' lines below
# Changed 'daemon $prog' to just '$prog' in the start() section

export LD_LIBRARY_PATH=/opt/openssl-0.9.8a/lib:/usr/local/BerkeleyDB.4.4/lib/:/usr/local/gcc-3.4.6/lib
export PATH=/opt/openssl-0.9.8a/bin:/usr/local/boxbackup-0.10/bin:$PATH

RETVAL=0

# See how we were called.

prog="bbackupd"

# Check that configuration exists.
[ -f /etc/box/$prog.conf ] || exit 0

start() {
        echo -n $"Starting $prog: "
        $prog
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
        return $RETVAL
}

stop() {
        echo -n $"Stopping $prog: "
        killproc $prog
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
        return $RETVAL
}

rhstatus() {
        status $prog
}

restart() {
        stop
        start
}

reload() {
        echo -n $"Reloading $prog daemon configuration: "
        killproc $prog -HUP
        retval=$?
        echo
        return $RETVAL
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        restart
        ;;
  reload)
        reload
        ;;
  status)
        rhstatus
        ;;
  condrestart)
        [ -f /var/lock/subsys/$prog ] && restart || :
        ;;
  *)
        echo $"Usage: $0 {start|stop|status|reload|restart|condrestart}"
        exit 1
esac

exit $?

################################################

Test that everything's working....

# ./bbackupd start
Starting bbackupd: Box Backup Client v0.10, (c) Ben Summers and contributors 2003-2006

# ./bbackupd stop
Stopping bbackupd:                                         [   OK   ]
# ./bbackupd stop
Stopping bbackupd:                                         [ FAILED ]
# ./bbackupd start
Starting bbackupd: Box Backup Client v0.10, (c) Ben Summers and contributors 2003-2006

#

And finally ... reboot the system and check /var/log/messages.

That's the main client/server function under way.  However, because we used separate openssl installations for the build of all the Boxbackup binaries, you'll need to add the following lines to /root/.bashrc - assuming you want to continue using the root account to manipulate boxbackup.

#
# Need these for using the boxbackup stuff
#

export LD_LIBRARY_PATH=/opt/openssl-0.9.8a/lib:/usr/local/BerkeleyDB.4.4/lib:/u$
export PATH=/usr/local/boxbackup-0.10/bin:$PATH


That's it!  I dare say there are more elegant ways of doing things - but it works for me.  I must say that I would like to see something like this incorporated into SME server as a standard.  Once working it's a no-brainer, it allows files to be recovered quickly and from the command line, multiple backups can be made simultaneously and so on and so on.

Go and have a beer - you deserve it!

.................  I told you it was long!!!!!!

Regards,

Dave

[jcoleman]

Thanks for sharing this Dave.  Content is way more important than form.  

I'm going to give this a try in atest environment asap.  I'll let you know if I run into any issues.

-jeff

[dave_d]

Good luck Jeff,

Don't forget - if you're building this for an SME7 only environment .....

A) the compiler for CentOS 4.2 is OK - no need to build another
B) the OpenSSL is OK - no need to build another
C) only one build required.  Simply transfer the built s/w across to t'other machine.  See www.fluffy.co.uk/blah..blah..blah for instructions on how to do this.

It's this business of being able to push completely built components from one machine to another that makes me think it ought to be possible somehow to automate the configuration process between two computers as both BBserver and BBclient could be deposited somewhere during an SME build and activated /configured from a panel.  If I had more time I would figure it out for myself.

Dave

[fpausp]

Kydoimus take a look at http://iomrrdtools.sourceforge.net/ there are scripts to Locating Your REV Drive's /dev Entry.

After that you should be able to mount your revdrive with somthing like - mount -t udf .....

I use rsync to backup my ibays to the rev automated in a cronjob, after that i umount or remount it readonly.

fpausp

[silasp]

Hi there.
I also use Rsync for automated remote backups. Here's how.
(This is a convenient collation of several of my previous posts)

INGREDIENTS:
- A SME server, accessible over the net with a fixed IP or hostname.
- A backup server. Doesn't have to be cutting-edge, as long as it has a network card and a nice big hard drive.
- A broadband internet connection between your SME server and your backup server.

HOW-TO:
- Enable Remote SSH access from the server-manager of your main server.

- Install SME 6 or 7 on your backup server. Install it in server-only mode, give it an unused IP on your local network. At this stage, both servers should be connected to the same local network.

- Enable unattended SSH logins from your backup server:
Log in as root to the backup server, enter
cd /root/.ssh
ssh-keygen -t rsa -b 2048
(choose a randomish name eg "keyname" and press enter twice when prompted for a passphrase)

chmod 600 keyname*
scp keyname.pub 192.168.1.1:/root/.ssh/
(replace 192.168.1.1 with ip of main server)

- Enter the main server root password. The keyfile will be copied.

- Now connect to the main server (replace 192.168.1.1 with actual ip)
ssh 192.168.1.1
(log on as root)
cd /root/.ssh

if [ ! -f authorized_keys ]; then touch authorized_keys ; chmod 600 authorized_keys ; fi
(above "if" command should all be on one line)
cat keyname.pub >> authorized_keys
rm -f keyname.pub
exit

- Create backup script on backup server:
mkdir /root/scripts
pico -w /root/scripts/backup

Code: [Select]


# Make sure you check
# /usr/lib/perl5/site_perl/esmith/Backup.pm
# for the correct backup file list for your SME version
# it begins with "sub restore_list" (near line 70)

# Replace this IP with your remote host IP
RMH=192.168.1.1
# Directory where you are storing the backups
BDIR=/backups/daily
# Limit bandwidth to x Kb/sec (this is good on my 245 kbs upstream)
BW=19

# Uncomment the below line when on the local network (0=no limit)
BW=0

echo -n "Backup begun "; date;

# All these are directories - note trailing slashes
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/home/e-smith/ $BDIR/home/e-smith/
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/e-smith/templates-custom/ $BDIR/etc/e-smith/templates-custom/
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/e-smith/templates-user-custom/ $BDIR/etc/e-smith/templates-user-custom/
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/root/ $BDIR/root/
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/ssh/ $BDIR/etc/ssh/

# All these are files - note no trailing slashes
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/group $BDIR/etc/group
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/gshadow $BDIR/etc/gshadow
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/passwd $BDIR/etc/passwd
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/shadow $BDIR/etc/shadow
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/samba/smbpasswd $BDIR/etc/samba/smbpasswd
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/samba/secrets.tdb $BDIR/etc/samba/secrets.tdb
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/smbpasswd $BDIR/etc/smbpasswd
rsync -aqzH --bwlimit=$BW -e ssh $RMH:/etc/sudoers $BDIR/etc/sudoers

echo -n "Backup completed"; date;


- Make some directories
mkdir /backups
cd /backups
mkdir daily

- Do an initial backup.
/root/scripts/backup


This will take a long time to execute. Your best bet is to run it overnight.

- Now create some more directories on your backup server
cd /backups
mkdir day.1
mkdir day.2
mkdir day.3
mkdir day.4
mkdir day.5
mkdir day.6
mkdir day.7

mkdir week.1
mkdir week.2
mkdir week.3
mkdir week.4
mkdir week.5

- We're doing this to create a week's worth of daily backups, plus a month's worth of weekly backups. If you need a different backup scheme, you can always create extra directories and scripts. You could even create hourly backups if you wanted to - you're only limited by disk space and internet bandwidth. (eg mkdir hour.1-23 or mkdir month.1-12)

For each directory set, you need to create a script like the ones below:
pico /root/scripts/rotateday

Code: [Select]


rm -rf /backups/day.7
mv /backups/day.6 /backups/day.7
mv /backups/day.5 /backups/day.6
mv /backups/day.4 /backups/day.5
mv /backups/day.3 /backups/day.4
mv /backups/day.2 /backups/day.3
mv /backups/day.1 /backups/day.2
cp -al /backups/daily /backups/day.1


pico /root/scripts/rotateweek

Code: [Select]


rm -rf /backups/week.5
mv /backups/week.4 /backups/week.5
mv /backups/week.3 /backups/week.4
mv /backups/week.2 /backups/week.3
mv /backups/week.1 /backups/week.2
cp -al /backups/daily /backups/week.1


(etc)

- These scripts use "hard links" instead of copying the files. This means that you save tons of disk space, basically, as each version of a file is only stored once, rather than being duplicated 7 times for each daily backup, for example.

Now shutdown your backup server and move it to the remote location. Plug it into the internet and check that you have internet access.

pico -w /root/scripts/backup
Change the RMH value to your main server remote access ip or hostname
eg:
RMH=202.123.45.67
or
RMH=www.yourserver.com

Now create a cron job to automate the whole process:

mkdir -p /etc/e-smith/templates-custom/etc/crontab/
pico -w /etc/e-smith/templates-custom/etc/crontab/backups

Code: [Select]


# Backup the server. Do this just before we rotate the backups.
# Since we are rotating backups daily at 3 AM, we will do the backup at 1 AM daily.
0 1 * * * root /root/scripts/backup

# Rotate daily backups (3 AM every day)
0 3 * * * root /root/scripts/rotateday

# Rotate weekly backups (4 AM, Saturdays)
0 4 * * 6 root /root/scripts/rotateweek


- If you were doing hourly backups (weekdays every hour 9AM-8PM), you would change the first entry to
0 9-20 * * 1-5 root /root/scripts/backup
and add an entry
# Rotate hourly backups every hour @ 45 mins past (9:45AM-8:45PM)
45 9-20 * * 1-5 root /root/scripts/rotatehour
(replace rotatehour with whatever you called that script)

- Anyway, once you have the cron entries how you like them:

/sbin/e-smith/expand-template etc/crontab
less /etc/crontab  - to verify that your new crontab entries are there, then
service crond restart

There you have it.
By the way, if you have mysql databases on the main server, it's a good idea to dump them to .sql files periodically.
Create a script on the main server like:
pico -w /root/scripts/mysql_dump.sh

Code: [Select]


# Backup all the mysql databases:
 mysqldump -Af --add-drop-table --compact > /root/scripts/total_mysql_backup.sql


and call it with a cron job (see above for how to do this). It's a good idea to backup the databases just before the remote backup script executes.

It's also a good idea to keep copies of all your contribs and RPM's in somewhere like
/root/rpms/

That way, they'll be backed up along with everything else.

===============

To restore the backups (on SME 7, will probably work on others with minor modification)

- For individual files or groups of files, you can just execute scp commands on the backup server - eg:
scp /path/to/directory/* 202.123.45.67:/path/to/directory/*

If your main server is completely screwed, you need to do a full restore as follows:

- Fetch the backup server and hook it up to the same local network as the main server.
- Do a full format / reinstall of the main server, after replacing faulty hardware. Install it in server only mode, give it an ip of 192.168.1.1
(or whatever it used to be).

- On the main server:
signal-event pre-restore

- On the backup server:
pico -w /root/scripts/backup

Swap the file paths around in the script

Code: [Select]


rsync -aqzH --bwlimit=$BW -e ssh $BDIR/home/e-smith/ $RMH:/home/e-smith/
rsync -aqzH --bwlimit=$BW -e ssh $BDIR/etc/e-smith/templates-custom/ $RMH:/etc/e-smith/templates-custom/

do this for every rsync line in the script.
Also change the bandwidth limit back to 0 (ie unlimited)
Then save the file and execute the script.

/root/scripts/backup

Wait a while. Once the restore has finished, log on to the main server:
signal-event post-upgrade
signal-event reboot

After that, your server will be back, exactly the same as it was.
If your network cards have changed, you may have to run "configure settings" to get them to work.

Also, you might need to reinstall contribs / RPMs and restore your mysql databases.

Cheers,
Silas.