CoreMedia Content Server Manual, Version 7.5.45-10
3.10. Administrating Replication Live Servers | 3.10.5. Restoring from Master Live Server Backup

If you are a skilled administrator, you do not need to create backups from Replication Live Server. Instead, you can use a backup from the Master Live Server. However, this procedure requires that you execute some SQL statements. To restore a Replication Live Server database from a Master Live Server backup you have to do the following:

Caution

If you have a client connected with your Replication Live Server that uses the timestamp of the server (for example, the CAE Feeder) you have to find the last "sequenceno" in the "changelog" table of the Master Live Server and Replication Live Server where both servers where in sync. You also have to check, if the client has already processed this event. Do this, before you replace the Replication Live Server database.

Finding the last common sequence number

Finding this sequence number is a bit tricky, because the numbers are different on different Content Servers. Therefore, you have to find the last common event in the changelog (see Section 2.5, “Changelog”) tables of both Content Servers. To do so, proceed as follows:

SELECT * FROM changelog WHERE sequenceno = (SELECT max(sequenceno)
 FROM changelog WHERE code != 15);

SELECT sequenceno FROM changelog WHERE code=<ReplicationCode> 
AND I1=<ReplicationI1> AND I2=<ReplicationI2> AND I3=<ReplicationI3> 
AND B1=<ReplicationB1> AND B2=<ReplicationB2> AND S1=<ReplicationS1> 
AND S2=<ReplicationS2> AND S3=<ReplicationS3>

This gives you the sequence number for further processing in "Clients and Timestamps" below.

Now, you have to check if the client has already processed the event with this timestamp. Otherwise, you might lose events. In the case of the CAE Feeder execute the following SQL script on the CAE Feeder's database:

SELECT * FROM pcproperties;

This returns a result as shown in the following example:

com.coremedia.amaro.persistentcache.propertystore.PropertyVerifier
-application caefeeder
com.coremedia.amaro.cae.feeder.IndexVerifier CAEFEEDER:1252067316056
ContentDependencyInvalidator-timestamp 442525:1:866469822
com.coremedia.cap.persistentcache.proactive.content.ContentTrigger.
timestamp.trigger 442366:6:866469822

Take the content of the properties with "timestamp" in their name. The first number in the content of these properties is the sequence number of the last event. These numbers must be equal or larger than the common sequence number you have found above. If it is smaller, you have to look for a smaller common sequence number, otherwise you would lose events in the CAE Feeder.

Restore the database

SELECT * FROM changelog WHERE sequenceno = (SELECT max(sequenceno)
 FROM changelog);

INSERT INTO system (property, content) VALUES ('replicator_remote',
 '<sequenceno>');
INSERT INTO system (property, content) VALUES ('replicator_local',
 '<sequenceno>');
INSERT INTO system (property, content) VALUES ('replicator_tag',
 '<idtag>');

DELETE FROM CmLicenses

UPDATE system SET content='live' WHERE property=
'repository_server_type' AND content='publication'

Clients and Timestamps

The CoreMedia systems uses timestamps to synchronize servers and clients. If you replace the database of a Replication Live Server with the database of a Master Live Server, the timestamp of the Replication Live Server will be replaced by the one of the Master Live Server. Every client, that connects with the Replication Live Server and that stores and uses the timestamp - such as the CAE Feeder - will stop working because the stored timestamp is different from the new timestamp of the Replication Live Server.

In order to synchronize client and server again, you have to replace the timestamp stored by the client with the timestamp of the server. To do this for the CAE Feeder, proceed as follows (replace the angle brackets with the appropriate value):

SELECT * FROM changelog WHERE sequenceno=<No from step 1>

UPDATE pcproperties SET content='<Master Timestamp>' WHERE
property='com.coremedia.cap.persistentcache.proactive.
content.ContentTrigger.timestamp.trigger';

UPDATE pcproperties SET content='<Master Timestamp>' WHERE
property='ContentDependencyInvalidator-timestamp';

Now, the feeder starts working again. Log errors like "Illegal transition for feeder:coremedia:///cap/content/701282:add" are harmless. They only say, that this content has been fed before.