Reverting the Primary Database to a Snapshot
  • 1 Minute to read
  • Dark
    Light
  • PDF

Reverting the Primary Database to a Snapshot

  • Dark
    Light
  • PDF

Article Summary

When reverting a CTERA Portal primary database to a previous snapshot, any files synced to the portal from the time of the snapshot to the present are not resynced and are therefore missing in the portal This data is never synced to the portal when the devices are reconnected to the portal, unless a manual procedure is performed.

You have to revert to a snapshot of the virtual machine when the actual database has become corrupted and not the data itself. If it is only the data that needs reverting to a previous point-in-time, rollback the database, as described in the note below.

To ensure the portal and devices are synced after reverting to a snapshot:

Warning

This procedure must be performed immediately after reverting to the snapshot and before connecting any device to the portal.

  1. Using SSH, log in as ‘root‘ to every CTERA Portal application server except for the primary database server.
  2. In the command line of every CTERA Portal application server except for the primary database server, enter the following command to stop the server: portal-manage.sh stop
  3. Using SSH, log in as ‘root‘ to the CTERA Portal primary database server.
  4. Enter the following command to change the Portal UUID: change-portal-gvsn
  5. Restart all the application servers you stopped in step 2 using the following command: portal-manage.sh start
Note

When you rollback the database to a previous point-in-time, after continuous archiving has been set up, any files synced to the portal from the time of the database is rolled back to, to the present are synced when the devices are reconnected to the portal. You can roll back to an older version of the portal database, as described in Rolling Back PostgreSQL Continuous Archiving to a Previous Point-in-Time.


Was this article helpful?