RAID 1, which mirrors data across two drives, is not a backup — and the distinction isn't semantic pedantry but the reason people lose data they thought was protected when they accidentally delete a folder
The previous articles on this site covered data storage units, the 1TB-shows-as-931GB issue, cloud egress fees, how SSDs work, and Mbps vs MB/s. This article addresses the backup vs redundancy distinction — why storage redundancy (RAID, cloud sync, mirroring) and actual backups protect against completely different failure modes, and the specific scenarios where each fails.
What RAID protects against — and what it doesn't
RAID (Redundant Array of Independent Disks) provides redundancy against hardware failure — if a drive physically fails (motor failure, head crash, controller failure), RAID maintains data availability on the surviving drive(s).
What RAID doesn't protect against:
- Accidental deletion: if you delete a file on a RAID 1 array, the deletion is mirrored to both drives simultaneously. Both drives now reflect the deleted state. The file is gone from both.
- Ransomware: encryption applied to files on a RAID array is mirrored to all drives. Both drives now contain encrypted files.
- Corruption: if a file becomes corrupted (by a software bug, incomplete write, or filesystem error), the corruption propagates to all drives.
- Controller failure: the RAID controller itself can fail, making the array inaccessible even if both drives are physically intact.
- Site disasters: fire, flood, or theft affects all drives in the array simultaneously.
RAID is about uptime, not data protection. A RAID 1 array stays online when a drive fails — the server keeps running, the service keeps serving — while the failed drive is replaced. But it provides no recovery from logical data corruption, deletion, or ransomware.
Cloud sync is also not a backup
Services like Dropbox, Google Drive, OneDrive, and iCloud sync your files to the cloud — and this is frequently (incorrectly) described as "cloud backup."
The key characteristic of sync: changes propagate bidirectionally and automatically. If a file is deleted on your device, the deletion syncs to the cloud and to all other synced devices. If ransomware encrypts your files, the encrypted versions sync to the cloud within minutes, overwriting the unencrypted versions.
What sync protects against:
- Device failure (the files are also in the cloud, you can restore to a new device)
- Local data loss from physical device damage
What sync doesn't protect against:
- Accidental deletion (the deletion syncs)
- Ransomware (the encryption syncs)
- Software corruption (the corrupted files sync)
Version history is the saving grace of most sync services: Dropbox keeps deleted files and previous versions for 30-180 days (depending on plan); Google Drive keeps deleted files in Trash for 30 days. This is closer to backup behavior — but the retention period is limited, and it's specific to the sync service's version history mechanism, not a true backup.
What a real backup requires: the 3-2-1 rule
The 3-2-1 backup rule is the widely-referenced framework for genuine data protection:
- 3 copies of data (the original + 2 backups)
- 2 different storage media types (e.g., local hard drive + cloud)
- 1 copy offsite (geographically separate from the others)
The critical properties that distinguish backups from sync/RAID:
- Point-in-time snapshots: backups capture the state of data at a specific moment, allowing restoration to a known-good state before corruption or deletion occurred
- Retention: multiple backup generations are retained (daily backups for 30 days, weekly backups for 3 months, monthly backups for a year — or similar)
- Independence from the primary system: a backup that's mounted/connected to the same system being backed up can be reached by ransomware. True backups are logically or physically isolated.
- Immutability (ideally): backups that cannot be modified after creation — immutable backups or WORM (Write Once Read Many) storage — prevent ransomware from encrypting backups as well as primary data.
Data unit sizing for backup planning
Understanding storage unit conversions is directly relevant to backup capacity planning:
- A 2TB primary drive that's 80% full = approximately 1.6TB of data to protect
- At a daily incremental backup with 10% daily change rate: ~160GB/day of changed data
- 30 days of daily backups: approximately 4.8TB of backup storage for incrementals + the full initial backup
- With compression (typical 2:1 for mixed data): approximately 2.4TB storage for the 30-day retention window
Understanding petabytes vs terabytes matters for organizational backup planning: a 500-node organization with 500GB average data per node = 250TB total = 0.25 PB. Enterprise backup platforms begin quoting in petabytes when raw data scales to this level.
SSD lifespan and backup frequency interaction
The previous SSD article covered NAND flash wear — SSDs have a finite number of program-erase cycles before cells fail. Enterprise SSDs are typically rated in TBW (Total Bytes Written); consumer SSDs in DWPD (Drive Writes Per Day) or TBW.
For backup drives specifically: using SSDs as backup media raises a consideration that doesn't apply to backup tape or HDDs — SSDs also experience data retention issues when unpowered for extended periods. NAND flash can lose charge (and thus data) over 1-10 years when not powered, with the time shortening as cells wear. For long-term archival backups (write once, store for years), HDDs or tape are more appropriate than SSDs.
How to use the Data Storage Converter on sadiqbd.com
- For backup capacity planning: convert your current primary data volume to the same unit as your backup storage capacity, then apply retention period × daily change rate calculations to determine required backup storage
- For cloud backup comparison: cloud providers typically quote in TB (and charge by the GB); converting between TB and the actual file sizes you're dealing with helps verify the math before committing to a plan
- For understanding backup transfer times: combining data volume (TB, in bytes) with connection speed (Mbps, in bits) — using the bits-to-bytes conversion — gives a realistic estimate of initial backup upload duration
Frequently Asked Questions
How often should backups run for a typical personal or small business setup? Daily backups cover most practical scenarios — the maximum data loss in a daily backup regime is 24 hours of work, which is acceptable for most personal and small business contexts. Hourly backups make sense for data that changes frequently and where losing 24 hours of changes would be significant (accounting systems with daily transactions, active databases, continuous content creation). For personal use, the free tiers of Time Machine (Mac), Windows Backup, or cloud backup services with daily snapshots typically provide "good enough" protection for the cost — the key is ensuring they're actually running and verified periodically (a backup that hasn't been tested for restorability is not a confirmed backup).
Is the Data Storage Converter free? Yes — completely free, no sign-up required.
Try the Data Storage Converter free at sadiqbd.com — convert between bits, bytes, KB, MB, GB, TB, and more instantly.
