Collapse AllExpand All

4. Restoring from Backup File

As the next screenshot shows, we can reach the Restore... option by right-clicking on the new database we just created. The Restore... option is the one we need to load the xTuple backup file.

Restore backup file

The Restore screen looks just like the next screenshot. All you have to do here is

  1. Browse your computer for the xTuple backup file you downloaded

  2. Select it the backup file so the path to it appears in the Filename field

  3. Select "admin" as the Role name

You should leave the other options not-selected. Then click RESTORE.

Begin restore

Don't worry if the restore takes several minutes to complete. This is normal. At the end of the process you will see log messages which look like those shown in the following screenshot. Depending on the circumstances of your PostgreSQL installation (e.g., whether previous databases have been installed there, etc.), the messages pgAdmin reports may vary. The ideal scenario on a fresh PostgreSQL install is for 0 errors to be reported and an exit code = 0. However, as the next screenshot shows, pgAdmin may report a number of errors and a non-zero exit code. If this is the result you get, don't be alarmed. Simply review the list of errors by using the scroll bar in the "Restore Database" screen. Scroll to the top and review the list of errors which were reported. Most if not all of the errors you get can safely be ignored.

Here are some examples of error messages which can safely be ignored. The first error reports that the PostgreSQL procedural language plpgsql is already installed—and so it does not need to be restored:

pg_restore: creating PROCEDURAL LANGUAGE plpgsql 

pg_restore: [archiver (db)] Error while PROCESSING TOC: 

pg_restore: [archiver (db)] Error from TOC entry 2121; 2612 48797691 

PROCEDURAL LANGUAGE plpgsql 

pg_restore: [archiver (db)] could not execute query: ERROR: language "plpgsql" already exists 

Command was: CREATE PROCEDURAL LANGUAGE plpgsql;

Likewise, you may see other messages such as the following two, which both indicate functionality already exists and does not need to be restored from the backup file:

Example 1:

pg_restore: [archiver (db)] Error from TOC entry 18; 1255 7469922 FUNCTION armor(bytea) admin 

pg_restore: [archiver (db)] could not execute query: ERROR: function "armor" already exists with same argument types 

Command was: CREATE FUNCTION armor(bytea) RETURNS text 
AS '$libdir/pgcrypto', 'pg_armor'
LANGUAGE c IMMUTABLE STRICT;

Example 2:

pg_restore: [archiver (db)] Error from TOC entry 20; 1255 7470043 FUNCTION crypt(text, text) admin 

pg_restore: [archiver (db)] could not execute query: ERROR: function "crypt" already exists with same argument types 

Command was: CREATE FUNCTION crypt(text, text) RETURNS text 
AS '$libdir/pgcrypto', 'pg_crypt' 
LANGUAGE c IMMUTABLE STRICT

In short, you should review any error messages you get when restoring an xTuple database backup file. However, in many cases the errors that are being reported can safely be ignored. Use your common sense when reviewing error messages. If you come across an error message which concerns you, search the xTuple forums to see if others have been concerned about the same thing. Quite often others in the community will have seen the same errors you are concerned about.

To see that the restore operation loaded the xTuple database successfully, simply refresh your pgAdmin view. Then expand the new database element to see the xTuple schema (i.e., tables, functions, etc.) listed under the Schema element. The following screenshot shows the "api" and "public" schema found in every xTuple database.

Database schema loaded successfully

Your database should be successfully restored. Now go to your xTuple client application and open it up. Then use the following login options:

  • Server: localhost or 127.0.0.1

  • Database: dbTest (or whatever you named yours)

  • Port: 5432

  • User name: admin

  • Password: admin

You can use the same steps described above to add more databases to your PostgreSQL server. However, if you are running a production database, we recommend that you run only the production database on the server—and don't load other databases onto the same PostgreSQL instance.