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

Note

CTERA recommends reverting a database only with the help of CTERA support.

When reverting a CTERA Portal primary database to a previous snapshot, any files synced to the portal after the time of the snapshot are missing in the portal. This data is never synced to the portal when the devices are reconnected to the portal unless they physically existed on a device and not just as a stub file.

Note

Even though the data is no longer available, it will still be displayed as stub files on edge filers. You can use these stub files to identify the data that was added to the portal after the revert date. These files should be deleted from the edge filer. As long as the stub files exist on the edge filer, the sync status will indicate that there is a sync error.

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 Rolling Back PostgreSQL Continuous Archiving to a Previous Point-in-Time. 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.

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. Suspend syncing on all devices connected to the portal.
  2. Roll back the CTERA Portal primary database, as described in described in Rolling Back PostgreSQL Continuous Archiving to a Previous Point-in-Time.
  3. Using SSH, log in as root to every CTERA Portal application server except for the primary database server.
  4. 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
  5. Using SSH, log in as root to the CTERA Portal primary database server.
  6. Enter the following command to change the Portal UUID: change-portal-gvsn
  7. Restart all the application servers you stopped using the following command: portal-manage.sh start
  8. Resume syncing on all devices connected to the portal.

Was this article helpful?