• No results found

What Must be Backed Up

Configuration files for Identikey Server, Virtual Digipass Message Delivery Component and Digipass TCL Command Line Administration.

SSL certificate(s) Audit Log data Data store

DPX files (except for demo Digipass)

Any scripts that have been written for Digipass TCL Command Line Administration, if they may be needed in the future.

Important Note

The Identikey Server installation includes a DPX directory containing sample DPX files for demo Digipass. These do not need to be backed up. However, if Identikey Server uses an ODBC database and you have copied the DPX files for your real Digipass into that directory, ensure you still have the original files. If you no longer have the DPX file(s) stored elsewhere, it is very important that you take a backup.

6.1.1 Configuration Files

The configuration files for the Identikey Server, Virtual Digipass Message Delivery Component and Digipass TCL Command Line Administration can be copied from:

the Bin directory in Windows (by default in Windows C:\Program Files\VASCO\Identikey Server\Bin) to a secure location.

<installation directory>/etc/vasco/ in Linux The files to be copied are:

identikeyconfig.xml for all Identikey Servers

mdcconfig.xml – a backup of one working file is sufficient.

dpadmincmd.xml

Tip

Save the files above with an extension that describes the server from which the file(s) were backed up. This makes it easier and quicker to locate the correct file during recovery.

6.1.2 SSL Certificates

Any SSL certificates used with the Identikey Server should be backed up. If you are using a certificate generated by Identikey Server's Configuration Wizard, this will be named either ikeycerts.pem or ikeypvk.pem.

6.1.3 Audit Log Data

If your organization requires that the Audit Log data be archived, the method required will depend on the audit settings. You may need to archive periodically, to avoid too much disk space being used or to keep the database from growing too large and slow.

6.1.3.1 Write to Text File

Ensure you make copies of all files contained in the directory into which the audit log files are written. By default this will be <install dir>\Log (Windows) or <install dir>/var/vasco (Linux), however it may have been configured to another location. Check the audit configuration settings if you are unsure.

6.1.3.2 Write to ODBC Database

Back up the database using the database's backup utility. If you are using the audit tables in the embedded database, they will be included in the backup of the data store and will not require a separate backup.

6.1.3.3 Write to Windows Event Log

By default, Event Log entries are written to the Application log. However, you can configure the entries to be written to another log. Check the audit configuration if you are unsure.

Important Note

The Event Log may be configured with a maximum size. When this size is reached, the oldest entries may be overwritten by new ones. To check this, view the Properties of the log in the Event Viewer. If older entries will be overwritten, you will need to archive them before that occurs.

To archive an Event Log:

1. Select Start -> Programs -> Control Panel.

2. Double-click on Administrative Tools.

3. Double-click on Event Viewer.

4. Right-click on Application (or the correct log, if not Application).

5. Click on Save log file as...

6. Select a path and enter a filename.

7. Select a file format from the Type drop down list.

8. Click on the Save button.

Note

The Audit Log data is not required for system recovery purposes.

6.1.4 Write to Syslog

In Linux, audit data can be written to the Syslog. See 14.4 Linux Syslog for information on configuring Linux and Identikey Server correctly.

6.1.5 DPX files

The DPX files are normally provided on secure media, which can be stored securely as a backup. If you prefer another method of archive, copy the files to your preferred location. It is important to keep the DPX file transport keys secure and preferably in a separate location to the DPX files themselves.

6.1.6 Data Store

6.1.6.1 Data Source Settings

If you have performed some adjustments to the ODBC Data Source (DSN) that are important to keep, make sure that you have a readout of the settings.

6.1.6.2 Backup Strategies

Warm Backup

A 'warm' backup of the disk containing the database used by the Identikey Server via a RAID hardware configuration or server mirroring is a favorable backup method. It is both entirely up to date and incurs no downtime if a single disk failure occurs.

This method requires either software RAID, or for better performance a hardware RAID configuration.

Another technique that achieves the same effect is the 'shadow database'.

However, it is still recommended to take a cold backup at intervals, as there is a possibility that a database corruption could be mirrored/shadowed under some circumstances.

Cold Backup

A 'cold' backup of the database allows administrators to implement a duplicate database as a safeguard on a regular basis. Generally speaking there are two methods that can be used to perform a cold backup:

Backup Utility

The first option is to use the vendor-specific backup utility that allows the contents of the database to backed up to a file or device while the system is running. Such a utility is provided with the embedded database PostgreSQL (see below).

Shut Down and Copy the Database File

The second option involves stopping the database server and any connecting server processes and copying the database files. However, this is only possible where the database vendor recommends this approach. Normally this is only appropriate if the database is contained in a single operating system file.

Replicated Copy

If replication has been configured between databases, a replicated copy can be used as a backup. However, it is still recommended to take a cold backup at intervals.

6.1.6.3 Backup of PostgreSQL Embedded Database

The PostgreSQL database available with the Identikey Server installation may be backed up while operational by completing these steps:

1. Open command prompt in <install directory>\PostgreSQL\Bin (Windows) or <install dir>/usr/local/pgsql/bin (Linux).

2. If using Windows, enter the following command:

pg_dump -f "<path\filename>" -Fc -Z9 -U <DB admin userid> [-v] postgres

If using a Linux distribution, enter the following command:

vds_chroot <install dir> pg_dump -f "<path/filename>" -Fc -Z9 -U <DB admin userid> [-v] postgres

where:

<install dir> is the Identikey Server installation directory – by default, this will be /opt/vasco/identikey

<path\filename> is the absolute path and file name of the file to which data will be backed up.

<DB admin userid> is the database administrator account name. When installed, this is set to digipass.

-v is an optional 'verbose mode' parameter. Use this if you wish to see output as the backup is run.

3. You will normally be prompted for the password of the database administrator account. When installed, this is set to digipassword.

This command may also be run via a batch file in order to automatically take a backup at regular intervals. In order to remove the interactive prompt for the password, you can add a line to a PostgreSQL configuration file to allow local logins for a database administrator account without a password. Edit the file <install directory>\PostgreSQL\data\pg_hba.conf (Windows) or <install dir>/usr/local/pgsql/data/pg_hba.conf (Linux) with a text editor. At the bottom of this file, there is a list of rules for authenticating connections to the database, which by default will be:

# TYPE DATABASE USER CIDR-ADDRESS METHOD

# IPv4 local connections:

host all all 127.0.0.1/32 md5

# IPv6 local connections:

#host all all ::1/128 md5 Add the following line directly below # Ipv4 local connections:

host postgres digipass 127.0.0.1/32 trust Backup Administrator Account

You may prefer to create a second database administrator account that only has permission to back up the database.