The 3-2-1 Backup Rule: Designing Recoverable Data
The 3-2-1 rule is a resilient starting model: keep at least three copies of valuable data, across two different media or failure domains, with at least one copy offsite. “Three copies” commonly means production data plus two additional copies. Three folders on one physical disk do not satisfy the intent because one failure can affect all of them. Likewise, two cloud locations that the same administrator account can delete may be physically separate while sharing one credential risk.
Define recovery objectives before copy counts
Recovery Point Objective describes the tolerable data-loss interval. Recovery Time Objective describes the target time to restore service. These targets should follow business impact and guide backup frequency and restore design. Recovery may require a consistent set of databases, object or file storage, application secrets, DNS, certificates, and configuration. A virtual-machine snapshot alone does not guarantee application consistency or a separate failure domain. For active databases, use application-aware snapshots, transaction-consistent dumps, or the mechanism recommended for that platform.
Build resistance to deletion and encryption
In addition to an offsite copy, an offline or immutable copy can reduce the impact of ransomware and accidental bulk deletion. Choose immutability periods in harmony with retention and lawful deletion duties. Separate backup identities from production administration, apply least privilege and MFA, and alert on destructive changes. Encrypt transfers and stored backups where appropriate, but remember that losing the encryption key can make a healthy archive unusable. Document and protect key recovery separately.
A successful job status may prove only that a copy operation finished. Combine automated integrity checks with sample file reads and regular full restoration exercises. During an exercise, measure clean-environment preparation, dependency order, permissions, DNS cutover, and user validation. Record the date, source copy, elapsed time, errors, and improvements. A retention schedule should follow business and regulatory needs rather than adopting daily, weekly, and monthly labels without analysis.
Review the design whenever data volume, application architecture, vendors, or compliance obligations change. Account for backup transfer, storage, retrieval, and operational effort, and verify current service terms before assuming any component is included.
Practical checklist
- Write a data inventory and business-approved RPO and RTO.
- Verify that three copies occupy genuinely separate failure domains.
- Plan at least one offsite, preferably offline or immutable, copy.
- Separate identities, encryption keys, and deletion privileges.
- Run and document regular full restoration exercises.
3-2-1 Yedekleme Kuralı: Kurtarılabilir Veri Tasarımı
3-2-1 kuralı, değerli verinin en az üç kopyasını, iki farklı ortam veya hata alanında ve bunlardan en az birini saha dışında tutmayı öneren dayanıklı bir başlangıç modelidir. “Üç kopya” genellikle çalışan veri ile iki ek kopyayı ifade eder. Aynı fiziksel disk üzerindeki üç klasör, aynı arızadan etkilenebileceği için bu amaca hizmet etmez. Benzer biçimde aynı yönetici hesabıyla silinebilen iki bulut konumu, donanım açısından ayrı olsa da ortak kimlik bilgisi riskini paylaşabilir.
Kopya sayısından önce kurtarma hedefini belirleyin
RPO, kabul edilebilecek veri kaybı aralığını; RTO ise hizmetin geri dönmesi için hedeflenen süreyi tanımlar. Bu hedefler iş etkisine göre yazılı olmalı, seçilen yedek sıklığı ve geri yükleme tasarımını yönlendirmelidir. Veritabanı, dosya depolama, uygulama sırları, DNS, sertifika ve yapılandırmanın tutarlı bir sürümü gerekebilir. Yalnızca sanal makine anlık görüntüsü uygulama seviyesinde tutarlılığı veya farklı bir hata alanını garanti etmez. Yoğun veritabanlarında uygulama uyumlu snapshot, transaction tutarlı döküm ya da ürünün önerdiği mekanizmayı kullanın.
Silinmeye ve şifrelemeye karşı dayanıklılık
Saha dışı kopyaya ek olarak çevrimdışı ya da değiştirilemez bir kopya, fidye yazılımı ve hatalı toplu silme etkisini azaltabilir. Değiştirilemezlik süresi, veri saklama ve silme yükümlülükleriyle uyumlu seçilmelidir. Yedek hesabını üretim kimliğinden ayırın, en az yetki ve MFA uygulayın, silme işlemlerini uyarıya bağlayın. Aktarımda ve saklamada şifreleme kullanırken anahtarların kaybının yedeği kullanılamaz hale getirebileceğini unutmayın; anahtar kurtarma sürecini ayrıca belgeleyin.
Başarılı görev bildirimi yalnızca kopyalama işinin tamamlandığını gösterebilir. Otomatik bütünlük kontrolleri, örnek dosya açma ve düzenli tam geri yükleme tatbikatı yapın. Tatbikatta temiz hedef ortamı, bağımlılık sırası, erişim yetkileri, DNS değişimi ve kullanıcı doğrulamasını ölçün. Sonucu tarih, kullanılan kopya, süre, hata ve iyileştirmelerle kaydedin. Saklama politikası günlük, haftalık veya aylık etiketlerden çok iş ve mevzuat ihtiyacına dayanmalıdır.
Pratik kontrol listesi
- Veri envanteri ile RPO ve RTO hedeflerini yazın.
- Üç kopyanın gerçekten ayrı hata alanlarında olduğunu doğrulayın.
- En az bir saha dışı, tercihen değiştirilemez veya çevrimdışı kopya planlayın.
- Kimlik, şifreleme anahtarı ve silme yetkilerini ayırın.
- Düzenli tam geri yükleme tatbikatı yapıp sonucu belgeleyin.