Backups

Backups is used to create, manage and restore repository backups.

Actions

Backup - Create a new backup of the current repository. Backups are created in the background and do not interupt standard user or system activities. Once a backup is started, the alert panel will display backup progress. Once completed, the backup will display in the list.
Info - Display information about the selected backup file, including the app or tool used to produce the backup, format, version and other metadata. Compressed and archived backups will be decompressed to access the metadata, which may take some time.
Restore - Restore the selected backup to the current repository. This is a destructive operation, so a new backup should typically be created before a restore is performed. The restore process is:
- Lock database configuration - First, the database configuration is locked to prevent other processes from accessing the configuration until restore preperation is completed.
- Lock database - Next, the restore process will wait for all other processes accessing the database to finish.
- Create recovery tables - Once all active processes have finished database operations, existing database tables are renamed with a "recovery_" prefix. If the restore process encounters critical errors, the recovery tables will be rolled-back. If the restore process is successful, the recovery tables will be removed.
- Update database configuration - The database configuration is updated to direct requests that occur during the restore process to the recovery tables. This helps minimize any interuption to services during the restore process.
- Unlock database and configuration - With the recovery tables in place and configuration updated, the database and configuration are unlocked to allow users and systems to continue functioning normally. The impact of the restore process at this point should only be a delay less than a few seconds long to any requests and processes that occured during the previous steps.
- Restore backup - The backup file is processed to restore the database tables to the state they were in at the time the backup was created. Progress will be displayed in the alert panel as the percentage processed. User and system operations will continue normally from the recovery database tables while this part of the process is performed.
- On failure, recover - If a critical error occured, whatever newly restored tables were created are removed. Then, the configuration file and database are locked again, recovery tables renamed back to their original names, configuration updated and database and configuration unlocked. The impact is typically another few second delay. The restore report, including any errors can be reviewed while operations continue normally with minimal interuption.
- On success, activate - If no critical errors occured, the configuration file and database are locked again to allow any active processes to complete. Then, the configuration is updated to direct future requests to the newly restored database tables. Next, the restore report is copied from the recovery repository, where it has been logged, to the newly restore repository. Then, the database and configuration is unlocked to allow new requests to be processed as quickly as possible. The impact is typically another few second delay. Finally, the recovery tables are removed, and any final information logged to the copied restore report.
  Updates made to the recovery tables during the restore process will be lost. To prevent updates during the restore process, deactivate the repository beforehand.
Remove - Remove the selected backup file(s). A confirmation dialog will be displayed.
Settings - Display a dialog with backup options, including backup folder, automatic backup frequency, retention policy and remote destination to copy automatic backups for redundancy.

Backup Files

Backup files are created and restored independent of other database tools. However, backup files are similar to a standard SQL database dump file, so they can also be restored using other database dump restore tools and procedures. Likewise, a standard SQL database dump file can be restored by Backups.

Backup File Formats

The following formats are recognized and can be restored.

webCOMAND 3 SQL - Text file with human readable standard SQL statements and hash line comments. Binary data is included inline as a string with back-slash escaped characters were appropriate.
webCOMAND 3 cJSON - Text file with human readable JSON with JavaScript-style comments (aka cJSON). Binary data is stored in seperate files referenced within the JSON. For more information, see cJSON.
webCOMAND 3 XML - Text file with human readable XML with comments. Binary data is stored in seperate files referenced within the XML. For more information, see XML.
MySQL Dump - Text file with human readable standard SQL statements and hash line comments. Binary data is included inline as a string with back-slash escaped characters were appropriate.
phpMyAdmin Export - Text file with human readable standard SQL statements and double-dash and C-style comments. Binary data is included inline as a string with back-slash escaped characters were appropriate.
webCOMAND 2 - Backups from the previous version of webCOMAND are recognized and can be restored. Once restored, the database will be automatically upgraded for webCOMAND 3.
Compressed Archives - Zip, Tar and Gzip archives are recognized and decompressed automatically as required.