SD Kart Bozulursa Ne Olur? Bir Otel Panelinde Yedekleme ve Felaket Tatbikatı
Raspberry Pi üzerinde çalışan bir personel panelinde yedekleme planını, geri yükleme tatbikatını, bulunan eksikleri ve kurtarma süresini adım adım anlatan proje notu.
Raspberry Pi üzerinde çalışan her sistemin sorusu şudur: "SD kart bir sabah açılmazsa ne olacak?" Bir otelin personel paneli için bu sorunun cevabı "yedeğimiz var" demek değil, "yedekten şu sürede geri dönebiliyoruz ve bunu denedik" demek olmalı. Bu not, yedekleme düzenimizi, yaptığımız felaket tatbikatını ve tatbikatın ortaya çıkardığı eksikleri anlatıyor. Kurulum adımlarının kendisi için MariaDB otomatik yedek, rsync ile uzak yedek ve 3-2-1 yedekleme kuralı rehberlerine bakabilirsiniz.
Neyi kaybedebiliriz?
Yedekleme planı, "neyi kurtarmamız gerekiyor?" sorusuyla başlar. Sistemimizde dört şey var ve her birinin önemi farklı:
| Veri | Önemi | Yedeklenme biçimi |
|---|---|---|
| Veritabanı (hareketler, personel, izinler) | Kritik; yeniden üretilemez | Gece döküm + haftalık uzak kopya |
| Uygulama kodu ve şablonlar | Yüksek; yeniden yazmak günler sürer | Her güncellemeden önce tarihli kopya |
| Yapılandırma (servis dosyaları, tünel, ortam değişkenleri) | Yüksek; unutulması kolay | Metin olarak ayrı arşiv, gizli bilgiler ayrı |
| İşletim sistemi | Düşük; yeniden kurulabilir | Kurulum notları, tam imaj yok |
Üçüncü satır en çok atlanan şeydir. Veritabanını yedekleyip servis dosyasını ve tünel ayarını yedeklemeyen biri, sıfırdan kurulumda yarım gün kaybeder.
Yedek düzeni
Gece belirli bir saatte (kullanımın en az olduğu zaman) bir zamanlayıcı veritabanı dökümünü alır, sıkıştırır, tarih damgasıyla adlandırır ve Pi üzerinde kısa süre saklar. Hemen ardından döküm ağ üzerinden ikinci bir makineye kopyalanır. Haftada bir, bu makineden şifrelenmiş bir kopya dış bir konuma aktarılır. Böylece "3 kopya, 2 farklı ortam, 1 uzak yer" kuralı karşılanır. Zamanlamayı cron yerine systemd timer ile yaptık; sebebi kapalıyken kaçan görevlerin telafi edilmesi ve günlüklerin journalctl'de görünmesi (timer ve cron karşılaştırması).
Saklama süresi: son 7 günlük dökümler günlük, son 8 haftalık haftalık, son 12 aylık aylık tutulur. Eski dökümler otomatik silinir, böylece disk dolmaz; bu ihtiyacı önceden hesaplamak için yedek alanı hesaplayıcıyı kullandık.
Tatbikat: Kartı "öldürmek"
Planı yazmak kolaydı; asıl soru işe yarayıp yaramadığıydı. Bir hafta sonu, otelin sistemi en sakin olduğu saatte, yeni bir SD kart üzerinde sıfırdan kurulum yaptık ve yalnızca yedeklerden geri dönmeyi denedik. Kurallar basitti: eski karta bakmak yok, kafadan hatırlamak yok, sadece yedekler ve yazılı notlar. Süreyi kronometreyle tuttuk.
Adımlar:
- Yeni karta işletim sistemini yazmak ve ilk kurulum (Pi ilk kurulum rehberi).
- Gerekli paketleri kurmak: veritabanı, Python, sanal ortam, tünel istemcisi.
- Veritabanı dökümünü geri yüklemek.
- Uygulama kodunu ve şablonları yerine koymak.
- Servis dosyalarını ve zamanlayıcıları kurmak.
- Tüneli yeniden bağlamak.
- Paneli açıp veriyi kontrol etmek: eski bir ayın toplamı, bilinen bir kişinin kaydı.
Bulduğumuz eksikler
Tatbikat, "yedeğimiz var" dediğimiz sistemde beş eksik ortaya çıkardı:
- Ortam değişkenleri yedekte yoktu. Veritabanı bağlantı bilgisi ve oturum anahtarı bir dosyadaydı ve yedeğe girmemişti. Gizli bilgiler olduğu için bilerek dışarıda bırakılmıştı ama bunların yeri ve nasıl yeniden oluşturulacağı hiçbir yerde yazılı değildi. Çözüm: gizli bilgilerin şifreli ayrı bir kopyası ve "nasıl yeniden üretilir" notu.
- Paket sürümleri belli değildi. Python kütüphaneleri sürüm sabitlenmeden kurulu olduğu için yeni kurulumda biri farklı sürüm geldi ve bir şablon uyarı verdi. Çözüm: çalışan sistemden bir bağımlılık listesi (
pip freeze) çıkarıp yedeğe koymak. - Zamanlayıcılar unutulmuştu. Veritabanı ve kod geri gelmişti ama gece yedeğini ve izleme görevlerini çalıştıran zamanlayıcı dosyaları yedeklenmemişti; sistem çalışıyor görünürken yedek almayı bırakacaktı. Bu en sinsi hataydı: geri döndüğümüzü sanıp yedeksiz kalacaktık.
- Saat dilimi. Yeni kurulumda sunucu saat dilimi varsayılan UTC'ydi; gece yedeği ve raporlar üç saat kaymıştı. Kurulum notlarına bir satır eklendi.
- Yedek dosyası bozuktu. Bir önceki aydan kalan haftalık kopyanın sıkıştırması yarım kalmıştı (disk dolmuş). Dosya vardı ama açılmıyordu. Artık her yedekten sonra dosya bütünlüğü otomatik kontrol ediliyor ve başarısızsa uyarı geliyor.
Sonuç: kurtarma süresi
Notları güncelledikten sonra ikinci tatbikatı yaptık. Sıfır karttan çalışan panele dönüş süremiz yaklaşık 45 dakika oldu; ilk denemede sorun çözmekle birlikte iki saati aşmıştı. Bir otel için bu kabul edilebilir bir süre: bu sürede kart okuyucular olayları kendi hafızasında tutar ve panel geri geldiğinde toplayıcı eksik olayları çeker, yani veri kaybı olmaz, yalnızca bir süre ekran kapalı kalır. Bu tasarım detayı (okuyucunun olayları geçici olarak kendisinin saklaması) kurtarma süresini baskısız hale getiriyor.
Çıkardığımız kurallar
- Yedek, geri yüklendiği gün yedektir. Dosyanın var olması hiçbir şey kanıtlamaz.
- Her şeyi listeleyin: veri, kod, yapılandırma, zamanlayıcılar, gizli bilgiler, paket sürümleri, saat dilimi. Tatbikat bu listeyi tamamlamanın en iyi yoludur.
- Gizli bilgileri yedekten çıkarmak yetmez; nerede olduklarını ve nasıl yenilenebileceklerini yazın.
- Otomatik kontrol ekleyin: boyut, bütünlük, yaş. Yedek sessizce durursa kimse bilmez; bunun için servis izleme ve alarm yazısındaki yaklaşımı kullandık.
- Tatbikatı tekrarlayın. Altı ayda bir; çünkü sistem değiştikçe yedek planı eskir.
- Kartı bozulmadan önce azaltın: yazma sayısını düşürmek ömrü uzatır (SD kart ömrü), ama bu yedeğin yerine geçmez.