SGEN backup and restore architecture overview
How SGEN takes a full snapshot of your site and lets you restore it — without the anxiety.
The SGEN backup and restore system captures the full operational state of a site at a point in time and stores that state as a single .sgen file. That file can be used to restore the live site to that exact state, or loaded into a preview environment so an operator can inspect what a restore would look like before committing. Every snapshot is checksum-verified on creation and re-verified before any restore begins.
This page explains the model: what a backup contains, how restoration works, the integrity guarantees that make a snapshot trustworthy, and the use cases the system was designed to handle. For step-by-step configuration, the starting point is the admin → Settings → Backups.
This page is a sibling to Disaster Recovery Overview, Staging and Versioning Overview, the Environment Model, and the Multi-site Architecture Overview. Read this one first when the question is "how does SGEN back up a site, and how solid is the restore?"
What is this for?
This page answers the concept-level questions that come up before an operator sets up backups for the first time, prepares for a compliance audit, or reaches for a restore after something goes wrong:
- What exactly does a backup contain, and what does it leave out?
- What does a restore do to a live site?
- How does SGEN know a snapshot is intact before trusting it?
- Which use cases is this built for, and which ones is it not the right tool for?
Good use cases
This page is the right place to start when you are doing one of the following:
- Planning a pre-change safety net before a significant content migration, theme swap, or configuration change. Understanding the snapshot model tells you exactly what a restore would recover.
- Evaluating SGEN for a compliance requirement that mandates periodic full-site backups with a documented retention window.
- Preparing a disaster recovery runbook for your team, your client, or a procurement reviewer. The model here backs every claim in that runbook.
- Diagnosing why a restore behaved unexpectedly — for example, why post-restore content does not match expectations, or why a restore failed the integrity check.
- Briefing a client or stakeholder on what "backup" means in the context of SGEN, as distinct from page-level version history or audit logging.
What NOT to use this for
This is a concept document. It does not give you:
- Step-by-step backup configuration. See the backup operator guide in SG-Modules documentation.
- Per-page version history. Stage and Live versioning handles individual page snapshots. That is a different system with a different scope. If you need to roll back a single page to a previous draft, that is the right tool.
- Single-record rollback. If a specific content record was changed incorrectly and you need to undo that one action, the audit log combined with manual correction is the right path. Full-snapshot restore is a blunt instrument — it replaces the entire site state.
- Cross-account migration. Moving a site from one SGEN account to another uses the dedicated site migration flow. A
.sgenbackup file is not the right format for cross-account transfer. - Cross-tier downgrades. A backup created on a higher-tier plan cannot always be restored to a lower-tier plan if the snapshot contains features or objects only available at the higher tier. That limitation is covered in the troubleshooting section below.
How backup and restore works in SGEN
The system has two sides: the backup model (how snapshots are created and stored) and the restore model (how they are applied). The two sides are designed to be used together — a backup is only useful if the restore is predictable, and a restore is only trustworthy if the backup is verified.
The backup model.
A backup is a full snapshot of a site at a moment in time. "Full" means every layer of the site's operational state is captured in one file:
- Content — every page, post, and custom object, including drafts and scheduled items.
- Media — every uploaded file: images, videos, documents, attachments.
- Settings — every site setting: SEO defaults, integrations, analytics configuration, domain settings, member roster, custom roles.
- Custom objects — every custom content type defined for the site, including field schemas and stored records.
- Theme and layout state — the active theme, active SG-Builder layouts, and any site-level custom CSS registered in the design system layer.
- Analytics event data. Historical visitor records are not part of the site's operational state. They live in the analytics layer and are not included in a snapshot.
- Transient cache state. The CDN and server-side cache are not snapshot targets. A restore does not restore cache state; the cache rebuilds from the restored content.
- Audit log history. The audit trail records are append-only. They are not overwritten by a restore; a restore adds a restore event to the existing audit trail.
- Scheduled automation jobs outside the site's own content. If a site has integrations that trigger jobs in external systems, those external jobs are not captured.
.sgen file. The format is a structured archive — SGEN-native, not a generic zip. It is human-opaque but machine-structured, with a manifest, a content layer, a media layer, a settings layer, and a verification block.When backups are created.
Backups are created on two paths:
- Scheduled. The operator sets a cadence — daily, weekly, or monthly — and SGEN creates a snapshot automatically at the scheduled time. The schedule runs in the background. No operator action is required once it is configured.
- Manual. The operator triggers a backup on demand from the admin → Settings → Backups. Manual backups are useful before a risky operation — a configuration change, a content migration, a theme update — where the operator wants a known-good state to return to if the change goes wrong.
.sgen snapshot stored in the operator's backup library.The restore model.
SGEN supports two restore modes. The distinction matters.
Full restore. The snapshot replaces the current live site state. Every piece of content, every setting, every media file in the current live site is replaced by what was in the snapshot. This is one-way and immediate: once applied, the live site reflects the snapshot. There is no automatic undo. If the operator wants a safety net for the restore itself, they take a pre-restore snapshot before starting.
Preview restore. The snapshot is loaded into a staging view without touching the live site. The operator can browse the restored state — inspect content, check settings, verify layout — exactly as it would appear after a full restore. If the preview looks correct, the operator commits the restore. If something is wrong, the operator discards the preview and the live site is untouched.
The preview restore mode is the recommended path for any restore that is not a genuine emergency. It costs a few extra minutes and prevents the most common restore regret: discovering after the fact that the snapshot was earlier than intended, or that the restore removed content added since the snapshot was taken.
Snapshot integrity — how SGEN knows a backup is trustworthy
A backup that cannot be verified is not a backup. The SGEN snapshot system includes two integrity checkpoints.
Checkpoint 1 — On save. When a snapshot is created, SGEN generates a checksum of the archive contents. The checksum is stored in the snapshot's verification block, alongside the creation timestamp, the site ID, the plan tier at snapshot time, and a manifest of what was captured. The snapshot is not marked as usable until the checksum computation completes successfully. A failed checksum on save produces a flagged snapshot that cannot be used for restore until the operator acknowledges or discards it.
Checkpoint 2 — On restore. Before any restore begins — full or preview — SGEN re-computes the checksum against the stored verification block. If the computed checksum matches the stored checksum, the restore proceeds. If the checksums diverge — meaning the archive was modified, truncated, or corrupted after creation — SGEN blocks the restore and surfaces an integrity error. The operator is shown the discrepancy and given the option to discard the snapshot or escalate to the support team.
This two-checkpoint model means a snapshot that passes the restore gate was intact when it was created and has not been altered since. An operator using restore-preview after a failed manual change can trust that the snapshot they are restoring from reflects the site as it was — not a partially written file.
Corrupted snapshot behavior.
When SGEN detects a corrupted snapshot, it does three things: it blocks the restore, it logs the integrity failure in the site's audit trail, and it surfaces a clear error in the Backups panel. The snapshot is marked as flagged. The operator can keep the flagged snapshot for support investigation or discard it. A flagged snapshot never silently replaces a working restore target.
How this connects to other features
The backup and restore system is one layer in SGEN's broader data-continuity architecture. Three other systems share related surface area but serve different purposes.
Stage and Live is SGEN's page-level versioning system. Stage and Live captures versions of individual pages and lets an operator promote a page from draft to live, or roll a page back to a previous version, without touching anything else on the site. It is the right tool for per-page version control. It is not a full-site backup, and it does not produce a restorable snapshot. When an operator says "I want to undo last week's page changes without reverting the whole site," that is a Stage and Live operation, not a restore operation.
The audit log records every action taken on a site by a member or by automation: content creation, content edits, setting changes, member additions, restore events. The audit log is append-only — it cannot be cleared by a restore. When a full restore runs, the audit trail records the restore event alongside the actor, the snapshot ID, and the timestamp. The audit log answers "who did what and when." It is not a restore tool.
Disaster recovery is the broader operational plan that includes backup and restore as one component. The disaster recovery architecture document covers the full recovery hierarchy — recovery-time objectives, recovery-point objectives, the role of SGEN's infrastructure-level redundancy alongside the operator's own backup cadence, and the playbook for platform-level incidents. If the question is "how long to recover from a full site loss?" read the Disaster Recovery Overview. If the question is "how do I get a backup I took last week back onto my live site?" this page and the operator guide answer that question.
Multi-site operators should note: backups are per-site. Each site in a portfolio has its own backup library. There is no portfolio-wide backup that covers all sites in one operation. An operator running a twelve-site portfolio who wants to protect all twelve sites sets up backup schedules on each site individually.
| System | Scope | Right tool for |
|---|---|---|
| Backup and restore | Full site snapshot | Pre-change safety nets, disaster recovery, compliance archives |
| Stage and Live | Per-page version | Rolling back a single page, draft-to-live promotion |
| Audit log | Action-by-action record | Accountability, compliance review, tracing a change to an actor |
| Disaster recovery | Platform + operator layer | RTO/RPO planning, infrastructure-level recovery |
| Site migration | Cross-account transfer | Moving a site between SGEN accounts |
How to set up and use backup and restore
Before you start
Before configuring backup schedules, three decisions matter up front. Getting these right the first time avoids the most common backup administration problems.
Decide your cadence. The cadence is the answer to "how much work is acceptable to lose in the worst case?" A site that publishes daily needs a daily backup cadence — a weekly backup means up to six days of content is at risk. A site that publishes once a month can use a monthly backup cadence safely. The cadence does not have to be constant: operators who run active campaigns can increase the cadence temporarily and return to the baseline after the campaign window closes.
Allocate your storage budget. Each backup stored in the library consumes storage. A full-site snapshot for a mature site with a large media library can run several hundred megabytes. The plan tier determines how much backup storage is available and how many snapshots can be stored simultaneously. Operators running large media libraries against a storage-limited plan tier should account for media size when planning retention windows.
Plan your retention window. The retention window is how long a backup is kept before SGEN automatically removes it to free storage. A thirty-day retention window on a daily backup cadence means thirty snapshots are stored at any one time. A ninety-day window on a weekly cadence means thirteen snapshots. The operator's compliance requirement — if one exists — often dictates the minimum retention window. SGEN will not automatically remove a backup until the retention window for that backup has elapsed.
Where to find it
Backup and restore configuration lives in the admin → Settings → Backups.
The Backups panel has three views:
- Backup library. Every snapshot stored for the site, sorted by creation timestamp with the most recent at the top. Each row shows the snapshot timestamp, the backup type (scheduled or manual), the snapshot size, and the integrity status.
- Schedule settings. The cadence, the next scheduled backup timestamp, and the retention window. This is where the operator enables or changes the backup schedule.
- Restore controls. Selecting any snapshot from the library surfaces the restore options: preview restore or full restore. The integrity status is shown before either option is accessible.
Steps
Step 1 — Enable the backup schedule.
Open the admin → Settings → Backups. The schedule is disabled by default on new sites. Toggle the schedule to enabled. SGEN will prompt for a cadence and a retention window before confirming. The schedule becomes active immediately after confirmation; the first scheduled backup runs at the next cadence tick.
Step 2 — Pick a cadence and set retention.
Choose the backup cadence that matches the site's publish frequency: daily for actively publishing sites, weekly for moderate-activity sites, monthly for low-activity sites or compliance archives. Set the retention window to the longer of the compliance requirement or the operator's own recovery horizon — how far back the operator would realistically want to restore.
Step 3 — Trigger a manual backup before any risky operation.
Before a significant change — content migration, theme update, integration reconfiguration, large bulk edit — trigger a manual backup from the Backups panel. Name the snapshot with a note in the manual backup dialog so it is easy to identify in the library. This snapshot is the restore target if the operation goes wrong.
Step 4 — Test a restore preview at least annually.
Once a year, use restore-preview on a recent snapshot to verify that the restore path works and that the snapshot contains what it is expected to contain. A restore preview does not affect the live site. A team that has never tested the restore path does not know whether their backups are usable until the moment they need them. The annual test surfaces integrity issues, storage configuration problems, and runbook gaps before they become real recovery incidents.
Step 5 — Document the runbook.
Write down the answers to these questions and store them somewhere the team can find under pressure: Where is the Backups panel? Who has access to trigger a restore? What is the naming convention for manual backups? What cadence and retention window is configured and why? When was the last restore preview tested? A backup exists to be used in a hurry — the runbook ensures the team can use it without thinking.
What success looks like
A correctly configured backup system produces three observable results.
Backups land on schedule. The backup library shows a new entry at each scheduled cadence tick. If a scheduled backup does not appear, SGEN logs a failure in the audit trail and, depending on the notification configuration, sends an alert. Operators should check the backup library after the first few scheduled runs to confirm the schedule is landing.
Restore preview works without affecting live. A restore preview on a recent snapshot completes successfully, shows the expected site state, and leaves the live site unchanged. If the preview fails the integrity check, that failure is surfaced before any restore begins — the live site is never touched by a failed restore attempt.
The runbook holds up under audit. When a compliance review, a client handoff, or an internal audit asks for evidence of backup discipline, the answers are in writing: cadence, retention window, last test date, restore path, access controls. A runbook that cannot be produced under audit pressure is a runbook that does not exist.
What to do if it does not work
Backup fails with a storage error.
The most common failure. The backup library is full, or the plan tier's storage allocation is exhausted. Resolution: review the retention window — shorten it to free space, or remove manual backups that are no longer needed. If the plan tier's storage ceiling is genuinely insufficient for the site's media library size and cadence, upgrading the plan tier or adjusting the cadence is the path forward. SGEN will not silently overwrite a saved backup to make room for a new one; the new backup fails and is logged.
Restore fails the integrity check.
The snapshot's checksum does not match the stored verification block. The snapshot is flagged and cannot be used for restore. Likely causes: the snapshot file was corrupted in storage (rare), or the snapshot was created during a write that did not complete cleanly. Resolution: check whether an earlier snapshot in the library passes its integrity check — most corrupted-snapshot situations leave adjacent snapshots intact. If the issue is widespread or recurs, contact the SGEN support team with the snapshot IDs and the integrity error details from the audit trail.
Retention removed the snapshot you needed.
The retention window rolled the snapshot out of the library before the restore was needed. Resolution for the immediate situation: if SGEN support is contacted quickly enough after the retention event, the team may be able to assist with snapshot recovery from infrastructure-level backups, depending on the plan tier. Resolution for the long term: extend the retention window to cover the compliance or recovery horizon the team needs. The retention window is always adjustable; the cost is storage against the plan tier's allocation.
Cross-tier restore fails.
A snapshot created on a higher-tier plan contains features, custom objects, or settings that the current (lower-tier) plan does not support. SGEN will surface a compatibility error during the restore-preview phase — before any changes are applied to the live site. Resolution: review the compatibility error detail to understand which features in the snapshot exceed the current plan's capability. The options are upgrading the plan to match the snapshot's tier, or accepting that the restore will land a site in a state that exceeds the current plan (which is not permitted). Attempting a full restore after a compatibility error has been identified is blocked by the system.
Multi-site partial restore confusion.
On a portfolio with multiple sites, a restore on Site A does not affect Site B. If an operator attempts to restore content to the wrong site — for example, confusing the backup library of Site A with Site B because both sites have similar names or were created from the same template — the restore applies cleanly to the selected site. The result is a site that looks wrong. Resolution: confirm the site name and site ID in the Backups panel header before triggering any restore. The audit trail records the site ID in the restore event, so the error is always traceable.
A walked example — pre-migration snapshot
Make the model concrete.
The situation. Your site is preparing a large catalogue migration: 400 new product records, a theme update, and a change to the site's primary navigation. The migration is complex enough that the operator wants a verified restore point before starting.
The backup. The operator opens the admin → Settings → Backups and triggers a manual backup. In the manual backup dialog, they enter the note "Pre-migration snapshot — 2026-05-25 — catalogue v2 + theme update." SGEN creates the snapshot, runs the checksum, and marks it as verified. The snapshot appears in the backup library with a green integrity status indicator.
The migration. The operator runs the migration. Partway through the theme update, an unexpected CSS conflict breaks the site's primary layout at mobile breakpoints. The layout regression is not recoverable through the normal CSS workflow; the change needs to be rolled back entirely.
The restore. The operator opens the Backups panel, locates the pre-migration snapshot, and selects "Preview restore." The preview loads the pre-migration site state into the staging view. The operator confirms that the snapshot shows the correct state — the pre-migration layout, the pre-migration product catalogue, the original navigation — and commits the full restore.
The result. The live site returns to the pre-migration state in full. SGEN logs the restore event in the audit trail: snapshot ID, actor, timestamp, restore type. The migration team restarts from the verified snapshot with a corrected plan.
The same pattern applies to any risky operation: snapshot before, restore if needed, verify with preview before committing.
Retention tiers — what each plan includes
Retention limits scale with plan tier. The table below describes the default retention behavior. Operators can configure retention within the tier's ceiling.
| Plan tier | Maximum retention window | Simultaneous snapshots stored | Manual backups allowed |
|---|---|---|---|
| Starter | 30 days | Up to 5 | Yes |
| Growth | 90 days | Up to 15 | Yes |
| Professional | 180 days | Up to 30 | Yes |
| Business | 365 days | Up to 60 | Yes |
| Enterprise | Custom (negotiated) | Custom | Yes |
The pre-restore checklist
Before any full restore, the operator should confirm each of the following. Restore-preview makes most of this confirmable without risk.
| Check | How to confirm |
|---|---|
| Correct snapshot selected | Snapshot timestamp and backup note match the intended restore point |
| Snapshot integrity passes | Green integrity indicator in the backup library row |
| Pre-restore snapshot taken | A fresh manual backup of the current live state exists, in case the restore itself needs to be undone |
| Restore mode confirmed | Preview restore used first; full restore committed only after preview confirms expected state |
| Access to Backups panel verified | The operator role has the Backups panel available (Administrator role required) |
| Team notified | Other site members who may be working on the site are informed before the restore begins |
When the backup model changes
The backup model is intentionally stable. The snapshot format, the two-checkpoint integrity model, and the full-site scope are not expected to change.
Three categories of change happen more regularly.
Retention tier adjustments. As plan tiers evolve, the retention ceilings and simultaneous-snapshot limits may increase. Existing operators keep their configured retention windows; the ceiling may move up, but it does not move down without notice.
New backup scope options. Future versions may add optional partial-snapshot modes — for example, a media-only backup or a settings-only backup — as supplementary tools alongside the full-site snapshot. These are always additive; the full-site snapshot remains the primary backup artifact.
Restore path improvements. Restore preview may gain additional inspection tools over time — for example, a content diff view that shows what would change between the current live state and the snapshot state before committing. These improve the operator experience without changing the underlying restore model.
What does not change without notice:
- The integrity guarantee. Every snapshot is checksum-verified on save and re-verified on restore. A snapshot that fails verification is never applied to the live site.
- The audit trail durability. Restore events are always recorded, and the audit trail is not overwritten by a restore.
- The per-site scope. Backups are per-site. A restore on one site does not affect any other site in the portfolio.
Connected pages
This concept doc is part of the data-continuity architecture cluster. The related pages cover adjacent ground:
- Disaster Recovery Overview — the full recovery model: RTO/RPO objectives, infrastructure-level redundancy, and the playbook for platform-level incidents.
- Staging and Versioning Overview — how Stage and Live handles per-page version history and page-level rollback.
- Environment Model — the relationship between the live site, the staging environment, and the preview restore surface.
- Multi-site Architecture Overview — per-site backup isolation in the context of a portfolio of sites.
- SGEN Glossary — definitions for
.sgen,snapshot,restore preview,retention window, and other terms used on this page.
The shortest possible summary
If you read nothing else on this page, take this with you:
A SGEN backup is a full snapshot of a site — content, media, settings, and custom objects — in a single verified .sgen file. Snapshots run on a schedule or on demand. Every snapshot is checksum-verified on creation and re-verified before any restore begins. Restore runs in two modes: preview restore lets the operator inspect the restored state before committing; full restore replaces the live site with the snapshot. Restore is one-way — take a pre-restore snapshot first. Backups are per-site. Retention scales with plan tier.That paragraph answers the first question any operator or compliance reviewer asks about the backup system.Reference — backup library entry shape
A populated backup library entry for a SGEN site.
| Field | Example value |
|---|---|
| Snapshot ID | snap_yoursite_2026_05_25_0300 |
| Site | Your Site (yoursite) |
| Created | 2026-05-25 03:00:12 UTC |
| Type | Scheduled (daily) |
| Snapshot size | 284 MB |
| Content objects captured | 1,842 |
| Media files captured | 1,205 |
| Integrity status | Verified |
| Checksum | sha256:4a9f1c... (truncated) |
| Retention expires | 2026-07-24 (90-day window) |
| Created by | Automated schedule |
Reference — restore event shape in the audit trail
A restore event as it appears in the site audit trail after a full restore completes.
| Field | Example value |
|---|---|
| Timestamp (UTC) | 2026-05-25 14:22:04 |
| Event type | backup.restore.full |
| Actor | ada@yoursite.com |
| Actor role | Administrator |
| Snapshot ID | snap_yoursite_2026_05_24_0300 |
| Restore mode | Full |
| Integrity check result | Passed |
| Duration | 4m 12s |
| Entry ID | evt_2026_05_25_r8k2m1p9 |
Where to go from here
With the backup and restore model in hand, the next page depends on the question.
- For "how does SGEN recover from a platform-level failure?" — read the Disaster Recovery Overview.
- For "how does per-page version history work?" — read the Staging and Versioning Overview.
- For "how do backups fit into a multi-site portfolio?" — read the Multi-site Architecture Overview.
- For step-by-step backup configuration — see the backup operator guide in SG-Modules documentation.