Backup Retention: KVKK, GDPR and Storage Costs

Why the Question “How Long Should We Keep Backups?” Really Matters

When planning a new hosting setup or consolidating servers, ask both “How often should we back up?” and “For how long should we keep those backups?” On one side, IT and business teams want long retention: old versions, audit trails, the comfort of knowing “it will be somewhere in a backup.” On the other side, legal teams remind everyone about KVKK/GDPR obligations, and finance points to growing storage bills, especially for large databases, media libraries and mailboxes.

Keeping everything forever increases privacy risk and storage costs. Under KVKK and GDPR you have strict principles like storage limitation and data minimisation. At the same time, NVMe disks and fast backup storage are not free, and long chains of dependent backups can make restores slower and more complex. In this article, we will walk through how to decide realistic backup retention periods for websites, email, SaaS apps and logs, to support KVKK/GDPR compliance while keeping storage and operational complexity under control. We will focus on retention planning for shared hosting, VPS, dedicated servers and colocation environments; implementation depends on the backup controls available in your chosen setup.

The Legal Baseline: What KVKK and GDPR Say About Retention

Neither KVKK nor GDPR sets one retention period for every backup. First establish which law and processing activity apply; GDPR scope depends on Article 3, not simply on the server country. GDPR Article 5 and KVKK Article 4 distinguish purpose, data scope and duration:

• Purpose: Define specific, explicit and legitimate purposes. GDPR purpose limitation also addresses later processing incompatible with those purposes.
• Data scope: GDPR requires adequate, relevant data limited to what is necessary. KVKK requires processing related to, limited to and proportionate to the purpose. Assess which fields and copies are needed.
• Storage duration: KVKK ties retention to the relevant legal period or the time needed for the purpose. GDPR limits identifiable storage to what the purpose requires, with specific safeguarded exceptions. Calling a routine backup an “archive” does not make it public-interest archiving under those exceptions.

Storing a backup containing personal data remains processing. Data-subject requests must therefore be considered across the relevant copies, alongside applicable grounds and exceptions. GDPR Articles 12, 17 and 19 address request handling, erasure and recipient notification; KVKK Articles 7, 11 and 13 and its disposal regulation have their own procedures. Your records should show that you can:

• Explain how long you keep personal data in active systems and in backups.
• Show that you have a retention schedule and that you actually follow it.
• Ensure that data deleted to fulfil an applicable erasure obligation is not reintroduced into routine use when a backup is restored.

Sector-specific rules may further constrain you. For example, accounting and tax rules may require multi-year retention of specified financial records, while employment rules may set different periods for particular HR records. The applicable periods depend on jurisdiction and record type. These legal minimums sometimes force you to keep certain categories of data much longer than you would from a pure IT perspective.

For a Türkiye-based record-retention assessment, distinguish these examples:

Withdrawing marketing consent does not justify continuing active marketing. Retaining limited evidence of consent/withdrawal or a suppression record may require a separate assessment. Do not automatically copy an invoice-retention period onto marketing records; identify their purpose, basis and necessary duration.

We covered how these principles affect log files and mail headers in more detail in our article on log retention on hosting and email infrastructure for KVKK/GDPR compliance. The same logic applies to backups: you must be able to justify your retention periods in relation to purpose, law and risk.

Backups vs. Active Data: A Subtle but Important Distinction

Backups can require different deletion procedures from active production systems, but they are not automatically exempt from data protection obligations. Before adopting a backup-expiry approach to erasure, confirm whether it is permitted under the applicable law and circumstances:

• Some backup formats do not support selective deletion of individual records. That limitation does not by itself justify retaining data until the backup expires.
• Where delayed removal from backups is legally permitted, remove the relevant data from active systems, restrict use of the retained backup copies, and expire them within a justified, documented retention window that meets applicable deadlines.
• For disaster recovery, design the restore process to re-apply required deletions and corrections before restored data returns to routine use; maintain a controlled record of changes needed for that process.

This is why indefinite retention is problematic: keeping old personal data recoverable without a continuing, justified need can conflict with storage limitation, even if the backups are rarely accessed.

GDPR timing: Article 17 requires erasure without undue delay when a ground applies, subject to necessary exceptions, including processing required by Union or Member State law under Article 17(3)(b), and establishing, exercising or defending legal claims under Article 17(3)(e). Article 12 requires information about action taken without undue delay and within one month. A necessary extension of up to two further months depends on complexity and request numbers, with reasons communicated in the first month. It is not a default three-month backup grace period.

The EDPB’s 2026 report, section 4.2.6, recognises that changing a backup may affect integrity. It points to procedures that track erasure requests and apply them to restored systems, and notes problems with relying only on routine expiry. Its recommendations are nonbinding and do not displace GDPR obligations. CNIL’s developer guidance likewise recommends erasure in backups or a solution that prevents erased data being restored. These are scoped implementation measures, not an exemption for all old copies.

KVKK timing: Under its disposal regulation Articles 11–12, a controller with a disposal policy acts at the first periodic disposal after the duty arises; intervals cannot exceed six months. Controllers not required to prepare such a policy have a three-month rule after the duty arises, and the Board may shorten the Article 11 periods in specified circumstances. These periods do not postpone a person’s request: if all processing conditions have ceased, the request is concluded and the person informed within thirty days. A justified refusal where conditions remain also has a thirty-day response limit; transferred data require appropriate action with third parties.

KVKK distinguishes erasure for “relevant users” from destruction for everyone and from anonymisation that prevents association even when combined with other data. Its relevant-user definition excludes personnel responsible for technical storage, protection and backups. Hiding a row, masking a field or hashing an identifier does not automatically achieve these outcomes. Under GDPR, data that remains identifiable is still personal data; keep the deletion method and verification evidence explicit.

From Law to Practice: How to Turn Principles into Backup Rules

Compliance language is one thing; making it work on your hosting or servers is another. Let’s translate these principles into concrete steps you can implement with your current infrastructure.

1. Classify Your Data by Purpose and Sensitivity

Start by mapping what you actually store and back up. A simple, pragmatic classification could be:

• Critical business records containing personal data: Customer accounts, orders, invoices, support tickets and relevant medical or financial records.
• Code, configuration and published assets: Product catalogues, blog posts and repositories may still contain names, identifiers or credentials; inspect their actual contents.
• Routine personal data: Marketing lists, tracking identifiers and dormant accounts require purpose and retention review.
• Technical and security logs: Web, email and access logs can contain identifiers even when labelled technical.

For each category, ask two questions:

1. Why do we keep this data (legal basis and business purpose)?
2. For how long do we realistically need to be able to restore it from backups?

Record the period’s starting event, who owns the decision, any legal preservation constraint, and the action at expiry. Resolve conflicting obligations for each record category; do not apply the longest period in the organisation to every backup.

2. Connect Retention with RPO/RTO

Backup retention is not just a legal topic; plan it alongside RPO (Recovery Point Objective), the tolerable data-loss time window, and RTO (Recovery Time Objective), the target recovery time. Frequency, retained history and measured restore duration are separate planning choices. If you have not yet defined those targets, it is worth reading our guide on how to design a backup strategy around RPO/RTO for blogs, e‑commerce and SaaS sites.

Once RPO/RTO are defined, align backup frequency and retention as below. Retention determines how far back recovery can reach; it does not establish restore speed. Validate RTO through timed restore exercises.

• Short RPO + Long retention: more frequent backups, kept for longer – generally higher storage and processing costs, all else equal.
• Long RPO + Short retention: less frequent backups, shorter history – generally lower cost, but more potential data loss and less history for recovering from late-discovered problems.
• Mixed: frequent short-term backups (e.g. 7–30 days) plus rare long-term archives (e.g. monthly for 12–36 months).

3. Build a Simple Retention Matrix

A simple matrix can combine system type, frequency and retention window. The following is a hypothetical planning example, not a legal retention schedule; each period needs justification against recovery needs and applicable obligations:

• Production database (customers/orders): Daily backups, kept for 90 days if justified by recovery needs. Archive only records requiring longer preservation separately; use a 3–5-year period only where justified for those records.
• Website code and assets: Weekly backups, kept for 90–180 days.
• Email accounts: Daily or weekly backups only if that frequency meets the required RPO; retain for 180–365 days only where justified. Preserve specific records needed for legal or HR/tax purposes separately for their applicable periods.
• Logs: Detailed logs for 30–90 days; summaries for 1–2 years only where justified by security or compliance needs. Summarisation alone does not anonymise personal data. Apply the schedule to retained log backups as well.

This matrix becomes the heart of your backup and retention policy. You should be able to show it to auditors and explain how it reflects KVKK/GDPR principles plus sector obligations.

So, How Long Should You Actually Keep Backups?

There is no one-size answer. The ranges below are illustrative planning options for websites on shared hosting, VPS-based applications, dedicated servers and colocation deployments, not statutory periods or verified industry norms. Select them only where recovery needs and applicable retention obligations justify them.

Websites and Databases (CMS, E‑commerce, Corporate Sites)

For a WordPress, WooCommerce, Laravel or custom PHP application with customer accounts and orders, a hypothetical layered plan could be:

• Short-term backups: Daily (or hourly where the RPO requires it) kept for 7–30 days. These can help recover from plugin issues or content deletions; incident recovery requires a usable recovery point from before the compromise.
• Medium-term backups: Weekly full or synthetic full backups kept for 60–180 days. These provide older recovery points for late-discovered bugs and security incidents, provided a usable point predates the problem.
• Long-term archives: Preserve financial records or contracts separately for their applicable retention periods. A 1–3-year window is only an illustration, not a legal minimum or maximum. Keep monthly whole-database backups that long only if the broader data retention is independently justified.

If your site processes special categories of personal data (health, religion, political opinions, etc.), you should be extra conservative: minimise both the volume and the retention period, and talk to legal counsel about whether you really need long-term archives at all.

For payment-card data, consider a design that keeps card details with the payment provider wherever possible. PCI SSC prohibits merchants from retaining card verification codes (CVV/CVC) after authorisation, including for card-on-file or recurring payments, even when encrypted or with customer permission. Do not carry these codes into retained backups. Masking, tokenisation or pseudonymisation does not automatically anonymise data; check whether identifiers remain in older copies.

Email Data

Email is tricky because it often contains many types of personal data mixed together, plus attachments with contracts, IDs, and sensitive documents. Some organisations choose to archive email centrally for legal discovery and compliance; others rely on normal mailbox backups only.

• For standard mailbox backups on hosting or VPS, 90–365 days is an illustrative planning range, not a default: justify the chosen period against recovery needs and the personal data retained.
• Where sector rules require long-term preservation, identify the covered messages and applicable period rather than retaining every mailbox for years. Use a separate, tightly controlled archive for those records.

Whatever you choose, document it clearly so you can justify why old emails are still present in backups or archives. Also ensure that departing employees’ mailboxes are handled according to HR, privacy and labour law requirements.

Application and Security Logs

Logs are essential for security investigations and performance troubleshooting, but they can easily become a KVKK/GDPR risk if you store IP addresses and identifiers for many years without a good reason. As a starting point:

• Detailed logs: Evaluate 30–90 days as an operational planning example, adjusting for incident detection needs and applicable retention requirements.
• Anonymised logs: A longer window (for example, 6–24 months) may support capacity planning or trend analysis if individuals are no longer identifiable. Aggregation alone does not establish anonymity; justify retention separately where identifiers remain.

Again, our dedicated article on log retention under KVKK/GDPR dives deeper into these trade-offs.

SaaS and Multi‑Tenant Applications

If you run a SaaS platform on a VPS or dedicated server, you carry extra responsibility. Your customers may be subject to KVKK/GDPR too, and they will expect contractual clarity on your backup and retention practices. For multi-tenant databases, an illustrative schedule to assess is:

• Frequent backups (daily/hourly) with 30–90 days retention, if justified by recovery needs. Promise per-tenant retention only where the backup design supports it; shared database backups may retain multiple tenants together.
• Optional extended retention (e.g. monthly backups for 12–36 months) as an extra service, aligned with the tenant’s legal obligations.

We covered the SaaS angle in detail in our article on backup and data retention best practices for SaaS apps. Whatever you decide, write it into your Data Processing Agreements and terms of service.

Identify controller and processor roles from the actual purposes and decisions. For a processor, GDPR Article 28(3)(g) addresses returning or deleting data at the controller’s choice when services end, including deleting existing copies unless Union or Member State law requires retention. Match offboarding commitments to shared-backup constraints; the contract alone does not make selective tenant erasure possible.

System Images and Snapshots

For VPS and dedicated servers, image-level backups or hypervisor snapshots can be convenient, but storage growth depends on the implementation and workload. An illustrative short-term schedule to assess is:

• Keep 2–4 recent snapshots (e.g. daily for the last few days) for quick rollback after updates.
• Do not rely on snapshots as your only long-term backup. Instead, export full backups or file-level archives that you can move to cheaper storage tiers.

Snapshots are best treated as short-lived safety nets, not as an archive strategy.

Balancing Retention and Storage Cost: Practical Levers

Once you have roughly defined how long you want to keep backups, the next question is “Can we afford it?” Here are practical cost levers for hosting, VPS, dedicated server and colocation environments.

Adopt the 3‑2‑1 Backup Strategy (But Tune Retention Per Layer)

The classic 3‑2‑1 rule says: keep 3 copies of your data, on 2 different media, with 1 copy offsite. The retention windows can differ, but older restore points may then have fewer independent copies. Count the production data as one of the three copies; copies on the same server do not provide independent protection against server loss. For example:

• Primary hosting backups (same server or same data center): Short retention (7–30 days) for fast restores.
• Secondary backups (separate storage or separate node): Medium retention (30–180 days).
• Offsite backups (another region or provider): Choose frequency to meet the RPO for loss of the primary site. Where justified, retain selected weekly/monthly copies for 6–36 months as a separate archive window.

If you are new to 3‑2‑1, our guide on the 3‑2‑1 backup strategy and how to automate it on cPanel, Plesk and VPS walks through setup options to evaluate against your environment’s access permissions and backup capabilities.

Use Incremental and Deduplicated Backups

Full backups every day are simple but expensive. Many backup tools support incremental backups (only changes since the last run) and deduplication (storing identical data only once), which can reduce storage usage depending on the data and tool. One full-plus-incremental pattern is:

• One full backup per week or month.
• Daily incrementals in between.
• Retention policy expressed at backup set level (e.g. keep 4 weekly fulls + 12 monthly fulls), retaining all full and incremental dependencies needed by each retained restore point.

This approach can lower storage costs, but restore times depend on the backup chain and tooling and should be measured in restore tests. Lower costs do not establish that a retention period is legally justified.

Tier Your Storage

Not every backup needs to live on the fastest NVMe storage. You can separate:

• Hot backups: Recent copies on fast disks, for operational restores.
• Warm backups: Medium-term copies on slower but cheaper storage.
• Cold archives: Long-term, rarely accessed backups on lower-cost storage (e.g. object storage with infrequent access tiers), accounting for retrieval charges, retrieval delays and minimum storage durations.

For dedicated servers or colocation, one design option is internal disks for hot backups plus independent external storage for warm/cold layers. Our article on offsite backup workflows, S3-compatible storage, Restic and Borg shows how to combine encryption, versioning and retention in a cost-efficient way.

Automate Retention and Deletion

A retention policy is incomplete if expired backups are never deleted. Automate deletion where possible and verify its operation. Make sure that:

• Your backup software has retention policies configured (keep last N backups, or keep until date X).
• Old backup sets are actually pruned, not just marked “expired.”
• You have logs or reports showing that deletion jobs ran successfully – useful in audits or investigations.

For Amazon S3 lifecycle expiration, versioning changes the result: expiring a current version can create a delete marker while older versions remain. Plan noncurrent-version cleanup, replication and protected copies, and verify completion; a successful scheduling job is not evidence of immediate physical removal.

Amazon S3 Object Lock protects particular object versions. Governance mode permits an authorised bypass; compliance mode prevents users including root from deleting a protected version during its retention period and does not allow shortening that period. A legal hold is a separate technical lock until an authorised user removes it. Plan these settings with erasure duties before locking data; the feature name does not create a legal reason to retain data. Check the actual behaviour of other S3-compatible providers.

Encryption and key rotation protect access but are not automatic erasure. Assess every relevant key copy, recovery route and retained dataset before considering key destruction; a shared key may also protect records that must remain recoverable. Keep deletion/correction instructions available independently of the production system so a disaster does not destroy the only record of what must be excluded from a restore.

On shared hosting, establish who controls backup retention. If your panel and account permissions expose backup rotation settings, configure them there; otherwise obtain the provider’s retention and deletion policy. On VPS, dedicated and colocation systems, you might use cron jobs plus backup tools to automatically expire old backups on remote storage.

Designing a KVKK/GDPR‑Aware Backup Policy for Your Infrastructure

Here is a step-by-step planning process for hosting, VPS, dedicated server or colocation environments.

Step 1: Inventory Systems and Data

List all systems in scope: websites, APIs, databases, mail servers, CRM/ERP, SaaS platforms. For each, identify what personal data it holds and which legal/regulatory rules apply. If you operate in multiple regions, also think about data localisation requirements, as discussed in our guide on choosing KVKK and GDPR-compliant hosting across Turkey, EU and US data centers.

A country label alone does not establish compliance. Include backup destinations, remote access, subprocessors and applicable transfer rules in the assessment, alongside retention and deletion responsibilities.

Step 2: Define RPO/RTO and Risk Appetite

For each system, define the maximum tolerable data-loss window (RPO) and recovery time (RTO). Critical revenue-generating systems (e‑commerce, SaaS production) may need shorter RPO/RTO targets. Set retention separately based on recovery history needs and justified legal/business purposes; stricter RPO/RTO does not itself require longer retention. Internal test systems may tolerate less frequent backups and slower recovery.

Step 3: Choose Frequency and Retention per System

Translate legal and business needs into concrete numbers. The following schedules are hypothetical planning examples, not KVKK/GDPR requirements; validate each against the system’s recovery targets and applicable record-retention duties:

• Public corporate site with contact form only: Daily backups, keep for 30–60 days. Old inquiry records in the database anonymised or deleted based on your privacy policy.
• E‑commerce store: Hourly database backups kept for 7 days and daily full backups kept for 90 days. Preserve accounting records separately for the applicable statutory period; do not assume accounting rules justify archiving the whole store backup for 5 years.
• Internal HR portal: Daily backups kept for 90–180 days if justified by recovery needs; retain required HR records separately for periods established by applicable labour law and justified HR purposes.

Step 4: Implement on Your Hosting/VPS/Dedicated or Colocation Setup

Implementation depends on your environment, available tools and administrative permissions, but the planning logic stays the same:

• Shared hosting: Verify whether the chosen plan supports automatic backups and user-configurable retention. Where available, configure a rotation (e.g. 14 daily, 4 weekly and 3 monthly recovery points) suited to your retention policy, and periodically download critical backups offsite.
• VPS/dedicated: Use backup tools and methods (e.g. database dumps, filesystem snapshots, Restic/Borg) to push encrypted backups to a separate VPS, object storage or external system with explicit retention rules. Ensure application-consistent database and file recovery points; do not assume a snapshot survives loss of its underlying storage. Verify the chosen tool’s supported backend and retention behaviour.
• Colocation: Combine your own backup appliances or software with separate backup storage or S3-compatible systems, and ensure physical separation from the primary servers.

Whatever your architecture, keep at least one copy in a different failure domain appropriate to the risk: a separate server can protect against a server failure, but site-wide failures require an offsite copy. Enforce retention at that layer as well.

Step 5: Document and Communicate

Your backup retention policy should not live only in administrators’ heads. Document:

• Which systems are backed up, how often, and where.
• Retention periods for each category of data.
• Who has access to backups and who can initiate restores.
• How you handle data subject rights in relation to backups: who assesses requests, whether individual records can be removed, when retained copies expire, how their use is restricted, and how deletions are reapplied after a restore. Have the procedure reviewed against applicable legal obligations.

KVKK disposal regulation Article 7(3) requires records of disposal operations to be retained for at least three years, without prejudice to other legal obligations. This means evidence of the operation, not keeping the erased personal-data contents for another three years. Minimise and restrict access to the audit record itself.

Include key points in your privacy notice and Data Processing Agreements so customers understand what happens to their data in backups.

Governance, Cleanup and Regular Review

Backup retention policy is not “set and forget.” Regulations, storage prices and your own business needs change over time.

Run Periodic Cleanup Campaigns

Even with automated pruning, old backup silos can accumulate: legacy servers, experimental environments, forgotten archives on external drives. At least annually, run a cleanup:

• List all backup locations (local disks, remote storage, tapes, third‑party services).
• Delete backups that are beyond their retention period and have no remaining legal basis.
• Document what you deleted and why, in case of future questions.

Test Restores and Disaster Recovery

A documented retention policy alone does not ensure that backups can be restored when needed. Periodically test that you can:

• Restore a database or file set from different points in time.
• Spin up a new VPS or server from backup if a node fails completely.
• Honour deletion requests after restoring by reapplying recorded deletions before returning the restored system to normal use; do not rely solely on a production system that may also have been lost.

Successful restore tests also give you evidence for auditors that your backup and retention processes are not theoretical.

Conclusion: Find Your Sweet Spot and Review It Regularly

“How long should we keep backups?” has no universal magic number; retention must reflect your specific stack and obligations. KVKK/GDPR principles push you away from “keep everything forever” and toward justified, documented retention windows. Storage costs and operational complexity push you away from overly aggressive “keep every hourly backup for five years” policies. A defensible setup balances recovery needs with justified retention limits and storage costs.

Classify systems and records, define RPO/RTO, design independent backup copies and implement each retention rule. Evaluate storage tiers, incremental methods and deduplication against measured recovery times and the actual tariff. For implementation detail, see our guides on backup strategy and RPO/RTO, 3-2-1 backups and offsite encrypted backup workflows.

If you are planning a new hosting setup or redesigning an existing backup policy, have the people responsible for legal compliance define the retention requirements, then map those requirements to backup schedules and storage plans. Verify that the chosen hosting plan and backup tools support that design. The safest time to fix your backup strategy is before you need those backups.