Tutorial: How to Recover a Server with SQLite3 Dump Backup Files

Abstract

How to recover Access Server using 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.

Prerequisites

Backup configuration files.
An installed Access Server where you'll restore the backup configuration.
Caution
If you follow these steps, the current configuration of Access Server is wiped out entirely and replaced with the contents of the backup files. You can't combine a backup set of information from one server with another production server.
Console access with root privileges.

Step 1: Restore the backup files

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.

Tip

For these commands, we assume that the backup files are located in the /usr/local/openvpn_as/ directory. Adjust the commands as necessary for your files' location.

Run these commands to stop the Access Server service and restore the backup:

service openvpnas stop
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 ../../clusterdb.db.bak ]&&(rm -f clusterdb.db;sqlite3 <../../clusterdb.db.bak clusterdb.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
service openvpnas start

These commands restore the configuration backup.

Troubleshooting tips

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 the interface and port for the web services to listen on to default settings. Once you have access to the Admin Web UI again, you can reconfigure your settings. Alternatively, you can use the command-line tools to configure the web server settings manually.

The configuration database also contains settings on how many TCP daemons and UDP daemons to launch. If this is set higher than the amount of available CPU cores, Access Server may become unstable. So if you have restored this configuration on a different server, and the amount of CPU cores is different from the server the configuration backup came from, adjust this on the Network Settings page in the Admin Web UI, or use our reset commands for the OpenVPN daemons here. It may run if the amount is set too high, but it may be unstable if set incorrectly.

In this section: