SGEN backups and disaster recovery

How to plan for backup and recovery with SGEN

Backups are the safety net for when something goes wrong despite your best efforts. SGEN takes backups automatically and gives you tools to restore from them. This page explains the backup model, the restore process, and how to plan for the recovery scenarios that matter most.

The plain version: every SGEN site is backed up regularly. You can restore from a backup point with a few clicks. Backups are encrypted, retained for a configurable window, and tested by the platform team.

This guide also covers the human side of recovery — how to decide when to restore, how to communicate during a recovery moment, and how to verify recovery worked correctly. The technical tools are most of the work; the operational discipline matters too.

What is this for?

Customers ask several backup questions:

• How often does SGEN back up my site? What is the cadence?
• How long are backups kept? Retention window.
• What is included in a backup? Content, design, settings, media — what is in scope?
• How do I restore from a backup? Process.
• Can I restore just a piece (one page, one form) without rolling everything back? Granularity.
• What if I accidentally delete something important? Recovery for human errors.
• What about ransomware or major data loss? Worst-case scenarios.

The right answers depend on your business. A blog with rarely-changing content needs different backup planning than an active ecommerce site. A site with regulatory compliance needs documented restore procedures.

The platform handles the technical backup work. Your role is mostly to know when backups exist, what they cover, and how to use them when needed. Test the restore process at least once before you need it — recovery practiced under stress goes worse than recovery practiced calmly.

Backups also intersect with content discipline. A team that publishes carefully and reviews changes before merging needs backups less often than a team that publishes frequently with less review. Both teams benefit from backups; one team uses them more.

Good use cases

What NOT to use this for

How this connects to other features

Before you start

A short checklist:

• Know your backup retention window. Per-plan-tier; check yours.
• Know your backup cadence. Automatic backups run on a schedule — typically daily for most plans.
• Bookmark the backup management page. Site → Settings → Backups.
• Test the restore process once. Restore a test backup to a staging site to confirm the process works for you.
• Document the restore procedure for your team. Who initiates restore? Who decides which backup point? Who communicates to stakeholders?
• Decide your own retention strategy. If you need to keep specific points longer than the standard window, plan for manual archiving.
• Plan your communication for a restore. Restoring to a previous point may surprise visitors who saw the newer state. Have a brief message ready.

Where to go

The key locations:

• Site → Settings → Backups. List of available backups, automatic and manual.
• Site → Settings → Backups → Create manual backup. Trigger an immediate backup.
• Site → Settings → Backups → Restore. Initiate a restore from a backup point.
• Site → Settings → Backups → Download. Export a backup file for off-platform storage (if available on your plan).
• Account → Audit Log. Records of all backup and restore actions.

Steps — Set up backups and practice recovery

1. Confirm automatic backups are running

Open Site → Settings → Backups. Confirm you see recent backups in the list — the most recent should be from within the last 24 hours (for daily cadence). If no backups appear, the automatic backup setting may be off; enable it.

2. Set your retention preference

Pick a retention window that matches your needs. For most operators, 30 days is sufficient. Longer windows give more recovery options but use more storage; shorter windows save storage but limit recovery range.

If your plan offers longer retention, consider 90 days for ecommerce sites or sites with regulatory record-keeping needs.

3. Trigger a manual backup before major changes

Before any major change — redesign, migration, large content batch update — trigger a manual backup via Site → Settings → Backups → Create manual backup. Manual backups are kept separate from the automatic rotation and give you an explicit recovery point.

Manual backups also serve as "this was the state before we made the change" archives. Even if you do not restore from them, they document the pre-change state.

4. Test the restore process

Schedule a 30-minute test of the restore process. Pick a recent backup. Restore to a staging environment (most plans support this) or to a non-production site.

Confirm:

• The restore completes within expected time.
• Content matches the backup point.
• Settings and design are restored.
• Form submissions and analytics history are handled as expected.

The test gives you confidence the process works. Most teams discover one or two small surprises during the test — better to find them now than during a real recovery.

5. Document the restore procedure

Write a short procedure for your team:

• Who has authority to initiate a restore.
• How to pick the right backup point (look for the timestamp before the issue).
• How to verify the restore completed correctly.
• How to communicate to stakeholders during and after the restore.
• How to handle in-flight work (form submissions, drafts) that might be lost.

Keep the document with your other operational documentation. Update after each actual restore.

6. Restore from backup when needed

When the moment comes:

• Open Site → Settings → Backups.
• Identify the backup point you want to restore from (timestamp).
• Click Restore.
• Confirm via the confirmation dialog (this is irreversible — be sure).
• The restore runs in the background. The site goes into a brief recovery state during the restore.
• The platform notifies you when restore completes.
• Verify the site is back to the expected state.

Most restores complete in a few minutes. Large sites with extensive media may take longer.

7. Communicate the restore to stakeholders

If the restore affects visible site state, communicate:

• A brief note to your team about what was restored and why.
• If visitor-facing content reverted, a note to any affected visitors (e.g., "we restored an earlier version; if you submitted a form between [time] and [time], please resubmit").
• An update in your team's operations log so future-you remembers what happened.

Restores are operational events. Treat them with the same communication discipline as platform incidents.

8. Run periodic disaster-recovery drills

For mission-critical operations, run a disaster-recovery drill annually or semi-annually:

• Simulate a recovery scenario (data corruption, ransomware, accidental delete).
• Walk through the restore process end-to-end.
• Measure the time taken (your Recovery Time Objective).
• Identify gaps and update the procedure.

The drill catches gaps before they become real problems.

9. Maintain off-platform copies if mission-critical

For sites where platform backups alone are insufficient (regulatory requirements, organizational policy, paranoid prudence), maintain off-platform copies:

• Periodic exports via Site → Settings → Data → Export.
• Stored in your own secure storage (cloud storage, encrypted local drive).
• Tested for restorability — confirm exports can be re-imported.

Off-platform copies protect against scenarios where platform backups themselves are unavailable. Rare scenarios, but planning for them is part of mature operations.

What success looks like

What to do if it does not work

Less-obvious cases:

Worked example — Acme Coffee recovers from a botched migration

In April 2026 Acme Coffee migrated their main site to a new homepage design. The migration introduced a bug that broke the contact form. Visitors were unable to reach Acme. The team discovered the issue four hours after publishing.

The response:

• Decided to restore to the pre-migration state. Four hours of lost work was a worthwhile trade for working contact form.
• Opened Site → Settings → Backups. Selected the automatic backup from the morning, before the migration started.
• Initiated restore. Confirmed the action. Restore completed in 3 minutes.
• Verified the contact form worked. Submitted a test form; received the confirmation email. Working.
• Communicated to the team. "We rolled back this morning's migration. Re-doing it tomorrow with fixes."
• Communicated to visitors. Sent a brief email to anyone who may have tried to submit during the broken window: "Our contact form had a brief issue today; please resubmit if you tried to reach us."
• Documented in the team's operations log. Date, time, what happened, what was restored, what was learned.

The next day the team re-did the migration with the form bug fixed. The lost four hours was annoying but recoverable. The restore process worked exactly as documented.

Worked example — Acme Studio runs an annual DR drill

Acme Studio runs annual disaster-recovery drills across client sites. The most recent drill:

• Picked a client site for the drill. Pre-coordinated with the client.
• Triggered a manual backup as the drill baseline. Confirmed it landed.
• Simulated a disaster scenario. Pretend a major content corruption occurred.
• Initiated restore from a 7-day-old backup. Confirmed the team could find the right backup point.
• Measured the time from "issue detected" to "site restored." 12 minutes.
• Verified content, design, settings, and form submissions matched the backup point.
• Documented the drill results. Time taken, gaps identified, action items.
• Updated the client's recovery procedure with two small refinements found during the drill.

The drill caught a small issue: the team's recovery procedure did not mention the post-restore notification step. The procedure was updated. The next drill (a year later) will include the notification step.

Notes on the backup model

A few details worth knowing:

Backups are automatic and continuous. Once set up, you do not manage the cadence. The platform handles it.

Backups are encrypted at rest. Backup data follows the same encryption standards as live data.

Retention is per-plan-tier. Higher tiers typically include longer retention windows. Check your plan.

Restore is irreversible. Once you restore from a backup point, the site is at that state. You cannot un-restore. Use the manual backup option to capture a pre-restore state if you need a fallback.

Restores can take longer for large sites. Most complete in minutes; sites with extensive media may take longer. Plan accordingly.

Some plan tiers include cross-site backup management. Bulk backup actions across a portfolio. Useful for agencies and multi-site operators.

Backups respect deletion. Permanently deleted data is removed from backups according to the platform's deletion policy. The deletion completes when all backups containing the data have rolled off.

Restores log in the audit trail. Who initiated the restore, when, which backup point — all recorded.

Common questions

How often does SGEN back up my site? Automatically — typically daily. Some plans support more frequent backups.

How long are backups kept? Plan-dependent. Common retention windows are 7, 30, or 90 days. Check your plan.

Can I download a backup file? On many plans, yes. Site → Settings → Backups → Download. Store off-platform if mission-critical.

Can I restore just one page? Page-level revision history (if available on your plan) supports per-page rollback. Full backups are site-level.

Will restore reset my analytics? No. Analytics history is preserved across content restores.

Will restore reset my form submissions? Form submissions are part of backups. Restoring reverts the submission state to the backup point. Submissions made after the backup point are not in the restored state.

Can I schedule a backup before a specific event? Yes — use the manual backup option immediately before the event.

What if my plan does not include backups? All plans include some level of backup. Higher plans include more retention and more controls.

How long does a restore take? Most complete in minutes. Large sites may take longer.

Can I test a restore to a separate site? Some plans support restore-to-staging. Check your plan's features.

Are backups included in cross-site reporting? Backup status is one of the site-level signals visible in some cross-site views.

What happens to backups when I delete a site? Backups roll off according to the standard retention policy. Permanent deletion includes backup removal.

Can I get a copy of a backup for legal hold? Discuss with support and your legal team. Legal holds are usually handled outside the standard backup tooling.

Is backup data encrypted at rest? Yes. Backup data follows the same encryption standards as live data.

Related reading

Backups are the quiet insurance policy. Set them up correctly once, test the restore process once, and trust the system to handle most recovery needs. For mission-critical operations, layer in off-platform copies and disaster-recovery drills. The combination covers the recovery scenarios that actually happen in practice.