UNS OpenHubDocumentation

Getting started

Protect Runtime data and recovery keys

Use the Controller's Backups & recovery workspace to check capture readiness, create and inspect protected recovery points, and review activity. Protect business databases and recovery keys separately, keep a verified copy outside the Runtime hosts, and rehearse restoration with the version-matched Runtime tools.

Applies to
UNS OpenHub Runtime
Guide version
1.1

Worked example

One recovery point, several protection layers

A controller backup does not automatically include every database, key or external service. Record each layer and its recovery owner.

Control plane Controller database + reviewed configuration

Capture these through the Runtime recovery workflow so the resulting component has explicit membership, checksums and version evidence.

Service deployment Installed services + instance configuration

Preserve a complete deployment component or enough immutable release evidence and configuration to reproduce it.

Business data History and service-owned databases

Protect each datastore with its supported database or storage backup method and a business-approved recovery point objective.

Recovery trust Decryption identity + trusted signer

Keep these outside the Runtime and separate from the ordinary backup payload. Without them, an encrypted artifact may be intact but unusable.

Procedure

Follow the task in order

  1. 1
    Set recovery objectivesFor every business service, record the acceptable data-loss window (RPO), acceptable recovery time (RTO), owner and retention requirement. Use these values to choose the schedule instead of treating one daily backup as a universal policy.
  2. 2
    Inventory every required data classList the controller control plane, shared configuration, each controller member, installed service deployments, business databases, service identities, secret-provider bootstrap and recovery identities. Mark reproducible caches and container images separately so they are not mistaken for irreplaceable data.
  3. 3
    Check the Recovery workspaceAs an administrator, open Backups & recovery. The Backups view shows capture readiness, the serving controller, the latest verified recovery point, local storage and registered external copies. In a cluster, review the coordinator plan and each controller's readiness before starting capture. The page also shows whether a daily archive is enabled and its configured time zone.
  4. 4
    Create an application-consistent recovery pointSelect Create recovery point only when capture is ready, then follow the Activity view until the job finishes and the signed point appears in Backups with complete member coverage. The point includes PostgreSQL, redacted controller configuration, installed microservice files when present, and the shared configuration profile when required. Use a database-native backup or supported storage snapshot for QuestDB and every service-owned datastore; a live copy of a container volume is not automatically consistent.
  5. 5
    Copy the complete set outside the Runtime hostsTransfer the parent manifest and every bound member component to an approved backup system over an encrypted channel. Verify the destination checksums and record the external backup identifier. A distributed set that exists only on its source hosts is not an independent disaster-recovery copy.
  6. 6
    Keep recovery keys separateKeep at least two independent break-glass copies of the recovery decryption identity and trusted signer. The Runtime may hold the public recipient used to encrypt backups, but it should not hold the only matching decryption identity. Keep older key generations until all backups that depend on them have expired.
  7. 7
    Test restoration from the external copyThe Controller shows a read-only restore plan for a verified source; it does not execute the restore. Use the version-matched external Runtime CLI on an isolated, stopped target with production publishing and side effects disabled. Verify signatures before decryption, check database integrity and service inventory, inspect a bounded business-data sample, and record the achieved RPO and RTO.
  8. 8
    Monitor protection as three separate statesTrack creation of a complete recovery point, successful off-host transfer, and successful restore testing separately. Alert on an old recovery point, missing member, checksum failure, storage exhaustion, missing key custody or an overdue restore rehearsal.

Expected result

What you should have

The deployment has a complete, independently stored and regularly tested recovery path whose scope and limits are understood before an incident.

Boundaries

Important boundaries

  • Never put passwords, tokens, private keys or recovery identities in documentation, tickets, logs or ordinary shared folders.
  • Do not copy live database or container-storage directories unless the selected snapshot method provides a documented consistency boundary.
  • Do not delete an old recovery-key generation while any retained artifact still depends on it.
  • Use the README included with the installed Runtime for version-specific capture, verification and restore commands.

FAQ

Common questions

Does copying the Runtime directory protect all data?

No. The Runtime directory contains software and local configuration, while databases, installed service state, cryptographic identities and external systems have separate consistency and custody requirements.

Is a successful backup job enough?

No. A successful job proves only that its configured input was copied. Verify completeness, signatures and checksums, then perform a representative restore from the external copy.

Can I back up a running database volume as files?

Only when the database and storage documentation explicitly support that snapshot method. Normally create a native logical or physical backup, or a coordinated storage snapshot, and let file-oriented backup software collect the completed artifact.

Why must the recovery identity be separate?

If a compromised or lost host contains both an encrypted backup and its only decryption identity, the backup does not provide an independent recovery boundary. Keep a separate break-glass copy outside the Runtime and normal secret-provider failure domain.

How often should restoration be tested?

Use the interval required by your RTO and compliance obligations. As a general minimum, run a representative rehearsal at least twice per year and after a material change to the backup format, key custody, storage provider or recovery workflow.

Does a controller recovery point include QuestDB history?

Do not assume so. Treat QuestDB and every service-owned datastore as their own protection class and verify the declared contents of the current Runtime recovery format.

Does Integrity verified mean restoration succeeded?

No. It means the stored signatures and files match. The Controller's restore plan is read-only and does not assess every target precondition. Test a real restore from an independent copy on an isolated target before counting it as a rehearsed recovery path.

This versioned public guide is maintained with the UNS OpenHub website and linked directly from the controller where the task applies.