How to back up an Oracle Cloud (OCI) compute instance

What OCI gives you

OCI backs up volumes, not instances. The boot volume holds the OS and everything installed on it; block volumes are extra disks. Backups are encrypted, kept in Oracle's Object Storage in the same region, and restore to a new volume in any availability domain there.

A backup of a running instance is crash-consistent: the disk as it would be after "a loss of power or hard crash", in Oracle's words. Databases recover from it as after a power cut, so keep dumps as well; snapshots versus backups explains why.

Incremental, full, and what you pay

A backup is incremental (only blocks changed since the last one, the default) or full. Oracle says there is no difference when you restore: any backup brings back the whole volume as it was at that moment, alone, with no chain to apply in order. The difference is size. Oracle's example: a 50 GB volume with 25 GB written gives a 25 GB full backup. The next day 2 GB changes and 3 GB is added, so the incremental is 5 GB. When the full backup expires, that incremental grows to 28 GB, because it must now hold everything needed for its day.

Backups are billed at the Object Storage rate, $0.0255 per GB a month on pay-as-you-go above the free tier, as of October 2026. Every block the OS has ever written counts, plus up to 1 GB of metadata, so a backup can outgrow the files on the disk.

Bronze, Silver and Gold policies

Assign a backup policy and OCI takes the backups for you. Oracle defines three, which you cannot change. Since November 2021 they take only incremental backups:

Scheduled backups can start several hours late when the system is busy, and a policy takes at most one backup a day per volume. Policy backups always expire; for a copy you want to keep, take a manual backup. A volume has one policy at a time, and assigning another silently replaces it. In the Console, go to Storage > Block Volumes (boot volumes are under Boot Volumes in the sidebar), open the volume, choose Edit and pick a policy under Backup Policies. From the CLI, list the Oracle-defined policies (no compartment given), then assign one:

oci bv volume-backup-policy list --query 'data[].[id, "display-name"]' --output table

oci bv volume-backup-policy-assignment create --asset-id <boot-volume-ocid> --policy-id <policy-ocid>

The CLI prints field names with hyphens, which is why --query quotes them.

Always Free: five backups, so plan them

Always Free resources live in the tenancy's home region. As of October 2026, Oracle lists two VM.Standard.E2.1.Micro instances; Ampere A1 capacity of 1,500 OCPU hours and 9,000 GB hours a month, which it equates to 2 OCPUs and 12 GB of memory; 200 GB of block storage shared by boot and block volumes; five volume backups, boot and block combined; 20 GB of Object Storage; and 10 TB of outbound data a month.

Five is the limit that matters. With five backups in place, Oracle's page says creating another "will fail with an error" until you delete one. Every Oracle-defined policy outgrows five: Gold within a week, Silver within weeks, Bronze within months. Instead, create your own policy with one daily backup kept for three days. Save this as daily-3d.json:

[
  {
    "backupType": "INCREMENTAL",
    "period": "ONE_DAY",
    "offsetType": "STRUCTURED",
    "hourOfDay": 3,
    "timeZone": "UTC",
    "retentionSeconds": 259200
  }
]

oci bv volume-backup-policy create --compartment-id <compartment-ocid> --display-name daily-3d --schedules file://daily-3d.json

STRUCTURED makes hourOfDay the start time, 03:00 UTC; 259200 seconds is three days. Three backups, or four while a late one overlaps, leave a slot for a manual backup before a risky change. Assign the policy as above. On a paid account, backups beyond the free five are billed.

Take a backup by hand

Before an upgrade, take a manual backup: open the boot volume in the Console, select Backups, then Create Boot Volume Backup. Without a retention period, it is kept until you delete it.

Or use the OCI CLI. Cloud Shell, opened from the Console, comes with it installed and signed in; elsewhere, install it and run oci setup config. Find the instance's boot volume; the availability domain and compartment are on the instance's page:

oci compute boot-volume-attachment list --availability-domain <ad-name> --compartment-id <compartment-ocid> --instance-id <instance-ocid> --query 'data[0]."boot-volume-id"' --raw-output

oci bv boot-volume-backup create --boot-volume-id <boot-volume-ocid> --display-name before-upgrade --wait-for-state AVAILABLE --max-wait-seconds 7200

--type defaults to INCREMENTAL. The CLI waits 1200 seconds by default and exits with code 2 when time runs out; Oracle says backups can take hours at busy times, hence --max-wait-seconds. Writing to the disk is safe again once the state moves from REQUEST_RECEIVED to CREATING. For a block volume, run oci bv backup create --volume-id <volume-ocid>. List a boot volume's backups:

oci bv boot-volume-backup list --compartment-id <compartment-ocid> --boot-volume-id <boot-volume-ocid> --query 'data[].[id, "display-name", "time-created", "source-type", "lifecycle-state"]' --output table

source-type is MANUAL or SCHEDULED. To copy a backup to another region, choose Copy to Another Region from its Actions menu or run oci bv boot-volume-backup copy --boot-volume-backup-id <backup-ocid> --destination-region us-ashburn-1; a user-defined policy can copy every scheduled backup automatically. You pay for storage in both regions plus outbound transfer, only boot volumes from platform images (or custom images built from them) can be copied, and Always Free backups exist only in the home region.

Restore a backup to a new instance

A restore never overwrites the original: it creates a new boot volume, and you boot a new instance from it, in the same availability domain. In the Console: Boot Volume Backups, the backup's Actions menu, Restore Boot Volume. From the CLI:

oci bv boot-volume create --boot-volume-backup-id <backup-ocid> --availability-domain <ad-name> --display-name web1-restored --wait-for-state AVAILABLE

oci compute instance launch --availability-domain <ad-name> --compartment-id <compartment-ocid> --subnet-id <subnet-ocid> --shape VM.Standard.A1.Flex --shape-config '{"ocpus": 1, "memoryInGBs": 6}' --source-boot-volume-id <new-boot-volume-ocid> --assign-public-ip true --display-name web1-restored

--availability-domain is required when restoring from a backup. The new instance gets new IP addresses, so update DNS. For a block volume, oci bv volume create --volume-backup-id <backup-ocid> --availability-domain <ad-name> makes a new volume to attach. To get a few files back without replacing the server, attach the restored boot volume to a running instance as a data volume and copy them off.

Why Oracle's copies are not enough

• One account holds everything. Oracle's Free Tier FAQ says accounts left idle for 30 days or more may be deemed abandoned and become eligible for suspension or termination, and that paid resources reclaimed when a Free Trial ends are permanently deleted. A lost login or a leaked API key reaches the instance and its backups together.
• Idle Always Free instances may be reclaimed. Oracle counts an instance as idle if, over 7 days, its 95th-percentile CPU use, network use and (on A1) memory use all stay under 20%, which describes many quiet personal servers. Its page does not say whether reclaimed means stopped or deleted.
• A1 over the limit. If a tenancy holds more A1 capacity than Always Free allows when its trial ends, the FAQ says all its A1 instances are disabled and then deleted after 30 days unless it upgrades.
• Whole volumes, one region. Backups stay in the region unless you copy them, and getting one file back means restoring a whole volume.

The 3-2-1 rule asks for one copy off-site. Here that means another company, in an account Oracle cannot close.

Add a copy outside Oracle

Back up the data, not the disk: /etc, site and app files, crontabs and each database as a dump; the server backup checklist has the full list. Set up restic as in the restic guide, with a root-only /etc/restic/env and password file and the repository in a bucket at another company, for example Backblaze B2, then run restic init once. A1 instances are Arm, so install the linux_arm64 build; --stdin-from-command needs restic 0.17 or newer, and stores the dump without writing it to disk (a failed pg_dump creates no snapshot). For MySQL or MariaDB, put mysqldump --single-transaction --routines --events app after the --, as in the mysqldump guide.

RESTIC_REPOSITORY=s3:https://s3.us-west-004.backblazeb2.com/my-backups/oci-web1
RESTIC_PASSWORD_FILE=/etc/restic/password
RESTIC_CACHE_DIR=/var/cache/restic
AWS_ACCESS_KEY_ID=your-key-id
AWS_SECRET_ACCESS_KEY=your-application-key

#!/usr/bin/env bash
# Nightly backup of an OCI instance to a bucket at another provider.
set -euo pipefail
set -a; . /etc/restic/env; set +a

# 1. The database, streamed into restic. A failed dump creates no snapshot.
restic backup --tag db --stdin-filename app.sql --stdin-from-command -- sudo -u postgres pg_dump app

# 2. Files. --one-file-system stays on the filesystem of each directory listed.
restic backup --tag files --one-file-system --exclude-caches /etc /var/www /home /root /var/spool/cron

# 3. Keep 7 daily, 4 weekly and 6 monthly snapshots of each; delete the rest.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

sudo chmod 700 /usr/local/bin/offsite-backup.sh

30 2 * * * root /usr/local/bin/offsite-backup.sh >> /var/log/offsite-backup.log 2>&1

Or pull instead: a server at another provider copies the data over SSH with rsync and a dedicated SSH key, so the Oracle instance holds no keys to your backup storage. Keep the restic password and bucket keys in a password manager too.

Restore onto a new server, and test it

Create a server with the same OS release, at Oracle or anywhere else, install restic and put back /etc/restic/env and the password file. Then, in a root shell with the file loaded (set -a; . /etc/restic/env; set +a):

restic restore latest --tag files --target /srv/restore

sudo -u postgres createdb app

restic dump --path /app.sql latest app.sql | sudo -u postgres psql -v ON_ERROR_STOP=1 -d app

Files and SQL dumps restore on any CPU, so an Arm A1 backup comes back on an x86 server elsewhere; programs compiled or Docker images built only for arm64 do not. Copy directories such as /etc/nginx from /srv/restore/etc, never all of /etc. Restoring a server from backup has the full sequence.

• Have OCI email you when a backup fails: Oracle's docs show an Events rule on the backup's end event with the status operationFailed.
• Read the restic log for a week, then add an alert as in backup failure alerts.
• Once a month, restore both: an OCI backup to a new instance, and the restic copy to a throwaway server elsewhere. Open the site and time it, as in testing a restore. Then terminate the test instance and delete its boot volume, so it stops using your allowance.

Frequently asked questions

Does Oracle Cloud back up my instance automatically?

No. Nothing is backed up until you take a manual backup or assign a backup policy (Bronze, Silver, Gold or your own) to the boot volume and any block volumes.

How many backups does Oracle Cloud Always Free include?

Five volume backups in the home region, boot and block combined, alongside 200 GB of block storage. On an Always Free account, a sixth fails until you delete one.

What is the difference between Bronze, Silver and Gold?

Bronze takes monthly backups kept 12 months and a yearly one kept 5 years. Silver adds weekly backups kept 4 weeks. Gold adds daily backups kept 7 days. All are incremental and cannot be changed.

Can I restore an OCI backup in another region?

Copy it there first, with Copy to Another Region or oci bv boot-volume-backup copy, then restore it in that region. Always Free backups exist only in the home region.

Will Oracle reclaim my Always Free instance?

It may, if the instance is idle: under 20% CPU (95th percentile), network and, on A1, memory use over 7 days. Keep a copy of your data outside Oracle.