RE: [cobalt-users] Tarring entire drive and moving... what would break?

["John Cordeiro" <jcordeiro@xxxxxxxxxxxxxxx>]

Here is a doc I found, Worked great for me. Follow it step by step.

The following information below has been verified and used by the Cobalt
EMEA team during their office move a few months ago. We had to make mirror
images of several RaQ3's and 4's.

This document was written for the RaQ3i. It basically involves stopping the
entire server for the duration of the backup to make a complete clean image.
This allowed for minimal downtime (an hour or less) for the servers and we
had duplicate machines in the new office ready and waiting for the network
to switch over.

Additional steps for the RaQ4 include:

a. stopping the ASP Server via:

/etc/rc.d/init.d/asp-apache-3000 stop
/etc/rc.d/init.d/asp-admin-3000 stop

b. if you have anything else on the box, make sure it's not running.

c. do a 'ps aux' to double check that services did stop when you issue the
stop command. if not, use 'killall process-name'.


if you aren't comfortable (this is the step after familiar) with the linux
command-line, you should not be doing this.

//begin//

FULL BACKUP (note that this will make the server unavailable for the
duration of the backup)

1. Telnet to your raq3
2. su to root
3. Shutdown all non essential services

/etc/rc.d/init.d/crond stop
/etc/rc.d/init.d/syslog stop
/etc/rc.d/init.d/admserv stop
/etc/rc.d/init.d/httpd stop
/etc/rc.d/init.d/sendmail stop

4. Make a backup directory on /home

mkdir /home/backup
chown postgres /home/backup

5. su to postgres and go to postgres home directory

su postgres
cd ~

6. Edit pg_hba.conf to allow access to cobalt database (change 'local all
crypt' to 'local all trust')

cp pg_hba.conf pg_hba.conf.master
vi pg_hba.conf

7. Backup the postgres database (Cobalt gui) then exit from postgres user
(this is extra insurance - my raq restored OK without having to re-import
the database but PLEASE do this anyway)

pg_dump cobalt > /home/backup/cobalt.dump
cp pg_hba.conf.master pg_hba.conf
exit

8. Shutdown postgres

/etc/rc.d/init.d/postgresql stop

9. Backup the full raq3 (I would recommend backing up to local disk on /home
if there is enough space, otherwise an NFS share or to tape, or lastly a
samba share. It might be a good idea to also make a tar backup for extra
insurance with '--exclude /home/pgsql' as this directory will not backup and
restore with tar)

find / | cpio -ov > YOUR_NFS_OR_SAMBA_SHARE_OR_TAPE_UNIT_OR
LOCAL_DIRECTORY/FILENAME

10. Restart the server

/sbin/shutdown -r now


FULL RESTORE

1. Telnet to your new raq3 (you should have at least run the wizard so it
has a name and passwords)
2. su to root
3. Shutdown all non essential services

/etc/rc.d/init.d/crond stop
/etc/rc.d/init.d/syslog stop
/etc/rc.d/init.d/admserv stop
/etc/rc.d/init.d/httpd stop
/etc/rc.d/init.d/sendmail stop
/etc/rc.d/init.d/postgresql stop

4. Make your backup accessible (ftp it onto the /home partition, connect to
your tape unit, setup nfs or samba depending on the method you used to
backup /size of file/disk space, etc)

5. Restore the data

cpio -iduv < YOUR_NFS_OR_SAMBA_SHARE_OR_TAPE_UNIT_OR
LOCAL_DIRECTORY/FILENAME

5. Restart the server

/sbin/shutdown -r now

6. TEST TEST TEST - Test the restored raq (you will have to figure this out
yourself as it will have the same ip address and services running as the
first raq - you may want to set up a "private internet" - ie one PC with a
crossover cable connected to the raq so that you can run it without making
any changes)I only did a backup of the database for the sake of extra
safety.

DIDN'T WORK?

cpio restored my raq ok (including the postgres database) without having to
restore the database separately, but this does not necessarily mean this
will always be the case. If there is a requirement to restore it under
certain circumstances, then this is what you need to do:

1. Telnet to your raq3
2. su to root
3. Shutdown all non essential services

/etc/rc.d/init.d/crond stop
/etc/rc.d/init.d/syslog stop
/etc/rc.d/init.d/admserv stop
/etc/rc.d/init.d/httpd stop
/etc/rc.d/init.d/sendmail stop

4. Make a backup directory on /home and copy the database dump to it (from
the admin ftp mdirectory I guess!)

mkdir /home/backup
cp /home/sites/home/users/admin/cobalt.dump /home/backup/cobalt.dump
chown -R postgres /home/backup

5. su to postgres and go to postgres home directory

su postgres
cd ~

6. Edit pg_hba.conf to allow access to cobalt database (change 'local all
crypt' to 'local all trust')

cp pg_hba.conf pg_hba.conf.master
vi pg_hba.conf

7. Delete the old postgres database, recreate it and restore it then exit
from postgres user.

destroydb cobalt
createdb cobalt
psql cobalt < /home/backup/cobalt.dump
cp pg_hba.conf.master pg_hba.conf
exit

8.Shutdown postgres and restart server

/etc/rc.d/init.d/postgresql stop
/sbin/shutdown -r now

NOTES:

I have not tried compressing the cpio backup file. I think it will work (I
have not tested this - use at your OWN RISK!), though, if you use the -c
option which creates an ascii file so use:

find / | cpio -ocv > YOUR_NFS_OR_SAMBA_SHARE_OR_TAPE_UNIT_OR_FILE

then gzip or compress the file (you could try piping to gzip or compress,
depending on how big the backup is and how much memory is available it might
work)
To restore you'd have to uncompress or gunzip the file first then:

cpio -idcuv < YOUR_NFS_OR_SAMBA_SHARE_OR_TAPE_UNIT_OR
LOCAL_DIRECTORY/FILENAME

I have only done a full backup and restore. If you only want a partial
backup then make sure you at least back up the following directories (also
untested so use at your OWN RISK!):

/etc
/home
/usr/admserv
/usr/local

//end//