Backups
How SGEN handles site backups — scheduling, retention, storage, and restoration. The foundational safeguard.
Backups in SGEN are platform-managed snapshots of site state, scheduled and stored by the platform team rather than assembled per site through plugins or external orchestration. This page is the Reference definition of how backups work — what they capture, where they live, how often they run, how long they are retained, and how restore is shaped.
This is the foundational safeguard behind every other recovery-sensitive operation in the Migration and Import section. Recovery Considerations, Post Migration validation, and the broader Migration workflow all assume the backup model documented here.
What is this for?
Read this page when you want the structural definition of SGEN's backup model — what backups capture, how they are created and retained, where they live, and how restore is structured. It is the entry-point Reference for the Backups sub-page of the Migration and Import section.
The page is a Reference definition. It does not walk you through creating a backup or running a restore — those procedures live in Guides. It also does not enumerate per-customer infrastructure or storage internals; that detail lives in internal operational documentation.
Good use cases
- You are scoping a new SGEN deployment and need to confirm the platform's backup posture.
- You are planning a recovery operation and need to understand what backup snapshots are available.
- You are explaining to a stakeholder why SGEN does not require per-site backup plugins.
- You are designing internal SOPs and need the backup model to anchor recovery procedures.
- You hit a "did the backup run?" question and want the structural model before opening the operational surface.
What NOT to use this for
- Step-by-step procedures for creating, restoring, or scheduling backups — open the relevant Guide.
- Per-customer storage internals — internal-only documentation or support escalation.
- Recovery procedures — open Recovery Considerations Reference.
- Per-release shipped behavior change — open What's New or Changelog.
How this connects to other features
- Migration and Import Overview — the parent Reference area that frames the backup discipline.
- Recovery Considerations — uses backups as the primary recovery vehicle.
- Post Migration — depends on backup safeguards during the validation window.
- SG-Dashboard Overview — the account-tier surface where the backup index across every site is visible.
- SG-Admin Overview — the per-site surface where individual backups for a single site live.
Definition
A backup in SGEN is a platform-managed snapshot of site state. The snapshot captures the site's content, configuration, modules, and operational state at the moment the backup is taken. The platform team owns the schedule, the storage, and the retention discipline; operators do not configure where backups live or assemble the backup pipeline from third-party tools.
The defining property is platform-managed. SGEN backups are first-party — they ship as part of the platform, not as a per-site add-on. Operators can rely on a baseline backup posture without configuring anything. Per-site overrides (cadence adjustments, retention adjustments where the plan supports them) layer on top of the platform-managed default.
Purpose
The purpose of this page is to define backups as a Reference layer rather than as a configuration walkthrough. It explains what backups capture, how the platform handles them, what operators can rely on by default, and how the backup model connects to the wider recovery and migration discipline.
Scope
This page covers SGEN backups at the Reference level — the model rather than the procedure.
The page covers:
- What a backup snapshot captures.
- How backups are scheduled and stored.
- How retention is shaped.
- How restore is structured at the platform level.
- The boundary against Recovery Considerations (the broader recovery framing) and Post Migration (the validation discipline that follows recovery).
- Per-customer storage internals, encryption details, or operational dashboards — internal-only documentation.
- Step-by-step procedures for creating or restoring a backup — Guides.
- Per-release shipped backup behavior change — What's New or Changelog.
Where to find it
Backups live under the admin → Settings → Backups. The index lists all stored snapshots with their capture timestamp and size. To restore from a snapshot, select the entry and choose Restore. On-demand backup capture is available from the same panel using the Create Backup button.
What a backup captures
A backup snapshot captures the site's persistent state — the records, settings, modules, theme registration, custom code, and per-site configuration that define how the site behaves.
Site content
Every record administered through the admin — Pages, Posts, Products, Forms, Custom Objects, Locations, Events, taxonomies, and the relationships between them.
Site configuration
Site identity, settings, theme registration, custom codes, custom fonts, redirects, popups, and the operational toggles that determine how the site renders and behaves.
Module state
The configuration and stored state of every module enabled on the site — store configuration, form definitions, integration connections (the configuration, not the third-party data), automation rules.
Operational state
The state needed to bring the site back to its prior operational shape — published-vs-draft states, in-flight workflows, audit trails relevant to the snapshot moment.
Schedule and retention
The platform schedules backups on a default cadence per site. Operators do not have to configure a backup schedule for the baseline posture to apply.
Default cadence
The platform takes a backup snapshot on a regular cadence per site. The exact cadence is plan-aware — higher tiers may include more frequent snapshots — but every site has at least the baseline cadence configured by default.
Retention discipline
Snapshots are retained for a defined window. Older snapshots roll off as newer ones are taken. Retention is plan-aware in the same way scheduling is, but every site has at least the baseline retention applied automatically.
On-demand backups
Operators can trigger an on-demand backup before a planned high-stakes operation (migration, theme change, custom-code deploy). On-demand backups follow the same storage and retention discipline as scheduled backups.
Storage
Backup storage is platform-owned. Operators do not configure where backups live or pay separately for storage. The Sovereign Infrastructure posture applies — backups stay inside the SGEN platform unless the operator explicitly opts into a mirroring arrangement that the plan supports.
Restore model
Restore is the operation that returns site state to a prior backup snapshot.
What restore does
Restore replaces current site state with the state captured in the chosen snapshot. Records, settings, modules, theme registration, custom code, and operational state all return to the snapshot moment.
Restore-to-staging-first discipline
The platform's recommended posture is restore to staging first, validate, then promote staging to live. Restoring directly to live is supported but should be reserved for confirmed-need cases (Recovery Considerations covers the framing).
Validation after restore
After a restore, operators should walk the Post Migration validation cycle to confirm the restored state behaves as expected before treating the site as production-ready again.
Site · marketing.example.com
Backup history
| Snapshot | Type | Size | Status | Actions |
|---|---|---|---|---|
| 2026-05-04 02:00 UTC | Scheduled · daily | 247 MB | Verified | Restore |
| 2026-05-03 02:00 UTC | Scheduled · daily | 246 MB | Verified | Restore |
| 2026-05-02 14:32 UTC | On-demand · pre-deploy | 248 MB | Verified | Restore |
| 2026-05-02 02:00 UTC | Scheduled · daily | 245 MB | Verified | Restore |
Where backups become visible
Backup outcomes surface in two operator-facing locations.
Account tier — SG-Dashboard Site Manager
The Dashboard Site Manager exposes the backup index across every site the account owns. Operators running a portfolio see one place to confirm the backup state of every site without opening each site's SG-Admin individually.
Site tier — SG-Admin
Inside a single site's SG-Admin (under the Configuration pillar), the operator sees that site's backup history, can trigger an on-demand backup, and can initiate a restore to staging.
Constraints and boundaries
Backups are a Reference area for the foundational recovery safeguard. They are not a substitute for routine version control of editorial state, nor a replacement for staging-vs-live promotion discipline.
Use Backups for:
- Restoring a site to a prior snapshot when current state has been broken durably.
- Capturing a known-good moment before a planned high-stakes operation.
- Confirming the platform's recovery posture during stakeholder evaluation.
- Routine editorial undo — staging-vs-live promotion handles that.
- Per-record version history — that is administered through the admin's per-module surfaces where supported.
- Substituting for the platform's audit trail — Audit-Ready Logging captures admin actions separately.
Public boundary
This page is intentionally public-safe. It does not expose backup storage internals, encryption details, exact retention numbers (those are plan-specific), or protected operational identifiers.
Examples
Example 1 — Operator restores a site after a bad theme change
An operator updates a theme registration that breaks layout across multiple pages. They open SG-Dashboard Site Manager, see the latest snapshot from before the theme change, restore to staging, validate the restored state, then promote staging to live. The backup model documented here is the structural anchor for the operation; the relevant Guide carries the step detail.
Example 2 — Migration operator captures a snapshot before importing
The migration operator triggers an on-demand backup before running a content batch import. The on-demand snapshot becomes the rollback target if the import does not behave as expected. The backup model gives the operator confidence that the rollback path is in place before the higher-risk operation begins.
Example 3 — Stakeholder asks "what happens if a deploy goes wrong?"
The stakeholder wants the framing for SGEN's recovery posture. The platform lead opens this page (Backups as foundational safeguard) and Recovery Considerations (the broader recovery framing) together. The pair of references gives a structured answer: scheduled backups + on-demand snapshots + restore-to-staging-first discipline = the platform's recovery model.
Documentation guidance
Use this page as the structural definition for the backup safeguard. Procedural detail belongs in Guides; per-release behavior change belongs in What's New or Changelog. Cross-reference Recovery Considerations and Post Migration when the question moves beyond the backup itself into the broader recovery cycle.
Reading order
Open this page first when scoping recovery posture. Pair with Recovery Considerations for the broader recovery framing. Pair with Post Migration for the validation discipline that follows restore. Pair with the SG-Dashboard Site Manager Reference for the account-tier surface where the backup index lives.
Related reading
- Migration and Import Overview — parent Reference area.
- Recovery Considerations — broader recovery framing.
- Post Migration — validation after restore.
- Import — sibling operation; backup precedes import.
- SG-Dashboard Overview — account-tier backup index.
- SG-Admin Overview — per-site backup surface.
- Architecture and Reliability — architectural posture for recovery.
Vocabulary cross-reference
- Backup is a recoverable snapshot of site state.
- Snapshot is a single backup instance taken at a specific moment.
- Restore is the operation that returns site state to a prior snapshot.
- Retention is the window during which snapshots are kept before rolling off.
- On-demand backup is a snapshot triggered by the operator outside the default schedule.
- Scheduled backup is a snapshot taken automatically on the platform's default cadence.
Maintenance discipline
When backup behavior changes across releases (new cadence, new retention, new storage option), the canonical here is updated and the change is also logged in Changelog. Operators should treat this Reference as the current model and Changelog as the historical ledger of how the model evolved.
Pairing with Architecture and Reliability
For stakeholders who want the architectural reasoning behind the backup posture — why the platform owns backup storage, why restore-to-staging-first is the recommended discipline, why retention is platform-managed rather than operator-configured — pair Backups with Architecture and Reliability. The architectural pages explain the structural commitments; this Reference applies them to the per-operation discipline.
The pairing matters for procurement evaluations and stakeholder explanations. The architectural posture answers "why does the platform handle backups this way?"; the Backups Reference answers "what does that mean for me as an operator?".
When this page is the right first read
This page is the right first read when an operator, a stakeholder, or a documentation author needs the structural model behind SGEN's backup safeguard. It is not the right first read when the question is about a specific recovery procedure (open Recovery Considerations + Guides instead) or about a per-customer storage configuration (escalate to support instead). Backups are foundational; the rest of the Migration and Import section assumes the model on this page.
The Backups Reference, paired with Recovery Considerations, is the team's anchor during incident response and during planned high-stakes operations. Reading it once during onboarding and revisiting it before every restore decision is the discipline this Reference is shaped for.
The same pairing applies in reverse: when scoping a planned operation that may need rollback, the operator confirms the backup state on the Dashboard or SG-Admin Backup surface, then opens this Reference to confirm the model, then opens Recovery Considerations for the broader framing. The three pages — Backups (this page), Recovery Considerations, the operational backup surface — together carry the operator from question to confidence in roughly five minutes.
Final note
Backups are the safeguard the rest of the recovery model relies on. Every other Reference page in this section assumes the backup posture documented here is in place by default. That assumption holds because backups are platform-managed, not operator-assembled — which is the architectural posture the rest of the platform leans on too.