Hi Simon,

> Fair enough, I was just starting to look into backing up config via
> cmuExport and then rsyncing data to a seperate server, will check out
> those ideas too and see which works best for me.

It would be lovely if that worked, but I fear it will not. One of the cardinal 
problems here is this:

With CMU there is no guarantee that your export of "site1" will be restored as 
"site1". It may be re-imported with a completely different GID and site 
number. That makes it near impossible to re-import your separate rsync export 
into the right places and to assign it the right GIDs.

I know people that use rsync exclusively to back up their RaQ550s. Aside 
from /home/sites, /var/lib/mysql, all config directories 
like /etc/, /var/named and so on they also back up /var/db/ 
and /usr/sausalito/codb/

When I see that my hair stands on end as it entails a whole bunch of problems.

The tricky part here is that /usr/sausalito/codb/ not only contains 
configuration data about sites, users and settings, it also contains 
application data. Like installed patches, third party software information 
and so on.

So imagine what happens when you OS restore a RaQ550 and then rsync that stuff 
back in without patching? BlueLinQ will then show all the patches and third 
party software that you had installed on the old box, while that software is 
in fact not present. 

Likewise the GUI may report the wrong configuration of daemons and services as 
the CODB values are still populated with the info from the old box. For 
instance: On the old box you had POP-before-SMTP ticked in the GUI. But on 
the OS restored box you forgot to enable it. Now thanks to installing the 
copy of /usr/sausalito/codb/ the GUI reports POP-before-SMTP being on, while 
it in fact is off. All in all this creates a whole plethora of minor and 
major problems which will haunt and hurt you in the long run.

Generally I'd say using CMU is your best bet to create a backup set that 
creates the least hassles upon restore, but it sure uses a lot of ressources 
when it runs thanks to Perl and the fact that it's always a full backup and 
not incremental. 

-- 

With best regards,

Michael Stauber

_______________________________________________
Cobaltfacts site list
[email protected]
http://list.cobaltfacts.com/mailman/listinfo.cgi/cobaltfacts

Reply via email to