Skip to main content

Restoring an Accelerator Backup

Introduction

The Accelerator backup will come in the form of a Gzipped Tar archive which contains the contents of the budgeting and activity data stored on the database's Hubble schema. It also contains a backup of the Qlik replication tasks.

The process of restoring a backup consists of copying the archive onto the Accelerator then restoring each portion in turn. The order in which these tasks are run is important as attempting to restore the Hubble schema before allowing Qlik to re-replicate is likely to fail.

It assumes an empty Accelerator as the destination and that you have access to the 'root' account of it.

Preliminary Steps

To restore these backups onto a fresh server it is necessary to connect to a terminal (SSH) session on the Accelerator as root, and to copy the backup archive onto it.

We will assume that a Windows machine with Putty installed is being used. A Linux desktop could also be used with minimal modification to the steps.

Copying the Backup

  1. From the host machine this can be achieved with Putty PSCP command. Replace the location of backup file and the Accelerator IP address or host name.

    pscp -scp path\to\hubble schema_backup.tar.gz root@accelerator ip:/ tmp/

  2. Once there the archive should be expanded using the following commands from within the root SSH session.

    cd /tmp

    gunzip hubble schema backup 2017 07 15 21 56 10.tar.gz

    tar xvf hubble schema_backup 2017 07 15 21 56 10.tar

  3. This will create two folders, QlikBackup and DatabaseBackup.

    The first of these contains the definition of the ERP database replication tasks, whilst the second contains the data from the 'Hubble' schema of the database. We need to give the relevant accounts full access to 'their' data,

    chown -R qlik:qlik /tmp/QlikBackup

    chown -R actian:actian /tmp/DatabaseBackup

Qlik Backup

Importing the Replication Definition

The 'QlikBackup' directory should contain a single file called Replication_Definition.json which contains the configuration of the Qlik components.

The major parts of this file are the definitions of the tasks, and the database connections that feed them. This can be imported into the Accelerator's Qlik database with the following commands in the SSH session.

su qlik
repctl importrepository json file=/tmp/QlikBackup/ Replication Definition.json

Create Schemas on the Accelerator

Before we can execute the replication tasks it is necessary to create the schema(s) into which this data will be placed. This is performed from within a SSH session and must be performed for each destination schema required by an Qlik Replicate task.

  1. From the SSH session execute the command below as a root user:

    sql iidbdb

  2. From within the SQL terminal create a new user for the target schema and then quit the application:

    create user schemaName with password='password' \g grant all on database db to schemaName \g

    commit \g

    \q

  3. Now we need to create and drop a table for the above user, to initialize the new schema. From the SSH session execute the following command:

    sql db -uschemaName

    From within the SQL terminal:

    create table tl (cl char(l)); \g
    commit \g
    drop table tl; \g commit \g
    \q

Run Qlik Replicate Tasks

  1. Configure the Qlik Replicate console to connect to the new Accelerator. This is described elsewhere.

  2. Run Qlik Replicate Console and note that the tasks will be present.

  3. Click Manage Databases.

  4. Click Open on the source/target databases and re-enter the passwords and test the connections.

  5. Open the task you are interested in and check that there are tables populated in the Explicitly Selected Tables list.

    If there are none, then it is likely that permissions on Linux were not given to the Qlik user earlier on (before repctl importrepository was run).

  6. Run the task.

  7. Log in as the schema that we need to give access from.

Database Hubble Schema

File Contents

The DatabaseBackup folder contains a file for each of the tables in the Hubble database schema. This includes:

  • Budgeting data. Budgeting tables will be backed up including the custom strategic planning tables.

    Much of these tables are named with a two-letter prefix then 'budget'. Also included in this group are 'is_generic' and 'isbpayroll' ('is' is the insightsoftware prefix)

  • Activity tables. These tables' names all begin with 'activity' and contain user activity logged by the application.

  • Dual (for EBS only). This is a dummy table which may be present, but contains no data.

In addition to these tables there will be two other files, called 'copy.in' and 'copy.out'. These are scripts to automate the insertion and extraction of data.

Copy.in Script

The copy.in script is used to restore the exported data. As well as containing the definition of the tables exported it also contains links to the files containing the tables' contents.

There are known scenarios where the backed up data contains synonyms that point to tables that are not included in the replication tasks. If this is the case then it is preferable to allow the restoration process to run through without stopping on error. The list of errors can then be examined after the import to verify the missing synonyms, or other errors that occurred.

By default the import process will stop when it encounters an error. To allow this to continue it is necessary to edit the 'copy.in' file using a text editor such as nano. Near the top of the file will be the line

\nocontinue

To allow the import to continue on error this should be changed thus, and the file saved.

\continue

Performing Import

It is required that the Hubble schema on a fresh Accelerator is empty. A freshly deployed Accelerator will have the five Activity tables created automatically, which must be deleted before restoring the backup. If the Activity tables are not deleted the restore script will fail when it attempts to recreate them.

Start the restore process from the backup directory with:

cd /tmp/DatabaseBackup
sql db -uhubble <copy.in> output.txt

This line assumes that the database is called 'db' and the user/schema is 'hubble'.

Changes to the user used will require manual changes to the copy.in script as the original schema name is mentioned there.

Checking for Errors

The output of the restore process has been logged to 'output.txt'. It is therefore necessary to identify if there have been any errors logged to this file, using the following command:

grep AE    output.txt

If the import encountered tables are no longer replicated or had been created manually, but which had synonyms, then errors like this will be listed:

E 0S0845 Table 'ar receipt classes' does not exist or is not owned by you.

The surrounding text for this error will detail the operation that was being attempted when the error occurred. This can be found by examining the log file in a text editor or viewer.

Was this article helpful?

We're sorry to hear that.