A backup is valuable when it can restore the information and working context an organization needs. Copying a familiar project file may be part of that process, but it does not automatically preserve every dependency required to open the project, interpret its records and reproduce an important output. Recovery needs to be planned and tested.
This guide provides a GaeaSynergy backup planning checklist and a controlled recovery-test framework. It is not a version-independent sequence of restore commands. Confirm the supported backup and recovery method for your installed version and deployment with the applicable documentation and GAEA support before restoring data or changing a production environment.
Understand where the working information resides
The GaeaSynergy introduction describes information stored in project and GIS databases and a datastore. The practical backup scope must account for the resources used by your installation. Identify their configured locations and dependencies rather than assuming that every record is contained in one visible project folder.
Ask the application owner and IT administrator to build the inventory together. The technical user knows which logs, maps and outputs are essential, while the administrator knows how storage and access are configured. A backup plan created by either group alone can miss requirements that become obvious only when the other group attempts recovery.
Define what successful recovery means
Describe the minimum useful recovered state. For example, an authorized user might need to open a representative project, inspect its boreholes, view related attachments and reproduce an agreed log or table. Those tasks provide an acceptance test. “The files were copied successfully” is a narrower statement and should not be treated as proof of operational recovery.
Define acceptable data loss and restoration time in terms appropriate to the organization. These requirements influence backup frequency, retention and recovery resources. Do not select an ambitious recovery target without checking whether staff, storage and procedures can meet it. A documented realistic target is more useful than an untested promise.
Inventory databases and supporting resources
Record the databases, datastore locations and other resources needed by the selected deployment. Include relevant templates, symbols, libraries, linked documents and project-specific supporting files where applicable. Determine whether these are stored centrally, locally or in several places. Keep the inventory current when configuration or storage locations change.
Also identify issued deliverables and the source information needed to explain them. A database backup and an archive of final reports serve related but different purposes. The organization may need both to recover active work and to establish what was issued previously. State where each belongs and who is responsible for its retention.
Distinguish backup, archive and export
An archive can organize inactive projects, while an export can support exchange or a defined preservation purpose. Neither should automatically be treated as a complete recovery strategy. GAEA’s project archiving guidance describes archived projects being stored in the datastore. Protecting that datastore remains a separate operational consideration.
Similarly, confirm exactly what a selected export includes before relying on it. A format may preserve some record types while omitting application configuration or other dependencies. Test the intended use and document limitations. A convenient exchange file can be useful alongside a backup without replacing the recovery method required for the complete environment.
Use a supported method for a consistent copy
Database information can change while users are working. Confirm how the chosen backup method obtains a consistent state and whether services or user sessions require particular handling. Do not assume that an ordinary folder copy taken at any moment will produce a usable database set. Follow guidance appropriate to the actual deployment.
Document the procedure clearly enough that another authorized administrator can follow it. Include prerequisites, expected outputs and how completion is checked. Keep credentials and sensitive access details in the organization’s approved secure system rather than embedding them in a widely shared checklist. The procedure should explain the process without exposing unnecessary secrets.
Protect copies against common failures
Consider what happens if the primary workstation, server or storage location becomes unavailable. A copy stored only beside the working data may be affected by the same incident. Select separate storage and retention arrangements appropriate to the organization’s requirements. Account for accidental deletion and corruption as well as equipment failure.
Access to backups should be controlled because they may contain the same confidential information as the live environment. Confirm who can create, retrieve and remove copies, and how those activities are managed. Avoid assuming that a backup is protected merely because it is not routinely opened. Include it in the organization’s normal data-handling arrangements.
Retain enough history to recover from delayed discovery
Some problems are discovered after several backup cycles. If every copy immediately replaces the previous one, the available history may contain only the damaged or incomplete state. Define retention based on operational needs and applicable organizational requirements. Record which copies are short-term recovery points and which support longer-term retention.
Make backup dates and scope easy to identify. A reviewer should be able to distinguish a complete scheduled copy from a partial manual export. Keep a record of failures and corrective action. A backup schedule that ran is not the same as a backup that completed successfully with the intended contents.
Plan a recovery test outside production
Choose a controlled test environment and identify the resources it needs. Confirm the recovery method before starting and protect the live data from accidental replacement. Some restore operations can overwrite existing information, so the destination and scope must be explicit. Have the appropriate administrator supervise the exercise according to the organization’s process.
Select a representative recovery point and record why it was chosen. Include the software version and configuration needed to interpret it. If compatibility across versions is uncertain, resolve that question with support rather than experimenting on the only copy. Preserve the original backup while testing a working copy or approved recovery process.
Test the records and the workflow
After recovery, check more than whether the application starts. Open representative projects and compare expected record counts or identifiers where practical. Inspect important values, associated files and spatial context. Include a project with supporting resources so the test can reveal missing dependencies that a minimal example would not expose.
Generate an agreed output and compare its essential content with the expected result. Check templates, symbols, units and relevant references. A recovered database that opens but cannot reproduce a required deliverable may still need additional resources or configuration. Record the difference and establish whether it affects the organization’s recovery objective.
Measure the recovery process honestly
Record the time needed to locate the backup, prepare the environment, restore information and complete acceptance checks. Separate active work from waiting for equipment, access or support. This gives a more realistic view than timing only the restore operation. The organization needs to know when users can resume meaningful work.
Ask someone other than the procedure’s author to follow the documentation where feasible. Note unclear steps, missing permissions and assumptions about file locations. A recovery plan that depends on one person remembering an undocumented detail is difficult to rely on when that person is unavailable. Use the test to improve the process before an actual disruption.
Keep software and deployment information available
Document the application versions, licensed modules and relevant deployment configuration associated with the backup. Record the supported route for obtaining installation media or assistance. License recovery and transfer requirements should be confirmed with GAEA; copying data does not by itself establish that a replacement environment can be activated or used as intended.
Keep configuration information alongside the recovery plan, with access appropriate to its sensitivity. Include contact roles and escalation arrangements. The goal is not to store every secret in one document, but to ensure an authorized administrator knows where to find the approved information needed to rebuild the working environment.
Repeat tests after meaningful changes
Reassess the plan when storage locations, application versions, modules or deployment arrangements change. New attachments or templates may introduce dependencies that were absent from the previous test. A successful recovery exercise from an older configuration does not establish that the current environment is covered in the same way.
Schedule periodic tests according to the organization’s needs and record their outcomes. Close identified gaps with named owners and repeat the affected checks. Treat recovery planning as an operational responsibility rather than a one-time installation task. The procedure becomes more useful when it reflects what the team actually uses and has demonstrated it can recover.
Include a communication step in the plan. Staff should know who declares an incident, who decides which recovery point to use and how users are told when the restored environment is ready. This avoids competing attempts to recover different copies of the same project. Technical restoration and organizational coordination need to reach the same decision about the authoritative working record.
Build a concise recovery record
Retain the backup identifier, recovery destination, software version, steps performed, test results and remaining limitations. State who reviewed the outcome and whether the defined recovery objective was met. This evidence helps management distinguish a tested capability from an assumption and gives the next administrator a practical starting point.
Confirm the right method for your installation. Use the current GAEA manuals and contact GAEA support with your version and deployment details. A complete backup plan preserves the necessary information; a controlled recovery test demonstrates that the organization can use it again.