Sync docs from ops-cli repo

Author: github-actions

…s/docs-backup/guides/backup-instance.mdx docs/docs-backup/backup/create.mdxdocs/docs-backup/guides/backup-instance.mdx renamed to docs/docs-backup/backup/create.mdx docs/docs-backup/guides/backup-instance.mdx renamed to docs/docs-backup/backup/create.mdx

@@ -5,7 +5,7 @@ title: Back up your Infrahub instance
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-This guide walks you through creating a comprehensive backup of your Infrahub instance. If you need to protect your data, prepare for upgrades, or establish disaster recovery procedures, follow these steps to create reliable backups.
+Create a comprehensive backup of an Infrahub instance on Docker Compose. Follow these steps to protect your data before an upgrade or to establish a disaster-recovery routine.
 
 ## Community edition support
 
@@ -188,7 +188,7 @@ infrahub-backup restore infrahub_backups/infrahub_backup_20250929_143022.tar.gz
 
 ### Automated backups with cron
 
-You can either use a [systemd timer](install#system-service-installation) or regular cron.
+You can either use a [systemd timer](./install#system-service-installation) or regular cron.
 
 Create a cron job for regular backups:
 
@@ -321,5 +321,5 @@ Confirm your backup strategy works:
 
 ## Related resources
 
-- [Restore from a backup](./restore-backup.mdx)
+- [Restore from a backup](./restore.mdx)
 - [CLI command reference](../reference/commands.mdx)

docs/docs-backup/backup/index.mdx

@@ -0,0 +1,52 @@
+---
+title: Infrahub Backup
+---
+
+Use Infrahub Backup to create and restore verifiable recovery points for an Infrahub deployment. Run it as a CLI against Docker Compose, or as a Helm chart on Kubernetes, to capture the graph database and the task-manager database as a single archive you can restore from later. Artifact storage lives outside those databases, so you snapshot it as a separate, coordinated step to keep a recovery complete.
+
+## Why reliable backups matter
+
+Infrahub keeps critical infrastructure state across several systems: the Neo4j graph database, the PostgreSQL database behind the task manager, and external artifact storage. If any piece is lost or corrupted, you can end up with drifted configuration, orphaned tasks, or a deployment that no longer starts. Regulatory and business-continuity requirements often call for auditable recovery procedures, so ad-hoc database dumps are rarely enough — you need consistent, verifiable recovery points.
+
+## How it works
+
+Infrahub Backup coordinates backup and restore across deployment targets. During a backup it captures each database with the correct credentials and packages everything so a restore is deterministic. Enterprise deployments are backed up online, with no downtime; Community Edition is dumped offline, so the tool first stops the Infrahub services and restarts them once the snapshot is complete. During a restore it brings services back in dependency order, reapplies the data, and records logs so you can confirm the operation succeeded. The CLI runs the provider-specific Docker or Kubernetes commands for you and sequences each step.
+
+On Kubernetes, the `infrahub-backup` Helm chart manages backups declaratively through your existing GitOps pipeline. Schedule backups with a CronJob, push archives to S3-compatible storage, and run restores — all without direct kubectl access.
+
+## High availability
+
+Infrahub Backup supports high availability (HA) deployments on both Kubernetes and Docker Compose:
+
+- **Kubernetes**: HA PostgreSQL is supported through [CloudNativePG](https://cloudnative-pg.io/) only. The tool detects the primary pod and targets it during backup and restore — no extra configuration needed.
+- **Docker Compose**: HA setups require stopping the `task-manager` and `task-manager-background-svc` containers before a restore, to keep them from accessing the database while data is replaced. See [Restore from a backup](./restore.mdx#docker-high-availability-deployments).
+
+## Community edition support
+
+Infrahub Backup works with Infrahub Community Edition as well as Enterprise deployments. A backup against Community Edition stops the Infrahub service while the snapshot is taken, so plan for a short interruption. A restore must target the same edition that produced the backup — Enterprise backups cannot be restored to Community Edition.
+
+## Best practices
+
+### Schedule regular backups
+
+- On Kubernetes, enable the `infrahub-backup` Helm chart in CronJob mode for automated, declarative scheduling that fits your GitOps workflow.
+- On Docker Compose, automate backups with cron, systemd timers, or CI workflows; daily is a good baseline, with more frequent snapshots for high-change environments.
+- Configure S3-compatible storage to push backups off-cluster, and apply bucket lifecycle policies for retention.
+- Rotate archives with a retention policy that matches your recovery point objectives, and replicate critical backups to an off-site location.
+- Monitor backup jobs and alert on failure — silent backup gaps are often noticed only when it is too late.
+
+### Run regular restore tests
+
+- Restore into a disposable environment at least monthly to confirm that credentials, network access, and storage quotas are still correct.
+- Track how long a restore takes and compare it to your recovery time objectives; tune the schedule or resource sizing if the gap widens.
+- Document each drill, including any manual steps you find, and fold the lessons back into your runbooks.
+
+### Validate backups after major Infrahub upgrades
+
+- After every major Infrahub version upgrade, capture a fresh backup and run a full restore rehearsal.
+- Watch for schema migrations or new services introduced by the upgrade that need additional credentials, storage buckets, or automation hooks.
+- Keep the validation artifacts — logs, checksums, and timelines — so you can demonstrate post-upgrade recoverability during audits.
+
+## Learn by doing
+
+New to the tool? The [Get started tutorial](../tutorials/getting-started.mdx) covers a full backup and restore cycle on a Docker Compose deployment.

docs/docs-backup/guides/install.mdx docs/docs-backup/backup/install.mdxdocs/docs-backup/guides/install.mdx renamed to docs/docs-backup/backup/install.mdx

@@ -5,7 +5,7 @@ title: Install Infrahub Backup
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-This guide shows you how to install Infrahub Backup on your system.
+Install the `infrahub-backup` CLI on a Docker Compose or Kubernetes deployment, or build it from source.
 
 ## Prerequisites
 
@@ -28,7 +28,7 @@ Before installing Infrahub Backup, ensure you have:
 **If building from source:**
 
 - Git and network access to clone the repository
-- Go 1.21 or later installed
+- Go 1.25 or later installed
 
 ## Installation methods
 
@@ -89,7 +89,7 @@ If you need a specific version or architecture, manually select the appropriate
 
 To install Infrahub Backup, build from source:
 
-1. Install Go 1.21 or later:
+1. Install Go 1.25 or later:
 
    ```bash
    # Check if Go is installed
@@ -322,6 +322,6 @@ For Docker deployments, you can run scheduled backups using a systemd service:
 
 ## Related resources
 
-- [Getting started tutorial](../tutorials/getting-started.mdx)
+- [Get started tutorial](../tutorials/getting-started.mdx)
 - [Configuration reference](../reference/configuration.mdx)
-- [Back up your Infrahub instance](./backup-instance.mdx)
+- [Back up your Infrahub instance](./create.mdx)

…docs-backup/guides/kubernetes-backup.mdx …docs-backup/backup/kubernetes-backup.mdxdocs/docs-backup/guides/kubernetes-backup.mdx renamed to docs/docs-backup/backup/kubernetes-backup.mdx docs/docs-backup/guides/kubernetes-backup.mdx renamed to docs/docs-backup/backup/kubernetes-backup.mdx

@@ -5,7 +5,7 @@ title: Back up Infrahub on Kubernetes
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-This guide walks you through backing up your Infrahub instance running on Kubernetes using the `infrahub-backup` Helm chart. If you deploy Infrahub through GitOps tools like ArgoCD or Flux and don't have direct kubectl access, this approach lets you manage backups declaratively through Helm values.
+Back up an Infrahub instance running on Kubernetes with the `infrahub-backup` Helm chart. If you deploy Infrahub through GitOps tools like ArgoCD or Flux without direct kubectl access, manage backups declaratively through Helm values.
 
 ## Why use the Helm chart for backups
 
@@ -383,4 +383,4 @@ Confirm your backup configuration works:
 ## Related resources
 
 - [Restore Infrahub on Kubernetes](./kubernetes-restore.mdx)
-- [Back up your Infrahub instance (CLI)](./backup-instance.mdx)
+- [Back up your Infrahub instance (CLI)](./create.mdx)

…ocs-backup/guides/kubernetes-restore.mdx …ocs-backup/backup/kubernetes-restore.mdxdocs/docs-backup/guides/kubernetes-restore.mdx renamed to docs/docs-backup/backup/kubernetes-restore.mdx docs/docs-backup/guides/kubernetes-restore.mdx renamed to docs/docs-backup/backup/kubernetes-restore.mdx

@@ -5,7 +5,7 @@ title: Restore Infrahub on Kubernetes
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-This guide walks you through restoring your Infrahub instance on Kubernetes from a backup stored in S3-compatible storage. The restore process uses the same `infrahub-backup` Helm chart and runs as a Kubernetes Job.
+Restore an Infrahub instance on Kubernetes from a backup stored in S3-compatible storage. The restore runs as a Kubernetes Job through the same `infrahub-backup` Helm chart.
 
 :::warning
 Restoring a backup will overwrite your current Infrahub data. Create a safety backup before proceeding if you need to preserve any recent changes.
@@ -321,4 +321,4 @@ Confirm your restore completed successfully:
 ## Related resources
 
 - [Back up Infrahub on Kubernetes](./kubernetes-backup.mdx)
-- [Restore from a backup (CLI)](./restore-backup.mdx)
+- [Restore from a backup (CLI)](./restore.mdx)

…cs/docs-backup/guides/restore-backup.mdx docs/docs-backup/backup/restore.mdxdocs/docs-backup/guides/restore-backup.mdx renamed to docs/docs-backup/backup/restore.mdx docs/docs-backup/guides/restore-backup.mdx renamed to docs/docs-backup/backup/restore.mdx

@@ -5,7 +5,7 @@ title: Restore from a backup
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-This guide shows you how to restore your Infrahub instance from a backup file. If you need to recover from data loss, roll back changes, or migrate to new infrastructure, follow these steps to safely restore your system.
+Restore an Infrahub instance from a backup file on Docker Compose. Follow these steps to recover from data loss, roll back a change, or move to new infrastructure.
 
 ## Community edition compatibility
 
@@ -234,5 +234,5 @@ Confirm restoration was successful:
 
 ## Related resources
 
-- [Back up your Infrahub instance](./backup-instance.mdx)
+- [Back up your Infrahub instance](./create.mdx)
 - [CLI command reference](../reference/commands.mdx)

…uides/collect-troubleshooting-bundle.mdx docs/docs-backup/collect/create.mdxdocs/docs-backup/guides/collect-troubleshooting-bundle.mdx renamed to docs/docs-backup/collect/create.mdx docs/docs-backup/guides/collect-troubleshooting-bundle.mdx renamed to docs/docs-backup/collect/create.mdx

@@ -5,15 +5,7 @@ title: Collect a troubleshooting bundle
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-Use `infrahub-collect` to gather everything OpsMill support needs to investigate an issue — service logs, diagnostic status, configuration, and metrics — into a single local archive. Run it when support asks for logs, or to attach diagnostic data to a support request. The same command produces the same bundle on Docker Compose and Kubernetes deployments.
-
-:::info
-Collection is strictly read-only. Unlike `infrahub-backup create`, the collect command never stops, restarts, or scales any container or pod, so it is safe to run against a production instance at any time — including while the instance is degraded.
-:::
-
-:::note Collect or back up?
-A troubleshooting bundle contains diagnostics for support to read; a [backup](./backup-instance.mdx) is a restorable snapshot of your data. When support asks for both, run `infrahub-collect create --include-backup` to produce them in one run.
-:::
+Collect a troubleshooting bundle from an Infrahub deployment and share it with OpsMill support. Collection is read-only and safe to run at any time, including while the instance is degraded. See [Infrahub Collect](./index.mdx) for what a bundle contains and how secrets are masked. The same command produces the same bundle on Docker Compose and Kubernetes.
 
 ## Prerequisites
 
@@ -22,21 +14,21 @@ Before collecting a bundle:
 <Tabs>
 <TabItem value="docker" label="Docker Compose" default>
 
-- The `infrahub-collect` binary is installed ([installation guide](./install-collect.mdx))
+- The `infrahub-collect` binary is installed ([installation guide](./install.mdx))
 - Docker and Docker Compose are available to your user
 - The Infrahub Compose project is running (fully or partially)
 
 </TabItem>
 <TabItem value="kubernetes" label="Kubernetes">
 
-- The `infrahub-collect` binary is installed ([installation guide](./install-collect.mdx))
+- The `infrahub-collect` binary is installed ([installation guide](./install.mdx))
 - `kubectl` is configured with access to the cluster running Infrahub
 - Your role can read pod logs and execute commands in pods (`pods/log` and `pods/exec`); no write or scale permissions are needed
 
 </TabItem>
 </Tabs>
 
-The binary is self-contained and collection works fully offline: it uses your existing Docker or kubectl access and performs no network access beyond your deployment itself.
+The binary is self-contained and collection works offline by default: it uses your existing Docker or kubectl access and performs no network access beyond your deployment itself. The one exception is the opt-in `--benchmark`, which downloads a benchmark image.
 
 ## Step 1: Verify environment detection
 
@@ -265,7 +257,7 @@ Confirm your collection works:
 
 ## Related resources
 
-- [Install Infrahub Collect](./install-collect.mdx)
-- [Back up your Infrahub instance](./backup-instance.mdx)
+- [Install Infrahub Collect](./install.mdx)
+- [Back up your Infrahub instance](../backup/create.mdx)
 - [CLI command reference](../reference/commands.mdx)
 - [Configuration reference](../reference/configuration.mdx)

docs/docs-backup/collect/index.mdx

@@ -0,0 +1,38 @@
+---
+title: Infrahub Collect
+---
+
+Use Infrahub Collect to gather everything OpsMill support needs to investigate an issue — service logs, diagnostic status, configuration, and metrics — into a single local archive. Run it when support asks for logs, or to attach diagnostic data to a support request. The same command produces the same bundle on Docker Compose and Kubernetes.
+
+## Safe to run at any time
+
+Collection is strictly read-only. Unlike `infrahub-backup create`, the collect command never stops, restarts, or scales any container or pod, so it is safe to run against a production instance at any time — including while the instance is degraded. If a service is down, collection continues with the rest and records the failure in the manifest. A partial bundle is still a useful bundle — a degraded instance is precisely when you need one.
+
+The binary is self-contained. By default, collection works offline: it uses your existing Docker or kubectl access and performs no network access beyond the deployment itself. The one exception is the opt-in `--benchmark`, which downloads a benchmark image.
+
+## Collect or back up?
+
+A troubleshooting bundle contains diagnostics for support to read; a [backup](../backup/create.mdx) is a restorable snapshot of your data. They are separate operations with different safety profiles — collection is read-only, while a backup can stop containers while the snapshot is taken. When support asks for both, run `infrahub-collect create --include-backup` to produce them in one run.
+
+## What a bundle contains
+
+Each bundle is a single `tar.gz` archive. Inside, every file lives under a top-level `bundle/` directory, alongside a `bundle_information.json` manifest that records an explicit outcome — success, failed, or skipped — for every collector, so support can see what was captured and what was not.
+
+| Collector | What it gathers |
+|---|---|
+| Service logs | Container logs for every service and replica, plus previous-container logs for restarted pods |
+| Database | Neo4j server logs (full log directory with `--include-queries`) |
+| Message queue | RabbitMQ queues, exchanges, bindings, connections, and status |
+| Cache | Redis info, client list, configuration, and slow log |
+| Task worker | Prefect worker state, one directory per replica |
+| Task manager | Work pools, work queues, recent flow runs, events, and automations |
+| Server | Version, installed packages, API information, configuration, schema, and masked environment variables |
+| Metrics | Container resource usage |
+| Backup (opt-in) | A standalone backup produced by the standard backup behavior and referenced in the manifest, not embedded in the archive (`--include-backup`) |
+| Benchmark (opt-in) | Host resource benchmark results (`--benchmark`) |
+
+The layout is identical on Docker Compose and Kubernetes.
+
+## Review before sharing
+
+Masking is based on key names: environment variables and configuration keys containing `password`, `secret`, `token`, or `key` are replaced with `********` before they are written to the bundle. Secrets stored under other key names are not detected. Service logs are collected as-is, and database query logs (`--include-queries`) can contain customer data. Review the bundle contents before sharing it.

…s/docs-backup/guides/install-collect.mdx docs/docs-backup/collect/install.mdxdocs/docs-backup/guides/install-collect.mdx renamed to docs/docs-backup/collect/install.mdx docs/docs-backup/guides/install-collect.mdx renamed to docs/docs-backup/collect/install.mdx

@@ -5,7 +5,7 @@ title: Install Infrahub Collect
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-This guide shows you how to install Infrahub Collect on your system.
+Install the `infrahub-collect` CLI. One binary collects from both Docker Compose and Kubernetes deployments; on Kubernetes it runs from your workstation or a CI runner and reaches the cluster through kubectl.
 
 ## Prerequisites
 
@@ -172,6 +172,6 @@ If these commands succeed, installation is complete.
 
 ## Related resources
 
-- [Collect a troubleshooting bundle](./collect-troubleshooting-bundle.mdx)
+- [Collect a troubleshooting bundle](./create.mdx)
 - [CLI command reference](../reference/commands.mdx)
 - [Configuration reference](../reference/configuration.mdx)