Hot, Cold and Archive Backups: NVMe, SATA and Object Storage

Keeping all backup copies on a single disk, especially on the production server, leaves them exposed to the same disk failure or compromise as the live data. A more resilient and cost‑efficient approach is to design a hot, cold and archive storage strategy and map it carefully to the right technologies: NVMe, SATA SSD/HDD and object storage. In this article, we will walk through example tiered backup designs, what each layer is responsible for, how to choose backup frequencies, and how to balance cost, restore speed and safety.

We will explain concepts like RPO/RTO in simple language, show example architectures for a single VPS, multi‑server stacks and colocated dedicated servers, and link everything back to the 3‑2‑1 rule and ransomware‑resistant design. By the end, you will have a clear blueprint to combine NVMe, SATA and object storage into a calm, predictable backup system you can actually trust.

What Do Hot, Cold and Archive Storage Really Mean for Backups?

Before comparing storage options, distinguish the categories: NVMe and SATA are storage interfaces, while object storage is an access model. In this guide, “hot”, “cold” and “archive” describe how quickly you need access to backups and how frequently you expect to retrieve them. These labels vary between providers; the cold tier here is an online backup repository, not necessarily a delayed-retrieval storage class.

• Hot backup storage: Very fast, very close to production, used for frequent backups and quick restores. Think “I broke the site with a bad deploy, roll back now”.
• Cold backup storage: Used when immediate access is less critical, for daily or weekly backups, disaster scenarios and older restore points within, say, 30–90 days. SATA SSD/HDD may offer a capacity-cost advantage; actual speed and cost depend on the disks, workload and service.
• Archive storage: Optimized for long retention (months or years), often with low storage cost per GB but possible retrieval charges and delays. Access is infrequent and often for compliance, audits or rare incident investigations.

These three layers map nicely to different technologies:

• Hot → NVMe on or very close to the production server
• Cold → SATA SSD or HDD on a separate backup server or NAS
• Archive → S3‑compatible object storage in another environment or region

If you want a deeper comparison of disk technologies, it is worth reading our detailed guide on NVMe SSD vs SATA SSD vs HDD for hosting, backups and archives. Here, we will focus on how to combine them in one coherent strategy.

Mapping Hot, Cold and Archive to NVMe, SATA and Object Storage

Hot Storage: NVMe for Fast Backups and Rapid Restores

Hot backups live on very fast storage, typically the same NVMe pool that powers your production database and application, or an NVMe‑backed volume in the same data center. The goal is to reduce storage I/O bottlenecks; actual backup and restore times depend on data volume, workload, network throughput and recovery steps. Copies on the production pool share its failure risks and must not be the only backups.

Common hot backup patterns to consider on NVMe:

• Consistent database snapshots or dumps at an interval matched to your RPO for MySQL/PostgreSQL workloads. A 5–15 minute interval is only useful if jobs can complete within it without unacceptable load; frequent recovery points may instead require a base backup plus continuous log archiving.
• Filesystem snapshots (LVM/ZFS/Btrfs) for application code and configuration before each deployment.
• Short‑retention rolling backups, for example the last 12–24 hours.

NVMe’s high IOPS and low latency can reduce storage overhead, but backup jobs still compete with production for I/O, CPU and memory; their impact must be measured. For detailed techniques on taking consistent hot backups using snapshots, we explained LVM snapshot workflows in our article about application‑consistent backups with LVM and fsfreeze.

Typical use cases for NVMe hot backups:

• Rapid rollback of a bad deployment of your Laravel or WooCommerce site, with database changes handled consistently.
• Recovering orders or user data deleted by a bug, provided they were captured in a retained backup or recoverable log history.
• Fast cloning of production to a staging environment for debugging.

Because high-performance NVMe capacity often costs more per GB than bulk backup storage, a cost-conscious design keeps retention short at this layer and copies backups to cold and archive tiers before removing local restore points.

Cold Storage: SATA SSD/HDD for Daily and Weekly Backups

Cold storage is where most of your operational restore points will live. This is usually a separate VPS, dedicated backup server or NAS using SATA SSDs or large HDDs. Latency is less critical here; what matters is capacity, sequential throughput and isolation from production.

An example cold-tier configuration could include:

• Incremental filesystem backups from production servers every night.
• Daily database dumps, or base backups plus the MySQL binary logs or PostgreSQL WAL needed for point-in-time recovery, copied to the backup server.
• 30–90 days of retention, depending on your business and legal needs.

A cold-tier repository on independent physical storage can protect against production disk failure; a separate logical volume on the same disks cannot. Protection against ransomware also depends on access isolation: production credentials should not be able to alter or delete retained backups. This online tier can support full VPS or database recovery, but restore time depends on backup size, throughput and recovery steps.

Hardware characteristics we care about here:

• Disk size: Enough capacity to hold full + incremental backups for your chosen retention.
• Sequential throughput: Affects how fast you can restore several hundred GB.
• Redundancy: RAID‑1/5/6/10 or ZFS mirrors/parity to survive a disk failure.

Archive Storage: Object Storage for Long‑Term Retention

Archive storage is where we push backups that you rarely need, but cannot delete yet: monthly full backups, quarterly snapshots, legal email archives, logs for forensic analysis, etc. A suitable option is object storage — for example, S3‑compatible buckets hosted in another environment or region, with costs, retrieval times and retention controls matched to your needs.

When choosing object storage for archives, verify the following capabilities and costs; S3 compatibility alone does not guarantee them:

• Designed for huge capacity at low cost per GB.
• Durability through replication or erasure coding across multiple disks and nodes.
• Fine‑grained lifecycle policies to move old objects to colder classes or delete them automatically.
• Support for versioning and enforced immutability / Object Lock. Versioning alone does not prevent deletion; ransomware resistance depends on retention settings and who can change them.

We covered cost aspects in detail in our guide on object storage cost optimization with lifecycle policies, cold storage and bandwidth control. In this article, we will focus on how it complements NVMe and SATA in a layered backup design.

Start with Objectives: RPO, RTO and the 3‑2‑1 Rule

Before you decide “how much NVMe vs SATA vs object storage” you need, you should define two key numbers:

• RPO (Recovery Point Objective): How much data can you afford to lose? 5 minutes of orders? 1 hour of email? 24 hours of blog comments?
• RTO (Recovery Time Objective): How long can you afford to be down while restoring? 5 minutes? 1 hour? Half a day?

We explained these concepts step by step in our article on how to design a backup strategy with clear RPO/RTO. Your hot, cold and archive layers exist to meet those numbers at the lowest possible cost.

Alongside RPO/RTO, we also rely heavily on the classic 3‑2‑1 backup rule:

• Keep 3 copies of your data, including the production copy
• On 2 different media types
• With at least 1 copy off‑site

NVMe + SATA + off-site object storage can support a 3‑2‑1 design, but interface names alone do not establish two media types: NVMe SSDs and SATA SSDs are both flash storage. Verify the actual storage media and failure-domain separation. A possible copy layout is:

• Copy 1: Production data on NVMe; same-pool hot snapshots are extra rollback points, not an independent backup copy
• Copy 2: Cold backups on a separate SATA‑based backup server
• Copy 3: Backups in off‑site object storage, updated frequently enough to meet the off-site recovery objective; older points can be retained as archives

If you want a more operationally focused walk‑through, we recommend our hands‑on guide to the 3‑2‑1 backup strategy and how to automate it on cPanel, Plesk and VPS.

Illustrative Architectures: How the Three Tiers Work Together

Scenario 1: Single NVMe VPS Hosting WordPress and WooCommerce

Imagine a WooCommerce store running on a single NVMe‑backed VPS. You have peaks of order activity during campaigns, and a broken update is not acceptable. Here is a simple, robust three‑tier layout:

• Hot (NVMe on the VPS)
  • LVM snapshots every 30–60 minutes, kept for 24 hours, if the VPS uses an accessible LVM volume with sufficient snapshot capacity. Coordinate database and filesystem consistency; local snapshots do not survive loss of that volume.
  • Consistent MySQL logical dumps every 15–30 minutes into a local NVMe backup directory, only if jobs can complete within that interval at acceptable production load. If considering Percona XtraBackup instead, first verify support for your exact database and tool versions, resource requirements and the preparation steps needed for restoration.
• Cold (separate SATA backup VPS)
  • Nightly backups of web root, uploads and database dumps using rsync with separately retained generations, rsnapshot or restic.
  • 30–60 days of retention with incremental backups.
• Archive (object storage)
  • Weekly full backups and monthly full images pushed from the backup VPS to object storage.
  • 12–24 months of retention, with lifecycle transitions where supported. Delete only expired, independent backup sets; preserve any shared data needed by retained restore points.

A consistent NVMe snapshot can help recover from a failed plugin update, but rolling back a live store also discards later orders and other writes. Preserve current data and plan reconciliation before rollback. If the VPS is lost, restore from the separate backup VPS; recovery time depends on transfer and restore throughput. For a compromise discovered months later, archive copies help only if a clean restore point predating the compromise remains available and protected.

Scenario 2: Small SaaS with Separate App and Database Servers

For a SaaS application with an app server and a separate database server, one possible layout places hot storage directly on the database server’s NVMe, cold storage on a dedicated backup box, and archive on object storage:

• Database NVMe (hot): Continuous log archiving with a compatible recovery base. For PostgreSQL 17, use a physical base backup and an uninterrupted archived WAL sequence extending from the backup’s start through the target time; pg_dump logical backups cannot serve as that base. For MySQL 8.4, preserve a suitable full backup and the complete subsequent binary log chain. Test recovery to the target time with compatible engine versions. A 5–10 minute RPO is a possible target, not a guaranteed result; recovery from server loss requires sufficiently frequent copies of the required backups and logs to independent off-server storage. A replica can support failover but does not replace retained recovery history, since it can also reproduce unwanted changes.
• Backup server with SATA (cold): Receives streaming backups and file snapshots from all SaaS nodes (app, DB, queue, cache, etc.), with 60–90 days retention.
• Object storage (archive): Monthly full backups, configuration exports and anonymized datasets for long‑term retention or analytics.

To recover from a data center outage, keep archives outside that failure domain and plan replacement compute in an unaffected location. Document and test restoration of data, configuration, secrets and network dependencies; automation alone does not guarantee recovery capacity or timing.

Scenario 3: Colocation or Dedicated Server with Local RAID

If you use a dedicated server or colocation and manage your own RAID array, the pattern is similar but with more local capacity:

• Hot: NVMe OS/DB disks in RAID‑1, with frequent snapshots where the storage stack supports them, plus local backup directories. An NVMe cache alone is not a retained backup copy.
• Cold: Large SATA HDD array in RAID‑Z/RAID‑6 used exclusively for backups and logs from the same server and from other servers in your rack.
• Archive: Encrypted replica of cold backups to remote S3‑compatible object storage.

Depending on the hardware and management arrangement, dedicated or colocated servers can offer control over RAID levels and filesystems such as ZFS. Local restore throughput still depends on the array and workload. Keep archive copies outside the rack’s failure domain so a rack‑level incident does not destroy all copies.

Sizing NVMe, SATA and Object Storage for Backups

Once you know your RPO/RTO and have a rough architecture, the next question is: how much of each storage type do you actually need?

How Much NVMe for Hot Backups?

NVMe backup capacity can be estimated in two ways:

1. As a percentage of your live data: For example, model a 20–30% reserve for short‑term backups and snapshots, but validate it against measured retained backup size; this percentage is not a safe default.
2. From RPO and change rate: For 24 hours of hot backups at 15‑minute intervals, measure changed-data volume and WAL/binlog generation, not just net database growth. Include retained full backups, snapshot overhead, temporary working space and headroom.

For busy MySQL or PostgreSQL instances, you also need to consider I/O headroom. Hot backups should not push IOwait through the roof and slow down your site. This is where NVMe’s high IOPS pays off; we discussed these performance benefits in our dedicated NVMe VPS hosting deep dive.

How Much SATA for Cold Backups?

Cold backup sizing is more straightforward and depends heavily on retention:

• Estimate your total dataset size (databases + files + configs).
• Decide how many full backups you want to keep (for example 4 weekly fulls).
• Measure the daily changed-data volume captured by your backup tool, including updates and deletions rather than only net growth.
• Multiply the measured daily incremental size by the retention days (for example 30–60), then add retained full backups, required chain dependencies and working headroom.

Space savings depend on the tool, version and configuration; do not assume restic, Borg and rsnapshot all provide the same deduplication and compression features. Measure stored backup sizes over representative workloads. A fixed 2–3× dataset size is not a reliable allowance for 30–90 days: derive capacity from retained fulls, incremental data, dependencies and headroom.

How Much Object Storage for Archives?

For object storage, you have two big advantages:

• It is easy to scale up as needed.
• Where supported, lifecycle policies can transition older objects to colder classes or delete expired data; deletion must preserve dependencies of retained backups.

A simple illustrative retention model is shown below. Retention periods throughout these examples are planning assumptions, not legal requirements. For personal data, including data governed by GDPR or KVKK, justify retention by the purpose, legal basis and necessary duration; those regulations alone do not justify long-term archiving. Assess applicable accounting or other record-retention obligations separately. Lifecycle rules help implement a policy but do not by themselves establish compliance.

• Monthly full backup of the entire environment.
• Retain for 12–24 months.
• Optional: keep only every second or fourth monthly backup after the first year.

If one full backup is 200 GB, 24 monthly fulls are ~4.8 TB. Deduplication and compression, where supported, may reduce this total, but no 2–3 TB estimate follows without measuring data reuse and compressibility. For backup repositories, use tool-aware retention and pruning rather than deleting shared objects solely by age. You can tune lifecycle policies over time, as explained in our guide on optimizing object storage costs with lifecycle rules.

Automation, Tools and Backup Flow Between Tiers

Automating transfers between hot, cold and archive tiers helps reduce missed copies and manual errors. Scheduled jobs still need failure alerts and restore checks. The following is an example toolchain for NVMe VPS and dedicated servers.

From Hot to Cold: Snapshots and Incremental Sync

• LVM or filesystem snapshots on NVMe where supported, with application-consistency procedures, for local hot recovery points.
• rsync/rsnapshot or restic/Borg, scheduled via cron or systemd timers: first prepare consistent database backup outputs and matching application files on production, and verify successful completion. In a staged pull workflow, use rsync over SSH to copy those completed files to a local staging directory on the backup server; then run restic or Borg there to preserve dated restore points in a separate repository. Keep staging files unchanged during backup, and do not count a failed preparation or transfer as a successful new recovery point. rsnapshot is another option for retaining file generations. Alternatively, run restic or Borg on the source host and write to a supported remote repository. Remote repository support does not mean direct remote source-file access; source files must be accessible to the backup process. Borg 1.4 is used here with local or SSH repositories, not as a direct S3 backend. Copying a running database’s raw data directory as ordinary files does not establish a consistent database backup.
• Compression and deduplication where supported by the chosen tool or filesystem, with measured savings used for SATA capacity planning.

Restic or rclone can be considered for cross‑platform workflows, but a transfer or mirror alone is not a retained backup history. We documented this in detail in our article on automating off‑site backups to object storage with rclone, restic and cron. The same scheduling approach can be adapted between the NVMe hot tier and SATA cold tier, with separate retained restore points.

From Cold to Archive: Syncing to Object Storage

From the cold tier (backup VPS or server), an archive workflow can upload to S3‑compatible object storage:

• Daily or weekly jobs that upload new or changed, successfully completed backup files. Use HTTPS/TLS for object-storage transfers and SSH/TLS for transfers between servers.
• Client-side encryption before upload, using a method compatible with the selected repository or storage backend. Keep repository passwords and recovery keys secure and recoverable independently of the backed-up server and storage credentials. Compression alone is not encryption. Enable server-side encryption at rest where supported as an additional protection, not a substitute for this client-side encryption policy.
• Bucket‑level versioning and, where supported, Object Lock with an appropriate retention policy for immutability.
• Lifecycle transitions to supported colder classes, with expiry coordinated with backup retention and shared-data dependencies. Do not blindly transition a deduplicated repository’s objects by age: older objects may still be needed by current restore points or repository operations. Check tool compatibility, retrieval delays, minimum storage charges and retrieval fees against your recovery and cost targets.

Tools like rclone integrate nicely with object storage and support encryption, bandwidth limits and retries. Combined with cron or systemd timers, these tools can automate transfers from NVMe → SATA → object storage; operators still need to monitor failures, manage retention and verify restores.

Immutable and Ransomware‑Resistant Design

One of the biggest reasons we insist on an off‑site object storage archive is ransomware. If malware encrypts your production data and also manages to infect your backup server, you still want a copy it cannot modify or delete.

Versioning helps retain earlier object versions, but is not by itself immutability. Where supported, Object Lock can provide write‑once‑read‑many (WORM) retention for protected object versions. Resistance to deletion with stolen credentials depends on the service’s retention mode, policy and bypass permissions; configure these deliberately and verify the effective protection rather than assuming every bucket or prefix is locked.

We go deeper into these patterns in our guide on ransomware‑resistant hosting backup strategies with immutable backups and air gaps. Combined with a hot/cold/archive layout, this gives you both day‑to‑day convenience and strong protection against worst‑case scenarios.

Testing Restores: The Most Important Part You’re Probably Skipping

A beautifully layered NVMe + SATA + object storage plan remains unproven until you verify a full restore. We strongly recommend scheduling regular disaster recovery drills to test each tier:

• Hot tier tests: Restore a database or filesystem snapshot to a temporary directory or staging database; verify data freshness and integrity.
• Cold tier tests: Provision a test VPS, restore a full backup from the SATA backup server and confirm the application boots correctly.
• Archive tier tests: Simulate a “region down” scenario by recovering the environment from object storage into an isolated environment in another region, without relying on services in the simulated failed region.

We described a practical process for this in our article about running safe disaster recovery drills for hosting backups. Even a simple quarterly restore test can expose small issues (permissions, missing configs, secrets) before a real incident and provide evidence that the tested recovery path works.

Matching Hosting Infrastructure to This Strategy

A possible three‑tier layout is shown below. When selecting hosting and storage plans, verify the disk types, snapshot support, locations and object storage features needed for this design:

• NVMe VPS for production: Your main web/app + database servers using high‑performance NVMe disks for hot data and snapshots.
• Secondary VPS or dedicated backup server with SATA disks: Aggregates cold backups from all your production instances.
• S3‑compatible object storage in another data center or region: Stores encrypted, versioned archive backups with lifecycle policies.

To map an existing environment to this three‑tier backup model, decide how often to snapshot on NVMe, how big the backup VPS should be, how to structure object storage buckets, and how to tie it all together with cron jobs and backup tools.

If you are planning a new project, we suggest defining RPO/RTO and backup design at the same time as you choose your hosting architecture. For example, when you evaluate whether you need one VPS or multiple VPS for dev/staging/production, our guide on hosting architecture for development, staging and production pairs nicely with the NVMe + SATA + object storage plan described here.

Bringing It All Together: A Calm Backup Strategy You Can Trust

A good backup system is not about a single magic technology; it is about a layered strategy that balances speed, cost and safety. NVMe can support fast hot backups and restores, but rollback time also depends on snapshot support, data volume and the recovery workflow. SATA‑based backup servers provide generous, affordable cold storage for day‑to‑day restore needs. S3‑compatible object storage in a separate location can provide an off‑site archive layer. Verify its durability commitments and support for versioning, lifecycle rules and immutability, and configure the required protections.

Aligning these three tiers with clear RPO/RTO targets and the 3‑2‑1 rule gives you a framework for recovering from common incidents (bad deploys, accidental deletions) and larger failures (hardware failures, major compromises). Actual recovery time and recoverability must be established through restore drills. The key is to automate the flow between NVMe, SATA and object storage, and to schedule periodic restore drills so you can measure recovery time and identify gaps in the tested scenarios.

Document current disk usage, growth expectations and compliance constraints alongside your measured restore times. Use these inputs to keep the hot, cold and archive plan aligned with your capacity, retention and recovery needs.