Deleting personal data from Ceph for GDPR erasure requests

Deleting personal data from Ceph for GDPR erasure requests: what the platform can and cannot do

When an erasure request arrives, the controller has to find every copy of the data: objects in RGW buckets, RBD images, CephFS files, snapshots, and the replicas or mirrored zones that hold the same bytes. Ceph provides deletion, object versioning, Object Lock, snapshots and multisite replication, but none of these runs erasure on its own. Each one must be configured by the controller, and each one can keep personal data after the live copy is gone. Article 17(1) of the GDPR lists the grounds on which a data subject can require erasure without undue delay, and Article 17(3) sets the exceptions, including compliance with a legal obligation and the establishment, exercise or defense of legal claims. Whether an exception applies is a legal judgment for the controller, not a storage setting. DeployOpen plans and configures the platform and prepares the evidence, but it does not issue audit reports or certify GDPR compliance.

The EDPB's 2025 coordinated enforcement action on the right to erasure found that controllers struggled with two things: setting retention periods and deleting personal data held in backups. Ceph deployments are exposed to the same gap. Confirm with your legal and records team which retention period applies to each data category before the platform is designed, then check how long deleted objects remain under versioning, whether a bucket or object under Object Lock retention can be removed before its retain-until date, and how long RBD and CephFS snapshots are kept by your schedule. Ask which of these you can shorten without breaking a legal hold, and record the answer, because the decision is yours to justify.

Replication and backups need the same treatment. Confirm whether a multisite zone or RBD mirror peer receives deletions, how quickly they propagate, and whether a backup target keeps copies that an erasure request will not reach. Where a backup cannot be edited without breaking its integrity, document the retention rule, the restore policy that stops erased data from returning to production, and the exception you rely on. The Ceph documentation for these features should be checked against your release, since behavior differs between Squid and Tentacle, and the evidence you keep should show what was deleted, where, when, and what remains and why.

Mapping GDPR Article 17 requirements to Ceph capabilities and configuration

This table maps each GDPR Article 17 obligation to the Ceph features that hold copies of personal data, the configuration each one needs, and the decision the controller must record. Read each row as a question to answer for your cluster: where a copy exists, who can remove it, and whether a retention duty allows you to keep it. Features named here are documented Ceph capabilities, and the confirm column lists what to verify in your own version and deployment.

Requirement or feature	Ceph capability and configuration needed	What the controller must decide and confirm
Article 17(1): erasure without undue delay	RGW object deletion removes the current object. Where bucket versioning is enabled, delete markers and noncurrent versions keep earlier copies until they are purged, so a lifecycle expiration rule for noncurrent versions is needed.	Set a maximum time for purging noncurrent versions and document it. Confirm the RGW lifecycle behavior for noncurrent versions in your Ceph release.
Article 17(1): erasure across all copies	RBD and CephFS snapshots keep data after the live volume is changed. Snapshot retention schedules must be reviewed so that snapshots containing the subject's data expire or are deleted.	Map which volumes and directories hold personal data and which snapshot schedules cover them. Confirm how a snapshot is removed in your platform and whether clones depend on it.
Article 17(1): erasure in replicated and mirrored copies	RBD mirroring and RGW multisite replicate deletions to peer zones or sites, but replication lag means a copy can exist briefly elsewhere. Pending sync state must be checked before a deletion is recorded as complete.	Decide how far a delay in peer sites is acceptable and record it. Confirm sync status checks and how each zone applies deletions in your release.
Article 17(1): backup copies	Backups taken with external tools hold copies that Ceph replication does not touch. Erasure in live data does not reach them unless backup retention is also set.	Set backup retention periods and state how erased data ages out of backups. The EDPB found controllers struggled with backups, so record the approach explicitly.
Article 17(3)(b): legal obligation exception	Object Lock in compliance mode prevents deletion of locked object versions until the retention date. Governance mode can be overridden by users with the bypass permission.	Identify the statute requiring retention and its period. Confirm which Object Lock mode applies and who holds the bypass permission, since that determines whether erasure is possible.
Article 17(3)(e): legal claims exception	Legal hold on RGW objects, where supported in your release, stops deletion without fixing a retention date. Snapshots kept for litigation need a documented owner and an end date.	Decide which records are held for legal claims and when the hold is released. Confirm legal hold support and the exact API calls in your Ceph version.
Article 17(3) and the controller's record	Ceph has no built-in erasure log that satisfies accountability. The evidence must come from your ticketing, lifecycle configuration and deletion logs.	Keep a written record of each request, the copies found, the action taken, the exception applied and the date. Confirm that RGW and cluster logs retain enough detail for your assessor.
EDPB 2025 finding on retention and backups	Retention periods must be set per data category in lifecycle rules, snapshot schedules and backup jobs, then checked on a schedule rather than assumed.	Assign an owner for each retention period. Confirm that periodic checks of lifecycle and snapshot state are scheduled and that results are recorded.

Where personal data lingers in a Ceph cluster

When versioning is enabled on an RGW bucket, a delete request usually adds a delete marker on top of the object instead of removing the data. The earlier versions stay in the bucket and keep the personal data that the request asked you to erase. Lifecycle rules, bucket policies and admin tools all act on these versions, so the erasure procedure has to address them directly. See the Ceph Object Gateway documentation for the versioning behavior of your release.

Delete markers hide, they do not erase: a standard delete hides the current version but leaves prior versions in place.
Explicit version deletion: removing a specific version ID is the step that removes that copy, and it must be run for every version that holds the data.
Lifecycle expiration: noncurrent version expiration rules remove old copies on a schedule, so confirm that the timing matches your erasure commitments.
Indexes and catalogs: check that bucket listings and any search index built on object names no longer reference erased keys.
Suspended versioning: suspending versioning later does not remove the versions that already exist.

Confirm this behavior in a test bucket with your S3 client tooling before you write the procedure.

Snapshots capture the state of an RBD image or a CephFS directory at a point in time. Deleting a file or clearing blocks in the live image does not change the snapshots that still reference those blocks. Personal data erased from the live volume therefore remains readable in every snapshot that was taken before the erasure, until that snapshot is removed or expires.

RBD snapshots: list the snapshots for each image that holds the data, because each one is an independent copy that must be addressed.
Protected snapshots and clones: a protected snapshot with dependent clones cannot be removed until the clones are flattened or deleted, so plan that sequence before the erasure.
CephFS snapshots: a file deleted from the live tree remains in the .snap directories of the snapshots that captured it.
Snapshot schedules: automated schedules keep creating new copies, which can include erased data, so update or pause schedules that cover affected paths.
Retention windows: the longest snapshot age in your schedule sets the time during which the data persists, so record that period for the erasure file.

Check the snapshot list on every image and directory that holds the data, and record the removal of each snapshot.

How to run an erasure request across Ceph copies

This sequence takes a verified erasure request from locating the personal data to a documented outcome, covering every Ceph copy that can keep it. It separates what can be deleted now from what must be retained under an Article 17(3) exception, Object Lock or the controller's backup schedule.

Locate every copy by owner identifier
Start from the data subject identifier your application uses, then map it to the RGW buckets, object key prefixes, RBD images and CephFS paths where that identifier appears. Include the metadata catalog or application database that points to those objects, because a search of Ceph alone will miss references held elsewhere. The step closes with a register listing each bucket, image, path and pool involved, the system owner for each, and the date of the search. Ask your storage team to confirm which pools hold those objects, since pool names rarely reveal the data they contain.
Assess the Article 17(3) exceptions first
Before anything is deleted, the controller or its data protection lead decides whether any Article 17(3) exception applies to each dataset, such as compliance with a legal obligation or the establishment, exercise or defense of legal claims. Record the legal basis and the retention period for each category, and do not delete data that a legal hold or statutory retention rule still covers. The step closes with a signed decision per dataset, indicating erase, restrict or retain, and the reason. This is a legal and governance decision, so the storage team carries it out rather than making it.
Remove current and noncurrent object versions
For erasable objects in versioned RGW buckets, delete the current version and every noncurrent version, since a plain delete only adds a delete marker and leaves the earlier data in place. Check whether lifecycle rules or delete markers are still holding copies, and confirm the bucket's versioning state before you start. Object Lock-protected objects can be deleted only after their retention period ends or where the lock mode allows it, so a request that conflicts with an active lock goes back to the decision step. The step closes with a listing that shows no remaining current or noncurrent versions for the identified keys.
Expire RBD and CephFS snapshots
Identify every RBD image snapshot and CephFS snapshot that contains the affected data, since a deleted file or volume still exists inside older snapshots until those snapshots are removed. Remove snapshots that are not needed for legitimate retention, and document any snapshot kept under an exception with its reason and expiry. Snapshot schedules must be paused or adjusted so they do not recreate the data from the source while the deletion is in progress. The step closes with a snapshot inventory showing each removed snapshot and each retained one, with its exception recorded.
Clear mirrored and replicated copies
Trace every RBD mirror peer, CephFS mirror target and RGW multisite zone that received the data, because each one holds its own copy. Apply the same deletion or retention decision to each peer, and confirm that the source change has replicated rather than assuming it has. Check any external backup repository that receives snapshots or exports, and tie its deletion to the controller's retention schedule for backups, which may permit the data to persist until that copy expires. The step closes with a per-site table showing the state of each copy and the date it was checked.
Confirm multisite propagation
Verify on each RGW zone that the deletion markers and object removals have synchronized, using the sync status reported by the gateway, and confirm the objects are absent from the secondary zones. Replication lag can leave data available for some time after the source is changed, so repeat the check after the sync window and record the time of each result. Where propagation fails, open an incident and do not close the request until the failure is resolved or formally documented. The step closes with sync status output saved for each zone and a confirmation that no copy remains outside the retained set.
Document the outcome and retained exceptions
Write a record for the request that lists the data subject identifier, the systems and Ceph objects affected, the actions taken, the exceptions applied and the copies that remain. Include the Object Lock or backup retention that prevents immediate deletion and the date on which each retained copy is due to expire. Keep the record with the request file so the controller can show how it responded to the request, and link it to the processing records and retention schedule. The step closes when the data protection lead signs off the record and the request status is updated to closed or to open with a retention date.

Evidence to keep for an erasure decision

An erasure decision is only as defensible as the record behind it. The cards below cover the controller's own decision records and the Ceph outputs that prove what was removed, what was kept under an exception, and where copies still exist. Keep them together so a supervisory authority can follow one request from intake to confirmation.

Erasure request log

The controller's register of each request: receipt date, data subject identity check, Article 17(1) ground relied on, affected buckets, images, volumes and filesystems, and the response date. Ceph does not produce this record, so the controller owns it. Check that every request links to the storage identifiers it touched, such as bucket names, RBD image names and CephFS paths, so the log can be matched against cluster state later.

Article 17(3) exception assessment

A written note for each retained item, stating which exception applies (for example a legal obligation or legal claims) and for how long. This is the document a supervisory authority will ask for when data remains after a request. Record the specific retained object or snapshot, not just the category, so the exception can be reviewed when its basis expires.

Retention schedule settings

The rules that set how long copies live: RGW lifecycle expiration, noncurrent version expiry, snapshot retention policies and any Object Lock retention periods. Export the active configuration and store it with a change history. Confirm that an Object Lock retention period cannot be shortened by the erasure process, because the schedule you document must match what the cluster enforces.

RGW lifecycle and versioning configuration

The bucket-level lifecycle rules and versioning state exported from each RGW bucket. These show whether deleting a current object leaves noncurrent versions behind, and whether any delete markers are retained. Capture the bucket configuration before and after an erasure run. Confirm with your Ceph release notes how lifecycle processing timing works on your version before you state a completion time to a regulator.

Snapshot and mirror inventories

A list of RBD and CephFS snapshots, and of any RBD mirroring peers, with the images or paths each one covers and its creation and expiry dates. Snapshots often hold deleted personal data long after the live volume is clean. Record which snapshots were purged, which were retained under an exception, and which mirror peers received the purge.

Multisite sync status and deletion confirmations

Multisite sync state from each zone, showing that a deletion has replicated to secondary zones, and the signed or logged confirmation that each copy was removed. Retain the sync status output with a timestamp, and treat any zone still behind as an open item. Without this evidence, a deletion in the primary zone is only a claim about the other sites.

Retention periods and backups: the EDPB finding in practice

The EDPB's 2025 coordinated enforcement action on the right to erasure found that controllers struggled with two things: setting retention periods and deleting personal data held in backups. For a Ceph operator, that finding lands on a concrete question: for each data category stored in RGW buckets, RBD images or CephFS paths, what is the retention period, who set it, and where is the written record? Start by mapping each category to a retention period in your records of processing, then configure lifecycle rules on RGW buckets and snapshot schedules on RBD and CephFS to match. A retention period that exists only in a policy document, with no matching lifecycle rule or snapshot retention setting, will not hold up under review.

Backup copies need a documented decision for each erasure case. Three outcomes are realistic: the copy is restored and then purged of the data subject's records before it goes back into service, the copy is overwritten as the backup rotation reaches it, or the copy ages out at its scheduled expiry. Each outcome has a different timeline and a different risk. A restore-and-purge approach is only workable if you can identify the affected objects inside the backup set, which depends on how your backup tool indexes data. Confirm with your backup vendor or internal team whether selective deletion from a backup set is supported, and whether the backup set is replicated to a second site or copied off-network, because each copy must follow the same decision. Record the chosen outcome, the backup retention window and the reasoning in your records of processing so an authority can see why the data remained in a backup after an erasure request was granted.

Keep the reasoning specific to the exception under Article 17(3) when you rely on one. A legal obligation to keep financial records, for example, justifies retaining those records for the statutory period, but it does not justify keeping unrelated personal data in the same backup set. Where an Object Lock retention period prevents deletion before expiry, document the lock duration, who can shorten it, and the date the object becomes eligible for deletion, and state whether the data is restricted in the meantime. Ask your legal team to confirm which exceptions apply to each category, and ask your storage team to confirm which settings in your Ceph release can enforce them.

Common questions about GDPR erasure on Ceph

What drives the cost of deleting personal data from a Ceph cluster?

The main cost driver is how many places personal data has been copied, not the deletion itself. Each bucket, RBD image, CephFS path, snapshot chain, mirror peer and multisite zone that can hold the data adds mapping, testing and evidence work. Other drivers are how well personal data is tagged or indexed today, whether object versioning or Object Lock is in use, how many applications write to the cluster, and whether backups sit outside Ceph. Costs are one-time for the mapping and tooling, and recurring when erasure requests must be run continuously. Ask any partner for a written scope that lists each storage location, the erasure method for each, and the evidence they will produce.

How long does a GDPR erasure request take to complete on Ceph?

Article 17(1) requires erasure without undue delay, and the Regulation does not set a fixed number of days for the technical work. On Ceph, the time depends on whether the data sits in live objects, in old object versions, in snapshots, or in retained copies that must be expired on a schedule. Snapshot and backup copies can outlast the live deletion, so the completion date for a request may depend on retention cycles you configured. Confirm with your data protection officer what response period your processes will use, then ask your team or a partner to test the full path on a non-production cluster before committing to a timeline.

What does the controller's team need to provide for erasure work?

The work needs decisions from the controller that no storage engineer can make alone. Your team must identify which processing activities hold personal data, which retention periods apply, and which Article 17(3) exceptions, such as a legal obligation or legal claims, may keep specific records. Storage administrators must provide a current inventory of pools, buckets, RBD images, CephFS filesystems, snapshot schedules, mirror peers and zones, plus access to run and observe deletions. Legal and privacy staff must approve how exceptions are recorded. Without these inputs, the technical deletion cannot be scoped or verified.

Can our own team handle GDPR erasure on Ceph without a partner?

Yes, if your team already runs Ceph day to day and has a defined process for finding and removing personal data. The Ceph RGW and RBD interfaces provide the deletion primitives, but the hard parts are mapping every copy, handling versions and snapshots, and producing records that show what was removed and what was kept under an exception. Teams that lack this mapping work, or that have never restored from snapshots or backups, usually benefit from an outside review of the design. A partner can take on the mapping, the test plan and the written procedure, while your staff keep ownership of the decisions.

Does S3 Object Lock stop us from erasing personal data?

Object Lock can prevent deletion of protected object versions until their retention period ends, so it can conflict with an erasure request. The GDPR does not override an erasure duty because a storage feature is in use, so you need a documented decision for each locked dataset. Options include shortening retention where the configuration allows it, scheduling deletion when retention ends, or recording an Article 17(3) exception where a legal obligation requires keeping the data. Confirm with the Ceph documentation for your release how Object Lock and governance-mode overrides behave before designing the process, and keep the decision record with the request.

How does a multisite or mirrored setup affect deleting personal data?

Each replicated copy is a separate place where personal data exists, so a deletion must reach every zone or mirror peer that holds it. In an RGW multisite configuration, you need to confirm that the delete propagates to the secondary zones and that no zone still holds old versions or a copy the replication log has not applied. For RBD mirroring and CephFS snapshots, the deletion on the primary does not automatically remove snapshots or copies at the peer, so each side needs its own check. Record the zone or peer, the time the deletion was verified, and the method used. Test this on a staging multisite pair before relying on it.

What should a partner include in a scope for GDPR erasure on Ceph?

A written scope should list the data locations, the erasure method for each, and the exceptions process. In practice, that means an inventory of buckets, images, filesystems, snapshot schedules, backup targets, mirror peers and multisite zones, along with a mapping of which systems hold personal data. It should also cover the test plan on a non-production cluster, a runbook for requests, changes to retention settings where needed, and the evidence format, such as deletion logs and exception records. Ask whether the work includes ongoing support or a one-time design, and whether it covers the backup systems that Ceph does not host. DeployOpen plans and documents this work as a fixed-scope engagement, and it does not issue audit reports or certifications.

Which GDPR fines apply if erasure is handled poorly?

Article 83 sets maximum administrative fines of EUR 10 million or 2% of total worldwide annual turnover for infringements such as Articles 25 to 39, and EUR 20 million or 4% for infringements of the principles and data subject rights, whichever is higher in each case. Erasure falls under data subject rights, so failing to act on a valid request can reach the higher tier. The EDPB's 2025 coordinated enforcement action on the right to erasure found controllers struggling to set retention periods and to delete data held in backups, which is why backup copies deserve their own review.

Primary sources for erasure and Ceph configuration

Start with the legal text, then the Ceph documentation for the release you run. The GDPR itself is available on EUR-Lex. For this topic, read Article 17, which sets the erasure obligation in paragraph 1 and the exceptions in paragraph 3, including compliance with a legal obligation and the establishment, exercise or defence of legal claims. Those exceptions decide which copies you may keep, so your erasure procedure should quote them by article number rather than paraphrase them from memory.

Next, read the EDPB news item on the coordinated enforcement action on the right to erasure. It reports that controllers struggled to set retention periods and to delete personal data held in backups. Treat that finding as the test your Ceph design must pass: for each bucket, pool and snapshot schedule, can you name the retention period, the deletion mechanism and the person who approves exceptions? The EDPB item is short, so pair it with your own records of processing rather than using it as a substitute for them.

For the storage mechanics, use the Ceph Object Gateway documentation. It covers bucket versioning, lifecycle rules and multisite configuration, which decide whether deleting an object removes every copy. Confirm current behavior against the exact Ceph release in use, since the active releases are Tentacle and Squid and each has its own documented behavior. Ask your engineers to test a delete on a non-production bucket with versioning and lifecycle enabled, and record which versions, delete markers and replicated zones remain afterward.

Configuration sequence for an erasure-ready cluster

This sequence sets up a Ceph cluster so that personal data can be located, versioned, retained and deleted on purpose, with evidence that each erasure request was carried out or lawfully refused. Each step produces a record that the next step depends on.

Classify data and map it to purposes
The controller's privacy or data owner lists which buckets, RBD images, CephFS paths and pools hold personal data, and for which purpose and legal basis each one is kept. Platform engineers attach the owner, retention period and any Article 17(3) exception to each bucket or image name in a register. The step is done when every pool, bucket and image that holds personal data has a named owner and a documented purpose, and nothing is left unclassified.
Set RGW versioning to match retention
Engineers enable versioning only on buckets that need it, because each noncurrent version is a separate copy that an erasure request must also reach. For each versioned bucket they record how noncurrent versions are expired and confirm the lifecycle rules in the bucket configuration with a test bucket first. The output is a bucket configuration export and a lifecycle policy per bucket, reviewed against the retention periods from step one.
Define Object Lock only where law requires it
Object Lock blocks deletion until retention expires, so it can prevent a valid erasure. The legal or compliance owner confirms in writing which buckets must hold records under a specific legal obligation, and the platform team enables Object Lock only on those buckets, with the retention mode and period set from that obligation. The step is complete when the list of locked buckets matches the approved list and each one names the statute or obligation that requires the lock.
Inventory snapshots and mirror schedules
Engineers list every RBD snapshot, CephFS snapshot and RBD mirror schedule that covers a volume holding personal data, including its retention and the pool it lives in. They decide which snapshots must be deleted, which will expire on their own schedule and which are exempt, and they record the reason for each. The result is an inventory that shows where a deleted object may still exist, with a date by which each copy will roll off.
Verify multisite and mirror sync
For RGW multisite and RBD mirroring, the team checks that the sync status reports all zones or peers as caught up before relying on any deletion. They confirm that a delete made in the primary zone propagates to secondary zones and that no peer retains the object through a separate retention setting. The output is a saved sync status report from each site, taken at the time of the test, showing no backlog for the buckets in scope.
Test a deletion end to end
On a test bucket holding dummy records, the team writes a known object, creates a version and a snapshot, replicates it to the second site, then runs the erasure procedure. They then check that the object is gone from the current view, from all noncurrent versions, from the snapshot and from each replica once lifecycle and sync have run. The step closes when every location reports the object as absent and the test results are recorded.
Capture evidence and document exceptions
Each erasure request gets a record with the request date, the systems searched, the commands or API calls run, the sync and snapshot checks, and the time each copy was confirmed removed. Where data is kept under an Article 17(3) exception, the record states the exception, the legal basis and the review date. The controller's data protection lead signs off the process, and the output is a template used for every request and a log of exceptions that auditors or supervisory authorities can review.

How DeployOpen scopes erasure configuration and evidence on Ceph

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, so erasure controls on Ceph are designed around your cluster, your retention rules and your evidence needs. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every pool, bucket, RBD image and CephFS path that may hold personal data, with its owner and purpose
Record where object versions, Object Lock retention, snapshots and mirrored or multisite copies extend deletion timelines
Agree in writing which erasure exceptions your legal and compliance teams will assess, and who makes each decision

How we build

Configure bucket versioning, lifecycle and Object Lock settings to match the retention rules your controller has approved
Set up snapshot retention and mirroring schedules so deletions propagate to every site in the agreed window
Test deletion end to end, including on secondary sites and in restored backups, and record the results

How we hand over

Deliver a written erasure runbook covering request intake, identity checks, deletion steps and exception logging
Provide configuration records and test evidence that your auditors or supervisory authority can review
Document what DeployOpen prepared and what your team still owns, since readiness work is not an audit or certification

How we support

Review erasure settings whenever Ceph releases, cephadm changes or your retention policy is updated
Retest deletion paths after major changes to replication, backups or multisite topology
Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the original build

Deleting personal data from Ceph for GDPR erasure requests