Backup and Restore of Alfresco MySQL database

[pauldavidmena]

I am in the process of migrating an existing ACS 4.2.6 system to a new data center. The original instance used LDAP for authentication, whereas I am using local authentication on the new instance. To keep the data current, I have been syncing the /alf_data partition from the existing instance to the new one, in addition to performing a mysqldump of the existing instance and restoring to the new instance. Once I've started to create local users on the new instance, should I no longer be backing up and restoring the database to the new server?

Thank you in advance!

Paul Mena

[cristinamr]

Hi!

....should I no longer be backing up and restoring the database to the new server?

In general terms:

• Stop your alfresco.
• Backup your database
• Backup your content store
• Backup your index (optional but recommended)
• Restore one by one

More info.

Cheers,

Cris.

[pauldavidmena]

Thank you for the quick reply. I agree that the steps you have outlined are correct for general use. I should have clarified that I have backed up and restored both the dir.root (/alf_data) and the mysql database multiple times, but have now reached a point where I am defining users locally on the new server. My concern is that restoring the database from the original server will overwrite local authentication data on the new. If that's not the case, I'll continue the practice.

Thanks again!

[cristinamr]

I think you are mixing the concepts here.

Users have an internal clasification about where they has been created. For example, if I create a internal user , this is ntlm, and I can see something like this though the node browser:

If you have a members already created on ldap, you should figure out how can you migrate their permissions to the new alfresco internal users.

Being honest: I don't know if there is an easy method. Maybe @afaust can clarify this.

Cheers,

Cristina.

[afaust]

If I understand @pauldavidmena correctly, they are restoring the "entire" Alfresco database from one system in the old data center to a system in the new data center. In that case they are of course loosing ALL the changes they have made in the system on the new data center, including any users they have created locally within Alfresco, but also any changes to content etc.

So if the intention is to keep the old system running but already prepare / change stuff in the new system, then yes, there it would be counterproductive to continue to backup and restore the database and alf_data. In general, by using this approach you will make your life way more complicated, as you will then have to go into the old system and selectively export any changes that have been made there, to then import them into the new system - and do all of this with an export / import mechanism that has not really been designed to faciliate easy export / import by users / administrators, but is more geared towards developers to prototype content structures, and be able to quickly bootstrap them in new systems / versions of extension modules.

[pauldavidmena]

@afaust Thank you for the reply. To clarify, the new server is not being used just yet, but my current efforts are focused on getting a subset of the old server's users set on the new server so that it will be our production Alfresco server going forward. We've had issues setting up LDAP in the new data center (the clone we made of the old data center is running CentOS 5, among other problems) and therefore have been leaning toward trying to use local authentication instead. To this end, the rsync of /alf_data and the dump/restore of the mysql database was an effort to keep the cloned Alfresco server up-to-date. I suspect that once we start using the new server we'll need to stop one or more of those daily "refresh" tasks lest we lose the new configuration data. I was trying to clarify which task I should continue versus which I should stop doing.

Thank you again!