EQUATOR GNSS / BY TECHNOGISGermany · Indonesia
Data & quality

Designing a backup and recovery strategy for GNSS projects

A GNSS backup plan must preserve observations, metadata and accepted processing records, then prove they can be restored into a usable project.

Designing a backup and recovery strategy for GNSS projects

Define what a usable recovery requires

A backup is valuable when it can restore a usable project, not merely when files appear in a second location. GNSS work depends on observations, setup metadata, reference definitions, processing inputs, review decisions and issued versions. Begin by identifying the records needed to reproduce the accepted coordinate chain. Raw receiver files alone may be insufficient if antenna heights, local transformations or the final acceptance report are missing.

Set recovery priorities according to project value and operational consequences. A current field campaign may need rapid restoration to continue work, while an archived control project may prioritize long term interpretability. Define acceptable data loss and restoration time through the organization's normal planning process. These requirements guide the backup frequency and storage approach without relying on a generic rule that every project needs the same arrangement.

Continue learning AR stakeout: using a live view without losing coordinate discipline

Protect data while the crew is still on site

Confirm that observations are actually recorded and readable before considering them backed up. At suitable intervals, copy field data to a separate approved location and verify the transfer. Keep session identifiers and setup records with the files. An empty raw file copied perfectly remains empty, so the field check should include representative content inspection rather than only a successful copy notification.

Avoid deleting receiver originals immediately after one transfer. Follow a documented retention procedure that accounts for verified additional copies and project needs. Removable media and laptops can share physical risks if stored together, so consider separation appropriate to the campaign. Protect the equipment and data through normal site procedures without making the transfer process so cumbersome that crews stop performing it consistently.

Continue learning Creating an audit trail for GNSS survey data

Include metadata and configuration

Back up antenna information, field notes, photographs, coordinate definitions and approved project templates with the observations. These records can be small but essential. A restored file without its mark identity or height measurement method can require expensive recollection or leave an unresolved interpretation. Treat metadata as part of the measurement evidence, rather than an optional office document copied only when someone remembers it.

Preserve significant processing configurations and supporting input manifests. If software automatically downloads reference products, record what was used and retain permitted inputs where needed for reproducibility. Keep accepted transformation and geoid identifiers clearly associated with coordinate versions. A backup should allow another analyst to reconstruct the approved workflow, not merely reopen a software project that now retrieves different defaults or cannot find a missing local file.

Continue learning Organizing GNSS project folders for reliable processing and handover

Separate backup from synchronization

Synchronization can keep working copies aligned, but it can also propagate deletion, corruption or an unwanted edit. A backup strategy should consider version history and recovery from those events. Understand the actual behavior of the chosen storage system, including retention and restoration limits. Do not assume that a cloud icon means every historical version is protected or that an offline drive is current simply because it was connected recently.

Use appropriate access controls and organizational ownership. A project stored only under one employee's personal account can become difficult to recover after staff changes. Keep credentials and recovery information in suitable private systems, and assign backup responsibilities explicitly. The plan should remain operable by authorized staff without depending on one person's memory of where copies were placed or how a device was configured.

Continue learning Archiving GNSS raw observations for useful future processing

GNSS receiver mounted on a survey tripod.
GNSS receiver mounted on a survey tripod. · Rowan Johnson / USGS / Public Domain

Verify integrity at meaningful points

Use file counts, sizes, checksums or supported integrity tools where they help establish that copies match. These checks assess file identity and transfer integrity, not survey quality. Pair them with content checks such as opening representative observation files and confirming session coverage. A corrupted or incomplete source can be copied faithfully, so verification should address both the transfer and the usability of the underlying dataset.

Keep a backup manifest identifying project versions and significant records. For large campaigns, automated checks can reduce manual effort, but inspect exceptions and retain results. A dashboard reporting success should lead to a recoverable set with clear scope. If some files were skipped or inaccessible, make that visible and resolve the gap rather than allowing a general success label to conceal missing measurement evidence.

Continue learning AR stakeout: using a live view without losing coordinate discipline

Preserve issued and superseded versions

The backup should retain the authoritative issued package and the history needed to understand replacements. Keep working outputs distinguishable from accepted deliverables. If a coordinate correction is issued, preserve the earlier package with a clear superseded status and link the replacement. This supports later investigations into which data a downstream team used and why two reports contain different values for the same point.

Avoid relying on file modification dates alone to identify the accepted issue. Copying and restoring can alter surrounding metadata or reorder files. Use stable version identifiers and manifests that travel with the package. The recovery process should restore those relationships so a future analyst does not have to infer approval status from ambiguous names such as final, final-new and final-corrected.

Continue learning Creating an audit trail for GNSS survey data

Test restoration with a representative project

Perform a controlled restore to a separate location and verify that the project can be interpreted. Open raw observations, locate setup metadata, identify the accepted processing run and inspect issued outputs. Where practical, reproduce a representative calculation using the retained inputs. A restore test reveals missing dependencies that a successful backup job may never detect, such as a transformation stored outside the project folder.

Record the test scope, date, result and corrective actions. Do not claim full recoverability from a test that restored only a small subset. Choose representative records and periodically include difficult cases, such as a project with local grids or several processing versions. Update the strategy when storage systems, software or project practices change, because a once successful test does not establish permanent recovery capability.

Continue learning Organizing GNSS project folders for reliable processing and handover

Plan long term readability

Keep original formats, but consider supported exchange formats and readable metadata where appropriate. A proprietary project may require software that is unavailable years later. RINEX and other documented formats can support future access when created and verified correctly, but conversion must preserve the observations and metadata needed for the intended use. Retain the original and record the conversion method rather than treating an exchange file as an unexplained replacement.

Review retention requirements and storage health through the organization's normal policy. Long term archives need ownership and periodic attention. A drive placed in a cupboard is not a complete preservation strategy if no one knows its contents or whether it can still be read. Keep the archive index usable and avoid storing unnecessary secrets in client or broadly accessible packages.

Continue learning Archiving GNSS raw observations for useful future processing

Make recovery an operational capability

Assign responsibilities for field copying, office backup, exception review and restoration approval. Provide a concise procedure that staff can actually follow. After an incident, preserve the event record and assess whether the recovered dataset is complete enough for its intended use before resuming production. A technically successful restore may still leave a period requiring recollection or a limitation in the final deliverable.

A strong backup strategy protects the full GNSS evidence chain and demonstrates that it can be recovered. It combines reliable copies, integrity checks, readable metadata and tested restoration. That turns backup from a reassuring storage habit into a practical capability to continue work and defend the accepted coordinates after equipment loss, accidental changes or staff turnover.

Continue learning AR stakeout: using a live view without losing coordinate discipline

Practical checklist

Practical checklist

  1. Define what a usable recovery requires.
  2. Plan long term readability.
  3. Make recovery an operational capability.
EQUATOR GNSS

Plan your GNSS setup

Compare the EQ10 and EQ20 receiver specifications, then discuss the configuration and support your project needs.

Compare GNSS receivers

References

  1. IGS/RTCM — RINEX 4.02 specification
  2. NOAA NGS — User Guidelines for Single Base Real Time GNSS Positioning
  3. IGS CORS Guidelines — Metadata