GDPR and backups: erasure requests, encryption and processors

Backups that hold personal data are covered by the GDPR, including a request to erase that data under Article 17. Taking one person's data out of existing backups is often technically hard, and the European Data Protection Board (EDPB) says in its 2026 report that it might not always be advisable. The common practice is to erase the live data, let backups expire on a documented schedule, and keep a record of erasures that is applied before restored data is used again. This page explains how the rules are commonly read; it is not legal advice.

By Lucas Flores, IT Systeme Flores UG. Last updated 2026-10-29

Does the GDPR apply to backups?

Yes. A backup that contains personal data is itself processing of that data. The Hessian data protection commissioner says so in its guidance on backup concepts: the rights of data subjects, among them the right to erasure under Article 17, belong in the backup concept, and backups belong in the records of processing under Article 30. At the same time Article 32(1)(c) requires the ability to restore availability and access to personal data after an incident, and Article 32(1)(d) a process for regularly testing that the measures work. Backups serve that duty, so the duty to erase and the duty to be able to recover have to be reconciled in practice.

The EDPB describes the tension in its report on the right to erasure: a backup is an important tool to protect the integrity of personal data when a controller suffers a security incident such as ransomware, so it is important to protect the integrity of the backup too.

What does Article 17 require, and what are the exceptions?

A person can ask the controller to erase their personal data, and the controller must do so without undue delay if one of the grounds in Article 17(1) applies: for example that the data is no longer needed for its purpose, that consent was withdrawn and nothing else justifies the processing, or that the data was processed unlawfully. The controller has to answer the request within one month, which can be extended by two further months for complex requests or many requests, with a reason (Article 12(3)).

Article 17(3) lists exceptions. Two matter for backups and archives: processing that is necessary to comply with a legal obligation, and the establishment, exercise or defence of legal claims. In Germany, business letters, booking vouchers and books have retention periods of six, eight and ten years (§ 147 AO, § 257 HGB), which is why an archive and a backup are treated differently; see backup vs. archive. Which email falls under which period, and when you may and should delete, is on Email retention periods in Germany. Whether an exception covers a particular record is a legal question for your data protection officer or your tax advisor.

What do the authorities say about erasure in backups?

The Regulation does not mention backups. The EDPB's coordinated enforcement action on the right to erasure, in which 32 supervisory authorities took part and which the Board adopted on 10 February 2026, looked at the question and reported the following in section 4.2.6:

It might not always be advisable to modify or delete information in backups, because that can harm their integrity. In that case organisations should have appropriate procedures to keep track of erasure requests and to comply with them on restored systems, as much as possible, if a breach hits the organisation's systems.
Half of the responding authorities raised concerns. Many controllers had no specific procedure and relied on automatic deletion, or on the retention period of the backups themselves. Practices varied widely, and many controllers excluded backup data from erasure by default without giving a reason.
One authority found that controllers who delete in increments over long periods make it hard to judge whether erasure happened without undue delay.
The recommendations for controllers are to follow established standards for erasing and destroying data securely, and to verify that erasure was carried out and be able to demonstrate it. Some controllers replace the data to be deleted with random characters, or move it to a separate system where it is erased later. The EDPB may issue further guidance on how to handle erasure in backups and on what "without undue delay" means here.

The BfDI, the German federal data protection commissioner, adds a point about restores in its short position on encryption and backups: processes for the secure deletion of data and of key material have to be planned, and personal data that may no longer be processed must not be restored. So the usual practice has four parts: erase the live data promptly; record the request in an erasure register; let backups expire on a short, documented schedule; and apply the register to anything restored before it goes live. It is practice, not a rule of the Regulation, and authorities may look harder at long retention.

How does backup retention interact with erasure?

The retention period of the backups decides how long erased data can still be found in them. A backup that keeps restore points for 30 days no longer holds an erased mail after about a month, plus the days the retention run and the storage cleanup need. One that keeps yearly restore points for ten years still holds it. That is why the storage-limitation principle of Article 5(1)(e) applies to backups as well: keep restore points as long as the recovery need justifies, and write down the reason. See grandfather-father-son rotation for how tiers thin restore points out.

Two details are easy to overlook. Removing a restore point is not yet erasure from storage: in a deduplicating backup, data that no restore point uses any more is reclaimed by a later cleanup pass. And every extra copy, such as a second repository or an offline disk, has a retention of its own and needs the same reasoning.

Two things can also keep data longer than the retention you wrote down. Immutable storage refuses deletion before the lock period ends, so the lock period adds to the time an erased item can remain in the backups (see immutable backups). And a hold, such as one that pauses retention after a suspected ransomware attack, keeps restore points until someone ends it. Both are deliberate and both belong in the written reasoning.

What do encryption and key handling change?

Article 32(1)(a) names encryption as an example of a security measure, and the BfDI recommends encrypting backups that contain personal data, while noting the cost: key management, and a weighing of confidentiality against availability. The same position notes that access restrictions and logging of the original processing may not apply to a backup, and encryption helps close that gap.

Encryption protects confidentiality. It does not end your duties while you can decrypt the data: you can still be asked to erase it. Destroying a key makes everything under that key unreadable, which fits the end of a whole backup set and nothing smaller. Keep the keys apart from the backups, and keep a copy of them elsewhere: without a key a backup is not a backup.

Who is a processor?

A party that processes personal data on your behalf and on your documented instructions is a processor. A cloud storage provider that holds your backups, a backup service, or an IT service provider that runs your backup system can each be one. Article 28 asks you to choose processors that give sufficient guarantees, and to bind them by a contract. The contract has to cover, among other things, processing only on your instructions, confidentiality, the security measures of Article 32, the conditions for sub-processors, help with data subject requests, deletion or return of the data at the end of the service, and information and audits. Whether a particular provider is a processor in your setup, and which transfers rules apply to the region you choose, are questions for your data protection officer.

What should a small business write down?

Where backups live, who operates that storage and who can read it, and an entry in the records of processing.
The retention of each backup set, any lock period on it and any hold, and the reason for each.
The erasure procedure: erase live data, add a line to the erasure register, answer within the time limit, and apply the register after any restore.
Which records are held under a legal retention duty, for how long, and who decided.
The processors, with a contract each, and what happens to the data when a contract ends.
Encryption, who holds the keys and where the copy of the keys is.
Tests: a restore test, and a check that the register is applied after it.

How Restow handles this

Restow gives you the pieces for a short, documented retention and encrypted storage you control. It cannot remove one person's data from existing backups, and this page says so plainly. Since 0.4.0 it also has two features that keep data longer on purpose, immutable backups and a retention hold; both are described below, with what they mean for an erasure request.

Where the data is, and who holds it

Restow is self-hosted. Backups go to a repository you choose (local disk, S3-compatible storage in the region you pick, or NFS); there is no Restow-run cloud, and Restow does not call home. Restow's maker does not receive your data. Who counts as a processor in your setup, typically the storage provider and any IT service provider that runs Restow for you, is your decision. If a provider operates a Service Provider installation for you, that provider holds the installation's master key and can technically decrypt every tenant's data, so the data processing agreement (Art. 28) should cover that explicitly. See encryption and key handling and storage.

Traffic to the storage is protected as well: a new or changed S3 endpoint over plain http:// is refused (except to localhost), and an endpoint saved before that rule keeps working but is flagged in red on its card and in every test until you move it to HTTPS. That is a technical measure for the security of processing (Article 32), not a statement about your compliance.

Encryption

Every chunk is encrypted with AES-256-GCM before it is written, with a separate key per tenant, in every edition. Each server or client, each file share and each Proxmox VE container has its own restic repository with a random password that the server keeps in its secret store, sealed with the tenant key. The tenant keys are stored only wrapped with the installation's master key, which has to be kept safe separately from the server.

Retention

Mail and Microsoft 365 jobs keep restore points in age tiers: a tenant default plus overrides for single objects. The recommended rule keeps everything for 30 days, then one a day up to 90 days, then one a week up to a year. Without a policy, every restore point is kept.
Machine, file share and Proxmox VE jobs keep daily, weekly and monthly counts. Lowering a number permanently removes older restore points at the next retention run, unless a lock or a hold stops it (see below).
The retention run is daily. It always keeps the newest restore point of every protected object and never prunes anything under a legal hold or a retention hold.
The archive keeps each item for a fixed 8 years, counted to the end of the year of capture, and nothing is deleted before that. No screen or API sets another period yet. After the period only the daily deletion run (Business and Service Provider) deletes, and never under a legal hold. What reaches the archive is decided per mail job by the capture ways you choose (since 0.4.4 also capture from the mailbox, by Graph or IMAP sync) and by what you import; mail that several ways captured is kept once.

Immutable backups, holds and an erasure request

Two features can keep personal data in the backups longer than your retention rule, and an erasure request meets them head on. State of the released version:

Immutable backups are set per repository and are off until an administrator turns them on; nothing is locked before that. On S3 storage with Object Lock, in compliance mode, a locked object cannot be deleted before its date by anyone, Restow included; in governance mode an account that holds the bypass permission can lift it (Restow never uses it). Once it is on, the backup data of the chunk store (Microsoft 365, IMAP, Proxmox VE VM disks) and of the restic repositories of servers, clients, file shares and Proxmox VE containers is locked; the archive's item records keep their own retention. The lock period is yours to choose, from 1 to 3650 days, and a locked object is written to stay locked for the period plus seven days. A daily job renews the lock of everything newer restore points still use.
What that means for erasure: while a restore point is locked, retention cannot remove it and no screen or API in Restow can. It stays visible and restorable, and its space comes back only after the lock has run out. Personal data you erased at the source can therefore remain in locked backups for at least the lock period, and longer where newer restore points keep using the same data. A file share whose repository is still locked cannot be purged before then. Lowering the lock period later is for the provider owner after a recent sign-in and applies only to data written from then on; what is locked stays locked. Choose the period with erasure in mind, and write the reason down.
Local disks and NFS shares get only a deletion delay: Restow's own code refuses to delete a file before its date. The interface says it is not immutability, because someone with access to the server or the share can still delete the files.
A retention hold comes with ransomware detection. While an object has a suspicious restore point that nobody has resolved, retention, restic forget and prune delete no restore point of that object, so clean older restore points are not pruned while encrypted ones pile up. Backups go on and storage grows. Only an administrator ends a hold, with "Mark as false alarm" or "Release hold"; both are audited, and a later clean restore point does not end it. The alert says that retention is paused, and a reminder follows after 14 days if the hold is still open. It is on by default, and the provider owner can switch it off.
What that means for expiry: the expiry that the usual practice relies on is paused for a held object until an administrator resolves the hold, and Restow does not end a hold because of an erasure request. The hold, like the lock, should appear in your written retention reasoning.

Neither feature changes the practice described above: erase the data at the source, keep your register and apply it after a restore. They change how long backups can still hold the erased data, and that time is now partly a setting you choose. See immutable backups for what is and is not locked, and what immutability does not protect against.

Kept database dumps

Before an update the updater makes a dump of Restow's database and keeps it; the Updates tab lists these dumps. A dump holds the whole database with the encrypted secrets, so it can contain personal data such as the names and addresses of protected mailboxes and of users. It is a copy outside your backup retention: the provider owner can download one (a one-time link after a recent sign-in, recorded in the audit log) or delete it. If you download one, keep it as carefully as the master key, and decide how long to keep it.

What Restow cannot do at the released version

It has no function to remove a single item, or one person's data, from existing restore points. A restore point is deduplicated, encrypted storage.
Retention always keeps the newest restore point of each protected object, so it does not remove the last restore point of a mailbox, even after the person left and the account was excluded from backup.
A source or an account that still holds backups cannot be deleted; Restow refuses and asks you to exclude or pause it instead.
A revoked machine is no longer pruned, so its snapshots stay as they are until the machine is removed from Restow. Since 0.4.5 an administrator can remove a revoked machine and then either delete its backups at once or keep them until the machine's retention would have let the newest one go; its restic repository is then deleted on every target that holds it. The repository is a plain restic repository, so an operator can also remove snapshots with restic and the repository password, outside Restow and at their own risk.
Removing a repository from Restow never deletes the data in it; that is a separate step at the storage provider.
Removing a machine deletes all of that machine's backups, now or when they expire, not single files from them.
A restore point under an immutable lock cannot be removed before its lock has run out, and the restore points of a held object are not removed until an administrator ends the hold. No function overrides either for a single erasure request.

In practice that means: erase the data at its source, record the request in your own register, let restore points expire on a retention you can justify, and apply the register after any restore. If you need to purge a person from all backups within a short time, check whether Restow's retention and your process meet your assessment, because today it cannot do it for you. Reads and restores are written to a hash-chained audit log, which helps to demonstrate what was done.

Frequently asked questions

Do I have to delete personal data from my backups when someone asks?

Article 17 applies to personal data wherever you hold it, backups included, unless an exception applies. The European Data Protection Board's 2026 report accepts that it might not always be advisable to modify backups, and expects organisations in that case to keep track of erasure requests and apply them to restored systems as far as possible. Whether that is enough for you depends on how long your backups are kept; ask your data protection officer or a lawyer.

Is it enough to let backups expire?

It is the common practice, and the EDPB found many controllers relying on it. Some authorities raised concerns where the expiry periods are long or not defined, because it is then hard to say that erasure happened without undue delay. A short, documented backup retention, plus a record of erasures that is applied after any restore, makes the practice easier to defend.

Does an immutable backup conflict with an erasure request?

It can. A locked backup cannot be deleted before its lock ends, which is the point of it, so personal data you erased at the source can stay in the locked copies until then. The Regulation does not mention backups, and the EDPB's 2026 report accepts that it might not always be advisable to modify them. The practice is the same as for any backup: erase the live data, keep a record of the erasure and apply it after a restore. Keep the lock period as short as the protection need justifies and write down why. Whether that is enough in your case is for your data protection officer or a lawyer.

What if the data I must erase is also covered by a retention duty?

Article 17(3) lists exceptions, among them processing that is necessary to comply with a legal obligation and the establishment, exercise or defence of legal claims. In Germany, business letters and booking vouchers have retention periods under § 147 AO and § 257 HGB. Which of your records fall under an exception, and for how long, is for your tax advisor and data protection officer to decide.

Does encrypting backups take them out of the GDPR?

No. Article 32(1)(a) names encryption as an example of a security measure, and the BfDI recommends it for backups that contain personal data. It protects confidentiality. As long as you can decrypt the data, you can still be asked to erase it, and you still need to be able to answer such a request.

Is my backup provider a data processor?

If a provider stores or handles your backup data on your behalf and on your instructions, it is likely a processor, and Article 28 then requires a written contract that covers security, help with data subject requests and deletion or return of the data at the end. Whether a given provider is a processor in your setup is for you and your data protection officer to decide. Storage on your own hardware involves no provider at all.

Sources

Read on 29 October 2026.

Regulation (EU) 2016/679 (GDPR), EUR-Lex: Articles 5, 12, 17, 28, 30 and 32. The grounds and exceptions of the right to erasure, the one-month response time, processors, encryption and restoring availability
EDPB: 2025 Coordinated Enforcement Action, Implementation of the right to erasure by controllers (adopted 10 February 2026), section 4.2.6. What supervisory authorities found about erasure in backups, with recommendations for controllers
BfDI: Kurzposition, Verschlüsselung und Backups. Encrypt backups with personal data, plan secure deletion of data and keys, and do not restore data that may no longer be processed (in German)
Hessischer Datenschutzbeauftragter: Wie ein angemessenes Backup-Konzept das Schadensrisiko durch Ransomware-Angriffe mindert. A backup is itself processing and data subject rights belong in the backup concept (in German)
§ 147 Abgabenordnung (AO). Retention periods of 6, 8 and 10 years for business records
§ 257 Handelsgesetzbuch (HGB). The same periods under commercial law