Arnaud
I reinstalled sme from the old CD + yum update --enablerepo=smecontribs
Not really the best practice recommended procedure.
Run a standard yum update, but do not include contribs from smecontribs at this stage.
It is also wise to reinstall contribs one at a time to ensure they each work correctly before installing more contribs.
If you install say 5 or 6 contribs at the same time (as well as regular updates), then it can be much more difficult to troubleshoot your server, in the event of errors or problems ie which contrib or update pkg to blame etc ???
Correct approach is
Install fresh OS
yum update
restore from backup
reinstall contribs one at a time using
yum install contribname --enablerepo=smecontribs
issue appropriate signal-event (as advised by contrib install instructions)
check contrib works & no server errors etc
repeat above 2 lines for each other contrib
The order of restore may vary if you restore from USB on first reboot after installing the clean OS from CD, if so, then follow that with a general purpose
yum update
I restored the datas from the backup with affa --full-restore via nfs and the sme was ok again.
are you sure for the normal order of the operations? First restore from backup then install the contribs? Is it not a problem if parameters are set for not present things??
Refer to
http://wiki.contribs.org/Backup_server_config#Backup_and_Restore_concepts.2C_issues_and_other_informationand if you still prefer not to believe me or that article, then search these forums on restore backup & posts by CharlieBrady, as he has mentioned this correct procedure order many many times over the years.
AFAIUI, the contrib install process will use the existing restored configuration (conf) files instead of creating new default conf files. The restored db settings are invoked after appropriate signal events following contrib installation with yum or rpm command.
In any case it is very angrily to loose 1 complete day because of it (installation + contribs + restoring the datas).
Being angry does not help, computer equipment fails, that is a fact of life, you have to get in & fix it, that is a fact of life too.
Did you ever practice or rehearse your restore procedures on a test system, before assuming they would all work correctly when critically needed ?
Part of a good backup system is to prove that restores (ie restore procedures) will work correctly. Assuming they will work correctly is not good enough.
The other important stress factor was that all my backups have been made and recovered by affa V2 and I didn't know if the problem was a faulty disk, a faulty SME, a faulty archive or a faulty program.
Or a faulty operator, or a combination of some or all of those reasons.
Combine perhaps with not having fully tested restore procedures & proven to yourself they work correctly when critically needed.
Also have you ran full surface scans on those hard disks using drive manufacturers diagnotic test software (google UBCD), and ran the long smartctl tests ?
Also do memory tests on your servers memory, there are instructions here somewhere (FAQ maybe), & I think also on the install CD booted up in Rescue mode.
If not done, you should do so ASAP !
Having multiple backups created using different methods is good backup policy.
Doing a test restore using each backup method & proving the system & data is fully restored, is also part of a good backup policy.
Read some other posts elsewhere in these forums, some people claim I speak my mind too freely, & then they verbally abuse me for it, not nice considering I thought I was being quite polite, so thank you for thanking me & appreciating my efforts.