Ceph Backup Strategies

Ceph has built-in replication, but replication is not a backup — it copies your mistakes to every replica just as faithfully as your data. The strategy you use to back Ceph up depends less on Ceph itself and more on what runs in front of it.

Ceph has become the default storage substrate for scalable private clouds — serving Cinder volumes in OpenStack, disks in plain libvirt KVM, and file or object storage through CephFS and RGW. This article covers the three strategies Storware Backup and Recovery uses to protect it.

The three Ceph backup strategies

Which one applies comes down to two questions: does a virtualization platform sit in front of Ceph, and are you protecting block volumes (RBD) or a file/object interface (CephFS, RGW)?

• Disk attachment — for Ceph RBD behind a hypervisor such as OpenStack.
• Independent Ceph RBD storage provider — for RBD volumes with no virtualization layer.
• OS Agent — for CephFS (and RGW mounted as a file system) at file level.

1. Disk attachment

When Ceph RBD backs a virtual environment such as OpenStack, the disk-attachment method uses a proxy VM. The backup process asks the platform to snapshot the source volume, create a volume from that snapshot, and attach it to the proxy. The proxy reads data directly from the attached volume — with no in-guest agents.

Incrementals are where Ceph comes into play. Here, communication with the Ceph monitors is used only to collect changed-block information for the incremental — the snapshot difference between the previous snapshot and the one taken for the current session. You still just list the changed blocks; the data itself is read from the attached volume, now that you know which blocks matter. Because of this, the method supports incrementals regardless of the underlying storage backend, and at scale it can bypass native OpenStack backup quota limits. Multi-Ceph and multi-AZ layouts are handled by assigning a storage provider per availability zone.

Reference: OpenStack backup — Storware documentation

2. Independent Ceph RBD storage provider

Ceph is often used with no virtualization layer at all — or in a platform combination a data-protection tool does not otherwise cover. For those cases, the storage provider protects RBD volumes the same way Storware protects VMs or applications.

You supply the Ceph keyring and configuration file; the provider detects the pools and volumes and lets you assign policy-driven backups (which can be scheduled), writing to virtually any destination — file system, object storage, or an enterprise backup platform. Under the hood, Storware uses the RBD-NBD approach to mount a remote RBD snapshot over NBD and read the data directly from the cluster; incrementals read only the changed blocks via snapshot difference. This path needs no proxy VM and no in-guest agent, which makes it genuinely agentless. Recovery is simpler here too, since Storware imports individual volumes regardless of the Ceph use case. Ceph RBD is also available as a secondary backup destination.

Reference: Ceph RBD storage provider — Storware documentation

3. CephFS and RGW via the OS Agent

RBD is not the whole story. For CephFS — and for RGW exposed as a file system — the approach is file level. You mount the CephFS share on a host running the Storware OS Agent, and the agent backs up the mounted path and the files inside it, following include and exclude rules. Both full and incremental backups are supported, on Linux, Windows, and macOS hosts.

Reference: Protecting filesystems with OS Agents — Storware documentation

Which strategy to use

• Ceph RBD behind OpenStack or another hypervisor → disk attachment.
• Ceph RBD on its own, or an uncovered platform combination → the Ceph RBD storage provider (agentless, RBD-NBD).
• CephFS, or RGW mounted as a file system → the OS Agent, for file-level backup.

Wrap-up

The picture is cleaner than it used to be. Disk attachment is the preferred path wherever a hypervisor manages the Ceph RBD volumes, the storage provider protects RBD directly and agentlessly when there is no virtualization layer, and the OS Agent covers CephFS and RGW at file level. One platform, one set of policies, and data protection continuity across all of them — before, during, and after any migration.

Frequently asked questions