Backing Up Your Data in Science Cloud
⚠️ 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.
...
Read this first
These are not backups
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.
Two terms used throughout this page
- RPO (Recovery Point Objective) — how much data you can afford to lose, measured in time. Backing up nightly means an RPO of 24 hours: a failure at 4pm loses everything since last night.
- RTO (Recovery Time Objective) — how long you can afford to be down while restoring. Restoring from Glacier Deep Archive can take 12+ hours before you can even begin.
Decide these two numbers before you pick an option below. Every choice on this page is a trade between RPO, RTO, and cost.
...
Before you start: check your access
What you can set up depends on which role you select when you sign in through IAM Identity Center.
Project Admin
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.
Project Power User
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.
...
- Enable S3 Versioning, Lifecycle rules, and Object Lock on your buckets
- Take manual EBS and RDS snapshots
- Confirm your RDS backup retention period is set correctly
- Run scripted backups to S3 from an instance that already has an instance profile attached
Custom project roles
Some projects define their own roles. If yours does, try creating a backup plan — if it fails on permissions, ask your Project Admin.
...
Choosing an approach
| 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.
...
Option A: AWS Backup
A single, policy-driven service that backs up EBS, EC2, S3, RDS, and EFS on a schedule you define.
...
To get started: AWS Backup console → Backup plans → Create backup plan → start from a template, then Assign resources.
...
Option B: Per-service native tools
Use these when you want finer control, lower cost, or only have one resource type to protect.
EBS and EC2
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.
...
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.
S3
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.
...
Lifecycle rules move objects to cheaper storage classes on a schedule. See Cost for the tier trade-offs.
RDS
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.
...
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
⚠️ 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.
...
Option C: Scripted backups to S3
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.
...
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.
...
Choosing a retention schedule
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.
...
Cost
You pay for backup storage on your own account bill. The main drivers:
...
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.
...
Use AWS Cost Explorer, filtered to the Backup, S3, and EBS services, to see what your backups actually cost once running.
...
Optional: Cross-Region copy
AWS Backup and S3 Replication can both copy data to a second AWS Region. This protects against the loss of an entire Region.
...
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.
...
Restoring
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.
...
- Restoring an EBS snapshot creates a new volume; you must attach and mount it yourself.
- Restoring an RDS snapshot creates a new instance with a new endpoint. Applications will need to be repointed.
- Restoring encrypted backups requires the KMS key. If the key is deleted, the backup is permanently unreadable — this is not recoverable by AWS or by anyone else.
- Cross-account restores require the vault and the KMS key to be shared in advance.
...
Summary of responsibility
To restate the point at the top of this page, because it is the one that matters:
...