Changes

If you use any add on contrib for backup purposes eg Affa or Dar2 or whatever, then after doing a fresh reinstall of the sme OS, the first thing you do is reinstall the backup contrib and do some basic configuration manually. Then you would restore using that contrib, then you can reinstall all other contribs etc.

If you use any add on contrib for backup purposes eg Affa or Dar2 or whatever, then after doing a fresh reinstall of the sme OS, the first thing you do is reinstall the backup contrib and do some basic configuration manually. Then you would restore using that contrib, then you can reinstall all other contribs etc.

It's good admin practise to create an ibay specifically to house a copy of every rpm you install, so you can easily reinstall those from your backed up and restored copies, although with yum repos being available now, it's not so necessary to do this. It does provide a reminder of everything you have installed though, in case you forget.

It's good admin practise to create an ibay specifically to house a copy of every rpm you install, so you can easily reinstall those from your backed up and restored copies, although with yum repos being available now, it's not so necessary to do this. It does provide a reminder of everything you have installed though, in case you forget. You should also do this if you wish to retain specific versions of rpms and source rpms, and also include copies of dependency rpms for good measure too.

The Affa contrib provides you with a report of missing rpms (if you enable that setting), which is the difference between the source server and the backup server, so you can easily see what needs reinstalling after a restore or Affa "rise", or install those on the Affa backup server in advance (if using a separate backup server).

The Affa contrib provides you with a report of missing rpms (if you enable that setting), which is the difference between the source server and the backup server, so you can easily see what needs reinstalling after a restore or Affa "rise", or install those on the Affa backup server in advance (if using a separate backup server).

Note that a tape backup backs up all file systems on the server, but only restores the "standard restore" files. See this list http://wiki.contribs.org/Backup_server_config#Standard_backup_.26_restore_inclusions

Note that a tape backup backs up all file systems on the server, but only restores the "standard restore" files. See this list (above) http://wiki.contribs.org/Backup_server_config#Standard_backup_.26_restore_inclusions

A full restore from a tape backup to a freshly installed sme OS, will cause all sorts of issues. The restored server will start to boot up but then grind to a halt during the startup/post configuration processes.

A full restore from a tape backup to a freshly installed sme OS, will cause all sorts of issues. The restored server will start to boot up but then grind to a halt during the startup/post configuration processes.

You need to perform a bare metal or disk clone backup to achieve that.  

You need to perform a bare metal or disk clone backup to achieve that.  

A contrib that does that is Mondo, but it appears to have not been updated to be compatible with sme7.x.  

A contrib that does that is Mondo, but it appears to have not been updated to be compatible with sme7.x.  

Another way of easily doing this is to swap out a RAID1 disk, and plug in a clean (empty) disk. There will only be a few minutes downtime while the disk is swapped, as hot swap is not currently supported. After the clean disk is inserted, then use the admin console to resync the RAID1 array.

Another way of easily doing this is to swap out a RAID1 disk, and plug in a clean (empty) disk of exactly identical size or larger. There will only be a few minutes downtime while the disk is swapped, as hot swap is not currently supported. After the clean disk is inserted, then use the admin console to resync the RAID1 array. The system will happily run on one disk in degraded mode until the synchronisation is complete.

Disk cloning software can also be used, but it must support RAID partitions and lvm volumes, and some cloning software does not.

Disk cloning software can also be used, but it must support RAID partitions and lvm volumes, and some cloning software does not.

The Linux dd command will also copy every bit on a disk, to another mounted disk, but it will be slow and may take a long time (many many hours) for a disk with a lot of data. The server would ideally be disconnected from the local network and the Internet during this operation to prevent data changing on the server during the disk clone/backup process.

The Linux dd command will also copy every bit on a disk, to another mounted disk, but it will be slow and may take a long time (many many hours) for a disk with a lot of data. The server would ideally be disconnected from the local network and the Internet during this operation to prevent data changing on the server during the disk clone/backup process. Issue the command man dd for further information.

Each of these methods has their own practical issues, choose the one that best suits your situation.

Each of these methods has their own practical issues, choose the one that best suits your situation.

The DAR2 contrib has a web interface that is configurable and allows you to create the disaster recovery backup (ie all data and configuration) required to rebuild a server, but you still need to reinstall add on contribs (rpms). It also allows allows selective backup jobs to be done, eg of certain ibays only, depending on your particular needs.

The DAR2 contrib has a web interface that is configurable and allows you to create the disaster recovery backup (ie all data and configuration) required to rebuild a server, but you still need to reinstall add on contribs (rpms). It also allows selective backup jobs to be done, eg of certain ibays only, depending on your particular needs.

===Reference links===

===Reference links===