Backup & recovery

Backup and recovery on GLBNXT Platform ensures that the data your applications depend on is protected against loss and that your environment can be restored to a known good state in the event of a data corruption event, an accidental deletion, or a platform-level incident. GLBNXT manages the backup infrastructure, executes backup processes automatically, and maintains the recovery capabilities needed to restore your data and your environment with minimal disruption.

This section explains what is backed up, how backup processes work, what recovery capabilities are available, and what your team needs to understand to operate confidently with the knowledge that your data is protected.

What Is Backed Up

GLBNXT Platform applies automated backup coverage across all data services within your environment. The following components are included in the standard backup scope.

Postgres databases containing application data, conversation history, user data, workflow state, and any other structured data stored by your applications are backed up on a defined schedule. Database backups capture a consistent snapshot of the full database state, allowing restoration to a specific point in time.

MinIO object storage containing source documents, processed files, model artefacts, and any other binary or unstructured content stored by your applications and ingestion pipelines is backed up to ensure that document corpora and application assets can be restored without requiring re-ingestion from source systems.

Vector database collections in Weaviate or Qdrant containing the embeddings that power your RAG systems and semantic search capabilities are backed up to protect against index corruption or accidental deletion. Restoring a vector database from backup avoids the need to re-run ingestion pipelines across your full document corpus to rebuild the index.

Environment configuration including platform service configuration, workflow automation definitions, and application settings is captured as part of the environment backup scope. Configuration backup ensures that the way your environment is set up can be restored alongside the data it manages.

Audit logs are retained separately from operational data under a protection policy that prevents them from being modified or deleted. Audit log retention is treated as a compliance obligation rather than a standard backup activity. See the Audit Logs and Query History section for guidance on audit log retention policies.

Backup Schedule and Retention

Backups run automatically on a defined schedule without any action required from your team. The default backup configuration applies the following schedule.

Daily backups capture a full snapshot of all covered data services within your environment. Daily backups are retained for a period defined in your service agreement, providing a rolling window of restore points from which your team can recover data from any point within the retention window.

Transaction log backups for Postgres databases capture incremental changes between daily snapshots, enabling point-in-time recovery to any moment within the retention window rather than only to the time of the most recent daily backup. This granularity is important for environments where even a small amount of data loss following an incident is unacceptable.

Backup retention periods are configured during onboarding based on your recovery requirements and any applicable regulatory obligations. For environments subject to data retention requirements that specify minimum periods for which data must be recoverable, retention periods are aligned to those requirements from day one.

Extended retention periods beyond the default are available and can be configured through your GLBNXT contact. Extended retention increases storage consumption and is reflected in the resource allocation of your environment.

Recovery Capabilities

Recovery from a backup event restores data or environment configuration to a previous state. GLBNXT Platform supports recovery at several levels of granularity depending on the nature and scope of the event requiring recovery.

Point-in-Time Database Recovery

For Postgres databases, point-in-time recovery allows your environment to be restored to any moment within the transaction log retention window. This capability is used when data corruption or an erroneous operation affects database content and a restore to the exact state before the incident is required.

Point-in-time recovery is initiated by raising a recovery request with your GLBNXT contact, specifying the database to be restored and the target point in time. GLBNXT executes the recovery process and confirms completion. The duration of the recovery process depends on the volume of data in the database and the distance in time between the target restore point and the most recent daily backup.

Object Storage Recovery

Recovery of MinIO object storage restores buckets or individual objects to a previous state from the most recent backup that captured them. Object storage recovery is used when documents or files are accidentally deleted, overwritten with incorrect content, or corrupted in a way that cannot be resolved by reprocessing from source.

Individual object recovery, where a specific file or document is restored without affecting the rest of the bucket, is available where the backup record captures sufficient granularity to support it. Full bucket recovery restores all objects in a bucket to their state at the time of the backup.

Vector Database Recovery

Recovery of a vector database collection restores the embeddings index to the state captured in the most recent backup. Vector database recovery is used when an index is corrupted, when a collection is accidentally deleted, or when a problematic ingestion run populates the index with incorrect or inconsistent data that cannot be efficiently corrected in place.

Following vector database recovery, any documents ingested between the backup restore point and the time of the recovery request will not be reflected in the restored index. Depending on the freshness requirements of your RAG system, a targeted re-ingestion of documents added since the restore point may be needed after recovery to bring the index back to a current state.

Environment Configuration Recovery

Recovery of environment configuration restores platform service settings, workflow automation definitions, and application configuration to a previous state. Configuration recovery is used when a configuration change introduces unexpected behaviour and the change cannot be reversed by re-applying the previous settings manually, or when configuration is accidentally deleted or overwritten.

Recovery Time and Recovery Point Objectives

Recovery time objective and recovery point objective are the two key parameters that define the recovery capabilities of a backup and recovery system.

Recovery point objective is the maximum amount of data loss that is acceptable following an incident, measured as the age of the most recent recoverable backup. For Postgres databases with transaction log backup, the recovery point objective on GLBNXT Platform is measured in minutes. For object storage and vector databases relying on daily snapshots, the recovery point objective is up to twenty-four hours depending on when within the backup cycle an incident occurs.

Recovery time objective is the maximum acceptable time to restore service following an incident requiring a recovery operation. Recovery time on GLBNXT Platform depends on the scope of the recovery, the volume of data being restored, and the complexity of the environment configuration. Your GLBNXT contact can provide guidance on expected recovery times for specific recovery scenarios relevant to your environment during onboarding.

For environments where strict recovery time and recovery point requirements apply, such as environments supporting critical operational processes or regulated sector deployments with specific business continuity obligations, discuss your requirements with your GLBNXT contact during onboarding to ensure that your backup configuration and recovery capabilities align with those requirements from day one.

Your Team's Responsibilities

GLBNXT manages the backup infrastructure and executes backup processes automatically. Your team has specific responsibilities that complement the platform backup capability and ensure that recovery is effective when needed.

Understanding your recovery requirements: your team should define the recovery point and recovery time requirements for each application and data set in your environment before they go into production. Requirements that are unclear until an incident occurs are requirements that may not be met by the default configuration.

Avoiding destructive operations without verification: accidental deletion or overwrite of data is one of the most common scenarios requiring a recovery operation. Before performing bulk delete operations, schema migrations, or data replacement processes in production, verify that a recent backup exists and that you understand what recovery would look like if the operation produces an unexpected result.

Testing recovery processes: knowing that backups exist is not the same as knowing that recovery works. Periodically testing that a recovery can be completed successfully from backup for critical data services gives your team confidence in the recovery capability and surfaces any gaps before they matter. Discuss recovery testing options and scheduling with your GLBNXT contact.

Reporting incidents promptly: the sooner a data loss or corruption event is reported to GLBNXT, the sooner a recovery process can begin and the more restore point options are likely to be available. If your team identifies a potential data integrity issue, contact your GLBNXT contact immediately rather than waiting to investigate further before raising the issue.

Application-layer data management: GLBNXT's backup coverage protects platform-managed data services. Data managed by your applications at the application layer, such as data cached in application memory, data written to temporary locations outside platform-managed storage, or data processed by your applications that has not yet been written to a persistent storage layer, is not covered by platform backups. Your team is responsible for ensuring that application design does not create data persistence gaps that fall outside the platform backup scope.

Disaster Recovery

For environments where business continuity planning requires documented disaster recovery capabilities, GLBNXT can provide a disaster recovery assessment covering your environment's recovery architecture, the scenarios covered, and the recovery time and recovery point characteristics applicable to each scenario.

Disaster recovery documentation is available to enterprise customers and partners on request and can be incorporated into your organisation's broader business continuity planning and regulatory compliance documentation.

For guidance on the high availability and resilience capabilities of the platform infrastructure that complement the backup and recovery layer, see the Security Architecture section. For guidance on the compliance frameworks that may impose specific business continuity and recovery requirements on your environment, see the Compliance Frameworks section.