Backing up Your Altium NEXUS Server with an Oracle Backend

This document is no longer available beyond version 2.0. Information can now be found here: Backing up Altium NEXUS Server with an Oracle Backend for version 5.0

This documentation page references NEXUS Server (part of the deployed NEXUS solution), which has been discontinued. All your PCB design, data management and collaboration needs can now be delivered by Altium Designer and a connected Altium 365 Workspace. Check out the FAQs page for more information.


Parent page: Backing up and Restoring Your Altium NEXUS Server

A critical requirement for systems that maintain and store valuable design data, such as the Altium NEXUS Server, is backing up the data and files hosted by the system. The Altium NEXUS Server installation includes a command line tool for this purpose, which offers the capability to both backup and restore the entire NEXUS Server content and user data, including the database when the Firebird option has been installed.

For users that have selected an Oracle® database type for use with the NEXUS Server however, the backup process is somewhat different and also time-critical.

The different approach required is because the Oracle database is a separate entity from the NEXUS Server system, unlike the integrated Firebird database alternative, and therefore must be backed up by its own system and process. That system is most likely in another network location, and more significantly, under control of the Oracle infrastructure, its inherent policies, and the database Administrator (DBA).

Backing up an Altium NEXUS Server that uses an Oracle database therefore involves two independent stages:

  1. Arranging for the Oracle database and metadata to be backed up.
  2. Using the supplied Altium NEXUS Server Backup tool to backup all other NEXUS Server content and settings.

The backup stages must be completed in the above order, and concluded within the shortest possible timeframe, to ensure data consistency.

  • The reverse of the recommended order (NEXUS Server content first) carries the risk that the database metadata will refer to non existent files if these have been added between the two backup events.
  • When the backup is completed In the listed order (Oracle DB first), any files that have been added between the events will not be included in the database metadata - the added files are simply ignored.

Important Recommendations

  • Complete backups should be performed on a regular basis, and must be mandatory before any significant changes are made to the system or its configuration. This includes software updates, setup changes, hardware replacement, and so on.
  • Test NEXUS Server installation systems should be created that are independent of the main Production system. A Test system can be used for regular test restores to ensure that the systems work as intended, and everyone involved is aware of the exact steps they need to take in the event of a worst case scenario.
  • As mentioned above, unless both the NEXUS Server and Oracle systems are suspended (unlikely for the Oracle system), both the backup (or restore) stages should be completed within the shortest possible time. The simple fact here is that if any changes are made to the NEXUS Server, or its database from other sources, within the period between the two backup stages, the two sources will not align in content when they are restored.

    The best approach is to stop the NEXUS Server (using Windows' IIS Manager), or prevent access to it, during the period between the two backup processes. The timing and order of the two backups is then not critical, since no changes can be made in the interim.

  • Since there are two independent backups performed to create a complete backup of the NEXUS Server content, the two data snapshots should be date/time stamped and associated with each other by some overarching system. Such a system would link the two sources that make up a complete NEXUS Server backup, and provide the ability to retrieve the 'composite' backup on demand.

Creating a Backup

Contact your Oracle DBA to instigate a suitable backup arrangement for the NEXUS Server database. The Oracle database backup should occur in close association with the backup completed by the Altium NEXUS Server Backup tool, and be involved with a backup management system that links the two stored backups.

It’s crucial that the two stored backups (NEXUS Server and Database) that correspond to a single backup of all NEXUS Server data be associated or linked, as detailed in the 'Important Recommendations' section above.

Perform a backup of the NEXUS Server using the supplied Server Backup tool. For more information on the process see the Backing up and Restoring Your Altium NEXUS Server page.

In short however, the backup command line tool (avbackup.exe) is located in the NEXUS Server installation’s \Program Files (x86)\Altium\Altium NEXUS Server\Tools\BackupTool\ directory, and its minimal command string is avbackup backup –z <output location\file>. Note that quotes must be used when the path-file includes spaces.

For example, creating a backup of an (Oracle database type) Altium NEXUS Server installation might be avbackup backup -z "C:\Backups\Altium NEXUS Server\". The completed backup process would appear as below.

When the tool detects that the NEXUS Server uses an Oracle database, the database backup part of the process is skipped and a warning is displayed. All other data, content, and settings are backed up as usual.

The content of an Oracle database NEXUS Server backup zip file is the same as that for a Firebird-based NEXUS Server backup, but does not include a database backup file - in a Firebird backup, this file is DXPServer.fbk.

If you find an issue, select the text/image and pressCtrl + Enterto send us your feedback.