Tutorial: How to Recover a Server with SQLite3 Dump Backup Files
Overview
Use this tutorial to restore an Access Server configuration using backup files. You can do this to recover an Access Server or move to a new Access Server installation.
An installed Access Server where you'll restore the backup configuration.
Console access and the ability to get root access.
While creating backups can be done with Access Server up and running, restoring a backup to a new installation of Access Server must be done with the Access Server service turned off. We assume you have an Access Server installation to which you wish to restore a backup set. Our instructions on restoring a backup include steps to stop the Access Server service, restore the backup set, and start the Access Server service again.
Sign in to the console and get root privileges.
Run these commands to stop the Access Server service and restore the backup:
systemctl stop openvpnas which apt > /dev/null 2>&1 && apt -y install sqlite3 which yum > /dev/null 2>&1 && yum -y install sqlite cd /usr/local/openvpn_as/etc/db [ -e ../../config.db.bak ]&&(rm -f config.db;sqlite3<../../config.db.bak config.db) [ -e ../../certs.db.bak ]&&(rm -f certs.db;sqlite3 <../../certs.db.bak certs.db) [ -e ../../userprop.db.bak ]&&(rm -f userprop.db;sqlite3 <../../userprop.db.bak userprop.db) [ -e ../../log.db.bak ]&&(rm -f log.db;sqlite3 <../../log.db.bak log.db) [ -e ../../config_local.db.bak ]&&(rm -f config_local.db;sqlite3 <../../config_local.db.bak config_local.db) [ -e ../../cluster.db.bak ]&&(rm -f cluster.db;sqlite3 <../../cluster.db.bak cluster.db) [ -e ../../notification.db.bak ]&&(rm -f notification.db;sqlite3 <../../notification.db.bak notification.db) [ -e ../../as.conf.bak ]&&cp ../../as.conf.bak ../as.conf chmod 0600 /usr/local/openvpn_as/etc/db/*.db chmod 0600 /usr/local/openvpn_as/etc/as.conf systemctl start openvpnasThese commands restore the configuration backup.
Some things could cause Access Server to fail to load properly:
The configuration could have instructions to listen to a specific network interface that doesn't exist on the new system.
The configuration could include instructions to run more OpenVPN daemons than the new system has CPU cores for.
If the configuration is set to listen to a specific IP, the web interface may not respond because it's set to listen to an address or interface that doesn't exist. To resolve this, refer to Reset OpenVPN web services and daemons to defaults. Once you have access to the Admin Web UI again, you can reconfigure your settings. Alternatively, you can manually configure the web server settings using the command-line tools.
The configuration database also contains settings on how many TCP daemons and UDP daemons to launch. If this is set higher than the number of available CPU cores, Access Server may become unstable. So if you have restored this configuration on a different server, and the number of CPU cores is different from the server the configuration backup came from, adjust this on the Network Settings tab found on the VPN Server page in the Admin Web UI, or refer to this tutorial: Tutorial: Reset Multi-Daemon Mode and Number of TCP/UDP Daemons. It may run if the amount is set too high, but it may be unstable if set incorrectly.