Skip to main content

Backups are data too

Deleting a feature from the production database does not mean every copy has disappeared. GIS naturally creates exports, offline areas, backups, test databases, caches and archives. Meaningful control requires knowing which important copies exist and what happens to them.

The real lifecycle

Conceptual flow

Every arrow is a governance decision.

Copies are not automatically bad

Copies provide real benefits:

  • disaster recovery
  • preservation
  • field operation without internet
  • safe testing
  • authorised research
  • migration
  • independent exit from a vendor

The problem is uncontrolled or forgotten copies.

Maintain a copy register for sensitive data

For significant restricted layers, record at least:

FieldExample
Datasetcultural sites authoritative layer
Authoritative locationproduction database
Sensitivityhighly restricted
Backup locationsencrypted cloud vault + offline copy
Mobile copiesnamed field project / expiry date
Consultant copiesprovider, purpose, return date
Test copiesmasked or synthetic where possible
Archiveopen-format preservation copy
Publication derivativepublic generalised layer
Ownerorganisational role
Review datequarterly or project close
Deletion statuslive, expired, verified deleted

This is a practical control, not a statutory requirement.

Backups need their own rules

Ask providers and administrators:

  • how often backups are taken
  • where they are stored
  • whether they are encrypted
  • who can restore them
  • how long they are retained
  • whether deleted data remains until backup expiry
  • whether backups are replicated into another jurisdiction
  • whether the organisation can obtain an independent recovery copy
  • whether restores are actually tested

A backup that has never been restored is an assumption, not demonstrated recovery capability.

Mobile GIS is a copy system

Field applications can place substantial datasets on phones and tablets. Review:

  • device encryption
  • screen lock
  • remote wipe where appropriate
  • offline-area extent
  • expiry after fieldwork
  • lost-device procedure
  • whether attachments download with the layer
  • whether shared devices use named accounts

Test systems should not automatically contain production cultural data

Where possible use:

  • synthetic records
  • generalised geometry
  • masked attributes
  • a minimum representative subset

If exact production data are genuinely required for testing, apply equivalent access and lifecycle controls.

Consultant copies need an end date

Contracts and project close-out should specify:

  • what the consultant may copy
  • where it may be stored
  • whether subcontractors receive it
  • when working copies must be returned or deleted
  • how deletion is evidenced
  • what may remain in backups and for how long
  • which copy becomes the client's archival record

See Working with consultants.

Government copies may have different retention obligations

Once information enters a public agency's recordkeeping environment, legal retention and public-record obligations may apply. That is one reason a data-sharing agreement should consider records and retention before transfer rather than relying on a later request to delete everything.

Exit copies are important

A carefully governed independent export can increase sovereignty by reducing vendor dependence.

For important systems, periodically export:

  • spatial data in usable formats
  • attachments
  • metadata
  • code lists and schemas
  • configuration documentation
  • account/role documentation

Store the export independently and test that it can be opened.

Sources

Last verified: 16 August 2026

Where this matters for Māori GIS

For iwi, hapū and marae GIS, backup design can involve whenua research, taiao observations, marae assets, historical sources and working interpretations that are difficult to recreate. GIS succession covers continuity between kaimahi, while local and hybrid GIS compares where the working and recovery copies can sit.