close

Filter

loading table of contents...

Content Server Manual / Version 2406.1

Table Of Contents

3.8.1 Backup Strategy

You need to have database backups to recover from database failures. The backups are created with database tools. The chronological order of the backups is crucial:

  1. Backup one of the Replication Live Servers.

  2. Backup the Master Live Server.

  3. Backup the Content Management Server.

Caution

Caution

Note, that recovery will not work correctly, if this given chronological order of backups is not respected. The content of the Content Management Server must be newer than the content of the Master Live Server, and the content of the Master Live Server must be newer than the content of the Replication Live Servers. The time between the single backups should be short. Try to avoid publishing deletions while the backups are made.

When you backup the database of any server, make sure that the database is consistent, that is, it represents the exact state of the database at a certain point of time. The exact backup procedure depends on your database product and likely on the configuration of your database.

If you use a custom blob store as described in Section 3.3, “Configuring Blob Storage” and if the blob data is not stored in the same database as the remainder of the content data, use the following procedure for each server:

  1. Suspend deletion of unused blobs by sending a POST request to the blobcollector actuator endpoint, for example:

    curl -X POST -H "Content-Type: application/json" \
    -d '{"suspend": true}' \
    http://localhost:8081/actuator/blobcollector

    For details, see Section 4.10.8, “Content Server Blob Collector Endpoint” in Operations Basics. Alternatively, you can set the property sql.store.collector.suspend to true and restart the Content Server.

  2. Wait 20 seconds to give the blob collector a chance to shut down.

  3. Backup the Content Server database.

  4. Backup the data store. This might be a file system backup or a backup of a separate database.

  5. Resume deletion of unused blobs again, by sending a POST request to the blobcollector actuator endpoint, for example:

    curl -X POST -H "Content-Type: application/json" \
    -d '{"suspend": false}' \
    http://localhost:8081/actuator/blobcollector

    Alternatively, you can set the property sql.store.collector.suspend to false and restart the Content Server.

If the collector is suspended, it will collect blobs again when it is run the next time. By default, it runs once a day. This might be a problem, if your backup procedure also mandates daily backups, continually preventing the collection of blobs. If you see the message "Blob deletion is suspended" with log level info on the log facility hox.corem.server.sql.SQLStore.blobcollector more than occasionally, you should set the property sql.store.collector.startTime in such a way that the collector starts soon after your backup is finished. The property sql.store.collector.startTime is given in seconds after the start of the day in the default time zone.

Search Results

Table Of Contents
warning

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.