⚠️ Backup and restore are entirely your responsibility.
The Science Cloud Team does not back up your infrastructure or your data. No backup of any resource in your account exists unless someone in your account has explicitly configured one.
We do not monitor whether your backups exist, whether they succeed, or whether they are recoverable. We will not restore data on your behalf.
If data in your account is deleted, corrupted, or lost — through error, a failed process, or a compromised credential — it is unrecoverable unless you have already configured and tested a backup yourself.
This page explains your options so you can choose and configure one.
People lose data because they assume one of these is protecting them. None of them is.
| Feature | What it actually protects against | What it does not protect against |
|---|---|---|
| Multi-AZ / High Availability | Hardware or Availability Zone failure | Deleting, overwriting, or corrupting your data — the damage replicates instantly |
| EBS RAID | Individual disk failure | Everything else, including accidental deletion |
| S3 Versioning (alone) | Overwriting or deleting an object | Deleting the bucket, or a credential compromise that deletes versions |
| S3 Replication | Losing a Region or a bucket becoming unavailable | Deletion or corruption — those replicate too |
| Snapshots you took once, manually | The state of the volume on that one day | Everything that changed since |
A backup is a separate copy, taken on a schedule, that you have tested restoring. If it fails any of those three tests, treat it as not existing.
Decide these two numbers before you pick an option below. Every choice on this page is a trade between RPO, RTO, and cost.
What you can set up depends on which role you select when you sign in through IAM Identity Center.
You can configure everything on this page yourself. The first time you create a backup plan in the AWS Backup console, AWS sets up the service role it needs automatically — there is nothing to prepare in advance.
AWS Backup is not available to you. Your role does not include the permissions the service requires, and the failure appears partway through creating a plan rather than up front.
Ask your Project Admin to set up backup plans for your project's resources. This is a request within your own project — not a request to the Science Cloud Team.
You can still do the following yourself, and all of them are worthwhile:
Some projects define their own roles. If yours does, try creating a backup plan — if it fails on permissions, ask your Project Admin.
| Resource | Option | Best achievable RPO | Effort | Relative cost |
|---|---|---|---|---|
| EBS / EC2 | AWS Backup | Hourly | Low | Medium |
| Data Lifecycle Manager | Hourly | Low | Low | |
| Manual snapshots | Whenever you remember | Very low | Lowest | |
| S3 | Versioning + Lifecycle | Immediate (per object) | Very low | Low |
| Versioning + Object Lock | Immediate | Medium | Low | |
| Replication to another bucket | Minutes | Medium | Medium (duplicate storage) | |
| AWS Backup | Continuous or scheduled | Low | Medium | |
| RDS | Automated backups (default) | ~5 minutes (PITR) | None — on by default | Low |
| Manual snapshots | Whenever you take one | Very low | Low | |
| AWS Backup | Per schedule | Low | Medium | |
| EFS | AWS Backup | Hourly | Low | Medium |
| (no native snapshot exists) | — | — | — | |
| Any | Scripted copy to S3 | Whatever you schedule | High | Lowest |
If you want one answer rather than a menu: use AWS Backup. It covers all four resource types with one configuration, and it is the only backup mechanism available for EFS.
A single, policy-driven service that backs up EBS, EC2, S3, RDS, and EFS on a schedule you define.
How it works: you create a backup plan (schedule + retention), then assign resources to it either by listing them explicitly or by tag — for example, everything tagged Backup=Daily. Tag-based assignment means new resources are protected automatically as you create them, which is its main advantage over per-service tooling.
Worth using because:
Trade-offs:
To get started: AWS Backup console → Backup plans → Create backup plan → start from a template, then Assign resources.
Use these when you want finer control, lower cost, or only have one resource type to protect.
EBS snapshots are incremental — the first captures the whole volume, subsequent ones store only changed blocks, so you are billed far less than the volume size after the first. Restoring creates a new volume.
Data Lifecycle Manager (DLM) schedules and expires snapshots automatically. DLM itself is free; you pay only for snapshot storage. This is the cheapest way to get scheduled EBS backups. Note that DLM requires an IAM role.
AMIs capture the instance and all attached volumes and the launch configuration. If your goal is "get this whole machine back," an AMI restores faster and more completely than reassembling volumes from snapshots.
For long-term retention, the EBS Snapshot Archive tier is significantly cheaper, with a 90-day minimum storage commitment and a restore time of up to 72 hours.
Snapshots capture the disk, not your application. A snapshot of a running database volume may be crash-inconsistent. Stop the service, flush to disk, or use the database's own backup mechanism instead.
Versioning keeps every version of every object, including a delete marker instead of an actual deletion. Enable this on any bucket holding data you care about — it is the single highest-value, lowest-effort protection on this page.
⚠️ Versioning is not sufficient on its own. It does not protect against the bucket being deleted, and it does not stop anyone holding valid credentials from permanently deleting the versions themselves. If your protection story is "we have versioning enabled," you are protected against your own typos and nothing else.
Object Lock makes objects immutable (WORM) for a fixed period or indefinitely. Requires Versioning. In Compliance mode, nobody can delete the object before its retention expires — including the account root user. Object Lock is normally enabled when the bucket is created; enabling it on an existing bucket may require contacting AWS Support.
Replication (same-Region or cross-Region) copies objects to a second bucket, optionally in another account. Requires Versioning on both buckets and an IAM role. By default it only replicates objects created after you enable it — use Batch Replication for existing objects.
Lifecycle rules move objects to cheaper storage classes on a schedule. See Cost for the tier trade-offs.
Automated backups are enabled by default and give you point-in-time recovery to roughly any 5-minute window within your retention period. The retention period is configurable up to 35 days. Check yours — if it is set to 0, automated backups and PITR are disabled entirely.
⚠️ Deleting a DB instance deletes its automated backups. You can avoid this by selecting Retain automated backups at delete time — but retained backups still expire on the original schedule and disappear once the last system snapshot ages out. They are a grace period, not permanent storage.
Manual snapshots and final snapshots are independent and persist until you delete them. If a database matters, take a manual snapshot before any destructive operation, and always take a final snapshot when deleting an instance.
Manual snapshots never expire on their own. They are the right tool for "keep this state indefinitely" — end of a study, before a schema migration, before a version upgrade.
A logical dump (pg_dump, mysqldump) written to S3 is worth having alongside snapshots. Snapshots restore only into RDS of a compatible engine version; a dump can be restored anywhere, including outside AWS.
⚠️ EFS has no native snapshot feature. If you are not using AWS Backup, your EFS file system has no backups.
EFS Replication copies a file system to another Region continuously. This is a disaster-recovery feature, not a backup — deletions and corruption replicate, and there is no point-in-time recovery. Do not use it as your only protection.
Copying data to S3 yourself with a scheduled job. Unglamorous, cheapest, and appropriate when your dataset is small, your instances are ephemeral, or you want backups readable outside AWS.
Common tools:
restic — deduplicating, encrypted, incremental, with an S3 backend. Good default.rclone — straightforward sync to S3. Simple, but a sync will happily propagate your deletions unless you use versioning on the destination.pg_dump / mysqldump piped to S3 — for databases outside RDS.aws s3 sync — fine for a one-directional copy of static files.What you are taking on: scheduling (cron or systemd timer), credentials (use an instance profile — never long-lived access keys on an instance), monitoring that the job actually ran, and expiring old backups. A backup script that has been silently failing for four months is the most common way this option goes wrong. Alert on absence of success, not on failure.
If your compute is ephemeral, this is your only option. Anything stored on an instance you can terminate and recreate — including notebook working directories and local scratch space — is gone when that instance goes. Keep the data you care about in S3 or EFS, not on the instance.
There is no mandated minimum retention in Science Cloud — it is your decision. If you have no specific requirement, these are reasonable starting points.
| Data type | Suggested schedule | Rationale |
|---|---|---|
| Active working data | 7 daily, 4 weekly | Covers the common case: you notice a mistake within a week |
| Production databases | 7 daily, 4 weekly, 12 monthly | Some corruption is only noticed at quarter or year boundaries |
| Reference / published datasets | 1 monthly + Object Lock | Rarely changes; the risk is deletion, not corruption |
| Rebuildable infrastructure | None — use infrastructure-as-code | Backing up a server you can recreate from a template is wasted money |
The mistake to avoid is uniform retention. Backing up everything for a year is expensive; backing up everything for a week will eventually not be enough. Split by how long it would plausibly take you to notice a problem.
You pay for backup storage on your own account bill. The main drivers:
Snapshots are incremental. After the first, you pay only for changed blocks — so 30 daily snapshots of a mostly-static 500 GB volume cost far less than 15 TB. Volumes with high daily churn cost proportionally more.
Deleting a snapshot may not free what you expect. Because snapshots share blocks, deleting one only frees blocks no other snapshot needs.
Archive tiers have minimum storage durations. You are billed for the minimum even if you delete early:
| Storage class | Minimum duration | Retrieval time |
|---|---|---|
| S3 Standard-IA / One Zone-IA | 30 days | Immediate |
| S3 Glacier Instant Retrieval | 90 days | Immediate |
| S3 Glacier Flexible Retrieval | 90 days | Minutes to 12 hours |
| S3 Glacier Deep Archive | 180 days | 12–48 hours |
| EBS Snapshot Archive | 90 days | Up to 72 hours |
Retrieval from archive tiers costs money and takes time. Deep Archive is the cheapest storage and the worst possible choice for anything you might need urgently. Match the tier to your RTO, not to your storage budget.
Small objects transitioned to archive tiers can cost more, not less. Each transition carries a per-object request charge and archive classes add per-object overhead. Do not apply a Glacier lifecycle rule to a bucket of millions of tiny files without doing the arithmetic first.
Use AWS Cost Explorer, filtered to the Backup, S3, and EBS services, to see what your backups actually cost once running.
AWS Backup and S3 Replication can both copy data to a second AWS Region. This protects against the loss of an entire Region.
This is a disaster-recovery measure, and for most workloads it is optional. A Region-wide, data-destroying failure is far rarer than the accidental deletions and corruptions that in-Region backups already cover. Get in-Region backup working first.
Consider it if: the data is irreplaceable, your work has an availability commitment that survives a Region outage, or you need geographic separation for another reason.
What it costs: you pay for the duplicate storage in full, plus cross-Region data transfer for every byte copied. This roughly doubles your backup storage bill and is not incremental in the way in-Region snapshots are.
Your backups are not backups until you have restored one. Untested backups fail at restore time for ordinary reasons: the snapshot was crash-inconsistent, the retention expired earlier than you thought, the job had been failing silently, the KMS key was deleted, or nobody had permission to run the restore.
Test at least once, and again after any significant change:
Practical notes:
To restate the point at the top of this page, because it is the one that matters:
Backup and restore of your infrastructure and data in Science Cloud are entirely your responsibility.
The Science Cloud Team does not configure, schedule, monitor, verify, or restore backups for your account. Nothing on this page happens automatically. If you have read this far and taken no action, you have no backups.
The minimum reasonable step, which takes a few minutes: