Overview

The 3-2-1 rule is the simplest reliable backup strategy: keep 3 copies of your data, on 2 different media or systems, with 1 copy off-site. Following it protects you from accidental deletion, disk failure, ransomware and even a whole-datacentre incident. This article explains how to apply 3-2-1 with ALYPOD Cloud products.

The 3-2-1 rule

• 3 copies — the live data plus at least two backups.
• 2 media/systems — for example a local Pod disk and a Storage Box or S3 bucket.
• 1 off-site — a copy that does not live on the same Pod or in the same location.

How to map it to ALYPOD

| Copy | Example storage | |------|-----------------| | Live data | CPU Pod NVMe disk | | Local backup | Pod snapshot / second disk | | Off-site backup | Storage Box or S3 object storage |

Steps

1. Automate. Use cron with rsync (or Vinchin policies) so backups run without human action. Manual backups get forgotten.
2. Version your backups. Use dated folders or --link-dest so a corrupt file does not overwrite a good historical copy. Keep at least 7 daily and 4 weekly restore points.
3. Encrypt sensitive data. Compress and encrypt before sending off-site:

bash tar czf - /var/www | openssl enc -aes-256-cbc -pbkdf2 -out www-$(date +%F).tar.gz.enc

1. Store the off-site copy away from the Pod. Push to an ALYPOD Storage Box or an S3 bucket on a different system than the live server.
2. Test restores regularly. A backup you have never restored is a guess. Restore a sample file or clone a Pod quarterly.
3. Monitor and alert. Log backup results and send failures to your email or monitoring system. Check exit codes in your script.
4. Document credentials and procedures. Record where backups live and how to restore, and store recovery keys securely (for example a password manager).

Troubleshooting

• Problem: Backups grow without limit. Solution: Apply a retention policy — rotate old sets and delete anything past your required window.
• Problem: The off-site copy is actually on the same Pod. Solution: Move it to a Storage Box or S3 bucket; a separate service is what makes it off-site.
• Problem: You cannot remember the last successful restore test. Solution: Set a recurring calendar reminder and add a restore test to your runbook.

Related articles

• [Backing up your server with rsync]
• [Scheduling automatic backups with cron]
• [Restoring data from a backup]