Back up and restore your site
How to take a manual backup, find an existing snapshot, run a restore, and shape what gets kept.
Backups are how you make a moment recoverable.
Restore is how you bring that moment back.
This page walks the full safeguard workflow for a single SGEN site — taking a snapshot on demand, finding the right snapshot in the backup index, running a full or partial restore, and shaping the retention rules so the right history is on the shelf when you need it.
The page is written to be useful for two operating modes.
The first is planned change — you are about to do something risky and want a known-good snapshot to fall back to.
The second is unplanned recovery — something went sideways on the live site and you need to put it back the way it was an hour ago.
Both modes share the same surfaces, so once the workflow is in your head, either mode is a few clicks.
What is this for?
Use this page when you need to take a backup, restore from a backup, or change how long backups are kept for a site. It covers the customer-facing surface — the admin Backups module for a single site, plus the SG-Dashboard backup index that aggregates snapshots across every site in the portfolio.
The page is a how-to. It does not define what a backup is at the architectural level — that lives in the Backups Reference under migration-and-import. It does not cover backup of the SGEN platform itself; that is platform-managed and not operator-configurable.
Good use cases
- You are about to install a custom code block, change a template, or run a bulk content edit, and you want a fresh snapshot before you start.
- A page changed in a way you did not expect and you want to roll only that page back to a known-good state.
- You are migrating in from another platform and want a clean restore point taken right after the first stable build.
- A team member made a change that needs to come out, and you want to compare the current state against a snapshot from yesterday.
- You are scoping a new agency engagement and need to confirm what the customer's backup history looks like.
What NOT to use this for
- One-file rollback inside a single page. Use the per-page revision history in the admin Pages instead. Backup-and-restore is a coarser operation.
- Long-term archival. Backups are operational safeguards with a retention window. For long-term archival, export the site to a
.sgenfile and store the export. - Cross-site copy. Restore brings a snapshot back into the same site. To clone or seed a new site from a snapshot, use the Import workflow instead.
How this connects to other features
- Backups Reference — the structural definition of what a snapshot captures and how the platform stores it.
- Recovery Considerations — the broader recovery posture, including when to escalate beyond a simple restore.
- Post Migration — validation work that depends on a fresh restore point.
- Audit Log — every backup-and-restore action is recorded; use the log to confirm what ran and who triggered it.
Before you start
- You are signed in as a user with site-admin permission for the site you want to back up or restore. Editors cannot trigger restores.
- The site is in a stable state. Triggering a backup mid-publish captures whatever is in flight, which is rarely what you want.
- If you are running a restore, the team is told. Restore replaces live state for the site; anyone editing a page at the same moment loses their unsaved work.
- The retention window for the site covers the snapshot you want. Snapshots older than the retention window are no longer in the index.
Where to find it
Two surfaces carry backup-and-restore.
The per-site surface is the admin → Backups inside the site you are editing. This surface lists every snapshot for that one site, lets you take a manual backup, and runs the restore.
The account surface is SG-Dashboard → Site Manager → Backups at the portfolio level. This surface lists snapshots across every site in the account. Use it to find a snapshot when you are not already inside the site, or when you are scanning multiple sites at once.
Steps
The full workflow has four parts — take a backup, find a snapshot, run a restore, and review retention. The steps below cover the per-site surface; the account surface is similar but with site-pick added at the top.
1. Take a manual backup
Open the site in the admin.
Click Backups in the left navigation.
The page opens to the backup index for the site.
The most recent snapshot sits at the top.
Click Take Backup in the top right.
A confirmation panel opens with a single field, Backup label.
Enter a short label that names why you are taking the snapshot.
Useful labels read like a sentence the future-you reads in a hurry — before template swap, pre-bulk-edit 2026-05-21, clean baseline after migration.
Avoid labels like test or backup.
Click Start Backup.
The job runs in the background.
The page returns to the index, and the new snapshot appears at the top with status Running.
The status changes to Ready when the snapshot is complete — small sites take less than a minute; larger sites with extensive media libraries can take several minutes.
You do not need to keep the page open.
SGEN sends an in-app notification when the snapshot is ready, and the index shows the Ready status the next time the page is opened.
For a team operating across time zones, the notification carries the snapshot ID, the label, the size, and the completion timestamp.
The same notification appears in the team's notification stream if the team has the notification surface configured.
2. Find a restore point
The backup index lists every snapshot the site holds.
Each row shows the timestamp, the label, the source (manual or scheduled), the size, and the status.
The filter row above the table holds three filters.
Source narrows to manual snapshots or scheduled snapshots.
Date range scopes the index to a window.
Label does a substring match against the label text.
For most recovery work the right starting point is the most recent snapshot before the change that caused the problem.
If you are restoring after a content edit at 10:14, the right snapshot is the one timestamped before 10:14.
Use the date range filter to scope the window and read the labels to confirm.
Click a row to expand the snapshot.
The expanded view shows the size, the captured surface (pages, posts, media, settings, modules), and the original trigger — manual with the label, or scheduled with the cadence name.
If the snapshot you need is older than the retention window, it is no longer in the index.
Open Recovery Considerations for the escalation path.
For a portfolio search across multiple sites, switch to the account-level Site Manager Backups surface.
The aggregated index lets you find a snapshot when the site name is the question — not the timestamp alone.
Use the site filter on the left and the date filter on top to scope quickly.
3. Run a full or partial restore
With the snapshot expanded, click Restore in the row's action menu.
The restore panel opens with the snapshot pre-selected and a default scope of Full restore.
A full restore replaces every captured surface in the site with the snapshot version.
Pages, posts, media references, settings, and module configuration all roll back to the snapshot timestamp.
A partial restore narrows the scope.
Click Switch to partial in the panel header.
The scope list opens with four toggles — Pages, Posts, Media references, Settings.
Tick only the surfaces you want to bring back.
Surfaces left unticked stay at the current state.
Partial restore is useful when one surface drifted and the rest of the site is fine.
A common pattern — a settings change went wrong, so the operator restores only Settings from a snapshot two hours back and leaves the pages and posts untouched.
Enter a short note in the Restore note field.
The note shows up in the Audit Log and helps anyone reviewing later understand why the restore ran.
Click Start Restore.
The site enters a brief maintenance state — public visitors see a short maintenance page while the restore runs.
The maintenance window is typically under two minutes for full restores on a small site and a few minutes for larger sites with extensive media.
When the restore completes, the site returns to normal serving and the index marks the snapshot with a Restored from badge.
Before clicking Start Restore, run one final check.
Confirm the snapshot timestamp matches what you intend to restore to.
Confirm the partial-restore scope matches the change you want to roll back.
Confirm no team member is in the middle of editing a page that the restore will touch.
These checks take twenty seconds and prevent the type of surprise that produces a second incident on top of the first.
4. Review and adjust retention
Click Retention Settings in the top right of the Backups page.
The retention panel opens with the current rules.
The default retention is the platform baseline for the plan.
On most plans, the baseline is daily snapshots kept for seven days, weekly snapshots kept for four weeks, and monthly snapshots kept for six months.
Each plan tier may extend this window — check the active plan in SG-Dashboard for the exact ceiling.
The retention panel exposes three rules.
Daily snapshots sets how many recent daily snapshots stay in the index.
Weekly snapshots sets how many weekly snapshots stay.
Monthly snapshots sets how many monthly snapshots stay.
Move a slider to extend or reduce a retention window.
The panel shows the effective storage footprint as the slider moves, so the impact on plan storage is visible before saving.
Click Save Retention.
The new rules apply immediately.
Snapshots already outside the new window are not deleted retroactively until the next retention sweep, which runs once per day.
Manual snapshots count against the same retention windows by default.
If a manual snapshot needs to stay outside the retention window, mark it as Pinned in the row action menu.
Pinned snapshots are not subject to retention sweeps; they stay in the index until manually unpinned.
5. Schedule recurring snapshots
Open Schedule in the top right of the Backups page.
The schedule panel shows the active cadence for the site.
Most sites run on the platform default — one snapshot per night during the off-peak window.
A site with active commerce or a high content-edit cadence may benefit from a more frequent schedule.
Pick the Cadence — daily, every twelve hours, or every six hours.
Pick the Run window — the local time band during which the snapshot job is allowed to run.
Pick the Label prefix — a short string that appears at the front of every scheduled label, useful for filtering later.
Click Save Schedule.
The new cadence applies on the next eligible window.
Existing snapshots stay in the index unchanged; the new cadence starts producing entries on the next run.
For sites with significant editorial cycles, align the cadence with the cycle.
A weekly publishing cadence pairs cleanly with daily snapshots and a weekly pinned reference.
6. Verify a snapshot before relying on it
A backup that has not been verified is a hypothesis.
Verification turns the hypothesis into a known.
Open the snapshot row in the index.
Click Verify in the action menu.
SGEN runs a read-only integrity check against the snapshot — the captured surface is enumerated, the references resolved, the size confirmed.
The check runs in the background.
The row shows a Verifying badge during the check; the badge clears to Verified on a clean result, or to Verification failed on a problem.
For a flagged snapshot, the expanded detail panel names the failing component.
Open the named component, run the standard recovery path for that component, and re-verify when resolved.
A verified snapshot carries the Verified badge in the index forever — even after retention sweeps move it through the lifecycle.
For audit-grade evidence, pair a manual verification with the snapshot pin so the verified state lives in the index without expiry.
What success looks like
A backup is successful when the snapshot reaches Ready status in the index and the in-app notification confirms the snapshot ID. The snapshot is then a valid restore source.
A restore is successful when the site returns to normal serving, the index marks the source snapshot with a Restored from badge, the Audit Log records the restore action with the note text, and a spot-check of the restored surface matches the snapshot timestamp's state.
Retention is correctly shaped when the index window matches the saved rules — older snapshots have fallen out of the index as expected and pinned snapshots are still present.
What to do if it does not work
- Backup stuck in Running state. Snapshots normally complete in under five minutes for typical sites. If the status has not changed in fifteen minutes, refresh the page; if still stuck, contact support — the backup worker may be holding a stale lock that needs to be released by the platform team.
- Restore failed mid-run. The site returns to its pre-restore state automatically; restore is transactional. The index shows the snapshot with a Restore failed badge and an error code. Open the snapshot to see the error context. Most failures are environment-side and resolve on retry.
- Snapshot you want is not in the index. Confirm the retention window covers the timestamp you need. If the snapshot is outside retention, escalate to support for off-index recovery; do not assume the snapshot is gone — the platform may retain off-index copies for a short additional window.
- Partial restore unticked Pages but Pages also changed. Pages link to media; if Media references are ticked, the media surface rolls back and pages that depend on a since-removed media item may show broken images. Re-run the restore with Media references unticked, or accept the media rollback and reattach the missing items.
- Retention slider will not save. The retention window for the plan tier may be capped. If the slider clamps below the requested value, the plan limit is reached; upgrade the plan or work within the cap.
- Pinned snapshot disappeared from the index. A pinned snapshot is exempt from retention sweeps but is not exempt from explicit deletion. Open the Audit Log and filter to backup events for the site; if a team member deleted the snapshot, the log carries the action and the actor. If no deletion event appears, contact support — the pin may have been cleared in error.
- Restore note appears blank in the Audit Log. The note field was left empty at restore time. Future restores: enter a short note so the action carries context for anyone reviewing later. The blank entry stays in the log as evidence; treat it as a lesson rather than something to overwrite.
- Backup index loads slowly on a large portfolio. When a site holds many hundreds of snapshots, the index pagination takes longer to render. Filter by date range first to scope the table; this is the fastest path on a long history.
Examples
Example A — pre-change safeguard for a template swap.
Operator opens the admin → Backups, clicks Take Backup, enters the label pre template swap 2026-05-21, clicks Start Backup.
The snapshot reaches Ready in 90 seconds.
The operator runs the template swap.
The new template renders incorrectly on three pages.
The operator returns to Backups, locates the pre template swap 2026-05-21 snapshot, runs a partial restore scoped to Pages only, leaving the new template active.
The three pages reset to their pre-swap content; the operator now reconciles the pages one at a time without losing the rest of the template work.
Example B — content rollback at the page-set level.
A bulk content edit ran across twenty product pages and inadvertently overwrote the meta description on each.
Operator opens Backups, filters by date range to the snapshot before the bulk edit, expands the row, runs a partial restore with only Pages ticked.
The twenty product pages return to their previous meta descriptions; the rest of the site is untouched.
Example C — pinning a clean baseline after migration.
Migration completes from a previous platform.
Operator runs a manual backup labeled clean baseline after migration.
The snapshot reaches Ready.
The operator opens the row action menu and selects Pin.
The snapshot is now exempt from retention sweeps and will stay in the index as the canonical post-migration reference, available for restore at any time.
Example D — emergency rollback after a settings change broke the public site.
A site admin changed the home-page template assignment on a busy commerce site at 14:08.
By 14:11 the team noticed the home page was rendering the wrong layout and conversion was dropping.
The admin opened the admin → Backups, found the scheduled snapshot taken at 13:00, expanded the row, ran a partial restore scoped to Settings only.
The site entered a one-minute maintenance window.
The home page returned to the prior template; the morning's content edits on other pages stayed intact.
The Audit Log shows the restore action with a note explaining the rollback.
Post-incident, the team set a manual snapshot before every template change going forward.
Example E — coordinated full restore on a small marketing site.
A solo operator ran a bulk find-and-replace on the site copy that produced cosmetic damage across 40 pages.
The operator opened Backups, selected the snapshot from the previous evening, ran a Full restore, and accepted the brief maintenance window.
The site returned to the previous evening's state.
The operator then re-ran the find-and-replace with a tighter scope, taking a fresh snapshot before the second attempt.
The full cycle — discovery, restore, re-attempt — took under twenty minutes.
Plan for large-site and multi-site backup scenarios
A portfolio of sites raises the operational stakes of backup-and-restore. The mechanics stay the same; the discipline changes.
Large single-site planning
A large site — many gigabytes of media, hundreds of pages, an active commerce surface — needs more thinking about timing.
Manual snapshots taken during the active business window can stretch into several minutes.
Schedule the heavy snapshots during off-peak windows where possible, and reserve mid-day manual snapshots for the lighter pre-change captures.
For a site that runs commerce, take a manual snapshot before every release that touches checkout, before every theme or template change that the customer journey depends on, and before any bulk product import.
The cost of an extra snapshot is small; the cost of a missing snapshot during a checkout incident is the incident.
Pin one snapshot per quarter as a long-horizon reference.
Pinned snapshots survive retention sweeps and give the team a known-good state to compare against months later when the question is "what did this site look like at the start of the year" rather than "what did it look like yesterday."
For sites with large media libraries, plan ahead for the time the snapshot will take.
A library above a few gigabytes will not finish in seconds; build the wait into the team's release schedule rather than fighting against it.
The trade-off is worth it — a heavy site without a recent snapshot is a heavy risk.
Multi-site portfolio planning
For an agency or in-house team running many sites, the portfolio surface in SG-Dashboard is the primary lens. Open SG-Dashboard → Site Manager → Backups to see snapshots across every site in one view. Use the filters to confirm that every site has a recent successful snapshot and that no site is sitting on a stale or failed schedule.
Pick a portfolio cadence and write it down. A typical agency cadence — daily scheduled snapshots on every site, weekly snapshots pinned for one month, monthly snapshots pinned for one year. Document the cadence in the team's internal runbook and audit against it once per quarter.
The portfolio cadence is also the right place to note exceptions.
A site that needs a different cadence — more frequent for a busy commerce flagship, less frequent for a low-change archival site — gets the exception noted in the same runbook.
A documented exception is a controlled exception; an undocumented one becomes drift.
Per-site retention tuning matters at scale. A high-traffic flagship site may justify a longer retention window than a small landing-page site. The portfolio bill carries snapshot storage as a line item; the team that tunes retention to actual recovery needs pays less in storage and still keeps the coverage they need.
Restore drills
A backup that has never been restored is a hypothesis, not a guarantee. Schedule a restore drill once per quarter. Pick one site, take a manual snapshot, change something visible, run a partial restore, confirm the change reverted. Document the drill in the team's runbook. The first drill always finds at least one assumption that does not match reality; the second drill is faster; by the fourth drill the team has muscle memory.
A formal drill also produces a record the team can hand to a compliance reviewer when the question is "how do you verify your recovery process works in practice." The Audit Log captures every drill action, so the evidence is built-in.
Reference — backup index row shape
A row in the index carries a fixed set of fields. The reference below shows a populated row from an SGEN site, captured during a pre-template-swap snapshot.
| Field | Example value |
|---|---|
| Snapshot ID | snap_2026_05_22_sgen_a7f1 |
| Label | before template swap 2026-05-22 |
| Source | Manual |
| Triggered by | ada@yourteam.com |
| Started at | 2026-05-22 14:03 UTC |
| Completed at | 2026-05-22 14:04 UTC |
| Duration | 1 min 18 s |
| Size | 412 MB |
| Captured surfaces | Pages, Posts, Media references, Settings, Modules |
| Status | Ready |
| Verified | Yes (2026-05-22 14:06 UTC) |
| Pinned | No |
| Restored from | (not yet used) |
Reference — populated label conventions
A practical label is the difference between a fast recovery and a slow one. The table below captures the conventions a small ops team has used across several months.
| Trigger | Label pattern | Example |
|---|---|---|
| Pre-change snapshot (template swap) | before | before template swap 2026-05-22 |
| Pre-change snapshot (bulk content edit) | pre | pre bulk meta-description fix 2026-05-22 |
| Migration milestone | | clean baseline after migration |
| Quarterly pinned reference | | Q2 2026 pinned reference |
| Pre-release commerce gate | pre | pre spring-launch checkout safe |
| Incident-response capture | incident | incident INC-1184 capture |
| Drill snapshot | drill | drill 2026-04-29 |
test, backup, snapshot, new, or a bare date — the index already shows the date and the snapshot type. A label that does not add information is a label that wastes the operator's time at recovery.Reference — retention rules on a typical plan tier
Retention windows vary by plan. The matrix below captures the platform baseline that most plans run on the standard plan.
| Snapshot type | Default kept | Adjustable up to | Adjustable down to |
|---|---|---|---|
| Daily (rolling) | 7 days | 30 days | 3 days |
| Weekly | 4 weeks | 12 weeks | 2 weeks |
| Monthly | 6 months | 24 months | 3 months |
| Pinned (any source) | Forever (until manual unpin) | n/a | n/a |
| Manual (unpinned) | Counts toward daily window | n/a | n/a |
Reference — restore scope mapping
Partial restore brings four togglable scope surfaces. The mapping below shows what each scope rolls back and what it leaves alone.
| Scope toggle | Brings back | Leaves untouched |
|---|---|---|
| Pages | Every page that existed at the snapshot, body content, metadata, page settings | Posts, media files themselves, site-wide settings |
| Posts | Every post and its taxonomies | Pages, media files, settings |
| Media references | The catalog of media items each page or post references | Actual binary media (kept across snapshots; not pruned by restore) |
| Settings | Site-wide settings, module configuration, integrations setup at the snapshot time | Content (pages/posts), media references |
Reference — snapshot lifecycle states
A snapshot moves through a small set of states from creation to expiry.
Running -> Ready -> Verified (optional)|+-> Restored from (when used as a restore source)+-> Pinned (operator action — exempts from retention)+-> Expired (retention sweep removes)A snapshot in Running state cannot be restored from yet — wait for Ready. A snapshot in Verification failed state can still be restored from, but the result is suspect; resolve the verification flag first if possible.
Common questions about backup-and-restore
How long are backup files kept?
The default retention is the platform baseline for the active plan — daily snapshots for seven days, weekly for four weeks, monthly for six months on most plans.
Each plan tier extends or contracts this window.
Check SG-Dashboard for the exact ceiling on the current plan, and tune within that ceiling on the Retention panel.
Does a backup capture media files?
Yes.
A snapshot captures every customer-uploaded media reference for the site.
The platform stores media efficiently across snapshots so the storage footprint stays proportional to net change, not to the full media library size on every snapshot.
Can I restore one page without affecting the rest of the site?
Partial restore goes as narrow as the Pages surface, which rolls back every page captured in the snapshot.
For a single-page rollback, use the per-page revision history inside the admin Pages — that surface keeps a finer record of edits and supports per-page rollback without touching neighbors.
What happens if a restore runs while a team member is editing a page?
The team member's unsaved edits are lost.
Restore replaces live state for the site.
Coordinate restores with the team: post a short notice in the team channel, wait for acknowledgement, then run.
The Audit Log records the operator who ran the restore and the note they entered; the team can review afterward.
Is the site live during a restore?
The site enters a brief maintenance state for the duration of the restore.
Visitors see a short maintenance page; commerce checkouts in flight at the moment of the restore may be interrupted.
For commerce sites with active traffic, time the restore for an off-peak window where possible, and notify the team before triggering.
Can I download the snapshot file?
The snapshot is held within the platform and is not directly downloadable as a file in the customer surface.
For a portable copy, use the site Export workflow — it produces a .sgen archive that can be downloaded and re-imported into the same or another SGEN site.
Can I share a snapshot with a teammate who is not a site admin?
Snapshots themselves are visible only to admin-level users on the site.
For sharing the recovery decision with non-admin teammates, use the Audit Log entry ID for the snapshot — that ID is safe to share in the team's channels, and admins can jump straight to the entry from the ID.
Does a restore reset user passwords or sign-in sessions?
No.
Restore covers content and configuration captured at the snapshot timestamp.
User accounts, sign-in sessions, 2FA setup, and SSO configuration live in their own surfaces and are not affected by a content restore.