Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Restore Apstra Database

CAUTION:
Always restore a database from a new backup; never restore a database from an older backup. Changes made after backing up a database would not be included in the restore and could lead to differences between device configs and the Apstra environment. If this happens, you would need to perform a full config push, which is service-impacting.
Note:

If you're restoring a backup to a new Apstra server that uses a different network interface for access (eth1 vs eth0 for example), you must update the metadb variable in the [controller] section of the /etc/aos/aos.conf configuration file, then restart the Apstra server.

  1. Verify that the contents of the snapshot folder are on the filesystem. In the example below, we have copied the restoration data to /tmp/aos_test_restore.
  2. Run the aos_restore command as illustrated below. The restore process first backs up the current database.
  3. When the database has been restored and migrated to a new server, the entire system state has been copied from the backed up installation to the new target. Run the command service aos status to validate the restoration.
  4. The database is stored on the Apstra server itself. If the server needs to be restored or if its disk image becomes corrupt, any backups/restores are lost along with the Apstra server. We recommend that you periodically move backups/restores off of the Apstra server to a secure location. Also, if you've scheduled cron jobs to periodically backup the database, make sure to rotate those files off of the Apstra server to keep the Apstra server VM disk from becoming full. Copy the contents of the snapshot directory to your backup infrastructure.