cancel
Showing results for 
Search instead for 
Did you mean: 

Need advice about backup/restore

zomurn
Champ in-the-making
Champ in-the-making
Hello,

I'am was wondering how to proceed for backup/restore of the server in this scenario:

1) The production version is working well.
2) I backup the production version
3) 1 week later, I update the custom model into which I add more metadata. Hence, I apply the default new metadata values to all documents in production.
4) The application in production crash…I need to do restore from step 2).
….
Documents in production have the new metadata which are not present anymore in the model due to restore….how to deal with this scenario ??

Help me please
23 REPLIES 23

derek
Star Contributor
Star Contributor
Hi,
Yes, once you're out of 2008 (i.e. now) you can stop backing that data up, assuming you don't discard your 2008 backups.
Regards

zomurn
Champ in-the-making
Champ in-the-making
Hi,
Revert to the original database before attempting the upgrade again.
At some or other point, you attempted an upgrade (or installation) that either failed or was terminated midway.  You need to revert to a good copy of the data.  You will not be able to recover the server with any confidence.  When you upgrade Alfresco, you should be prepared to have schema updates applied and have the appropriate backups beforehand.
Regards

OK. So the question is, what provokes/causes this schema upgrade (background task ?)  ? Is it possible to know this in advance so as to be more careful for deployment ?

Thanks.

PS : the idea of backing up only some subdirectories of alf_data is tricky Smiley Happy (close to incremental backup after all).

derek
Star Contributor
Star Contributor
The upgrade is not a background task.  It occurs at bootstrap when the war file is changed.  If it appeared to happen as a background task, check that you are not sharing the database with some dev environment and use proper db passwords, etc.  You can explicitly tell Alfresco to NOT upgrade the schema by adding this to your custom-repository.properties:
db.schema.update=false
but you should switch this to 'true' when you introduce a new war file.  At any rate, you should always start a new war file up against a test server with a copy of the live data.

zomurn
Champ in-the-making
Champ in-the-making
OK, thanks Derek !
So setting db.schema.update=false is useless at final, in which case we are able to set it to false ? It preserves the schema.
Otherwise, I constated something more about restore : when we backup alf_data+db, we need also to backup the licence, is it right ?
Because, If we forgot, we can't download the same licence and install it with the restored repository.
The 3 components alf_data+db+licence would be atomic so…

At any rate, you should always start a new war file up against a test server with a copy of the live data.

That's exactly the requirement I told to my customer : a pre-production server. Smiley Happy
Furthermore, it covers us from our development because the customer does the beta tests on it ! Smiley Happy