Sistem Yöneticileri İçin Otomatik Yedekleme ve Sağlık Kontrolü

Hızlı Özet (TL;DR)

En gelişmiş sunucu ve yedekleme donanımı bile insan faktörüne, günlük manuel kontrollere ve unutkanlığa bırakıldığında er ya da geç felaketle sonuçlanmaya mahkumdur. IT dünyasındaki en yıkıcı senaryo; **“Her gece yedek alınıyor zannedip, sunucu çöktüğü gün yedekleme diskinin 4 ay önce dolduğunu ve yedeklerin aylardır bozuk alındığını öğrenmek”**tir. Profesyonel sistem mühendisliği; tüm yedekleme, veritabanı tutarlılık kontrolü, S.M.A.R.T. disk sağlığı ve sertifika süresi denetimlerinin savunmacı Bash ve PowerShell betikleriyle (Scripts) otonom yürütülmesini ve anlık sağlık durumunun Telegram, Microsoft Teams veya Dead Man’s Switch mekanizmalarıyla raporlanmasını zorunlu kılar.

Neden Manuel Kontroller ve Sessiz Cron Görevleri Tehlikelidir?

Birçok sistem yöneticisi bir Linux sunucuda crontab -e içine bir yedekleme komutu yazar veya Windows Görev Zamanlayıcı’da (Task Scheduler) bir görev oluşturur ve ilk gün çalıştığını görüp arkasına yaslanır. Ancak aylar içinde şu sessiz arızalar meydana gelir:

• Uzak NAS cihazının IP adresi veya SMB şifresi değişir, bağlantı reddedilir.
• Veritabanı büyüdüğü için /tmp veya yedekleme diski %100 dolar ve sıkıştırma işlemi yarıda kesilir (0 baytlık bozuk .sql.gz dosyası oluşur).
• RAID veya ZFS havuzundaki iki diskten biri arızalanır (DEGRADED durumuna düşer); sunucu tek diskle çalışmaya devam ettiği için kimse fark etmez, ta ki üç ay sonra ikinci disk de yanıp tüm veriler yok olana kadar.

Bu tuzaklara düşmemek için otomasyon betikleri “Hata Yakalama (Strict Error Handling)”, “Bütünlük Doğrulama (Verification)” ve “Aktif Bildirim (Alerting)” prensipleriyle yazılmalıdır.

Kurumsal Sunucularda Otomatize Edilmesi Gereken 5 Kritik Görev

Hem Windows Server (PowerShell) hem de Linux / Proxmox / TrueNAS (Bash) ortamlarında her gün otonom çalışması gereken beş temel kontrol katmanı şunlardır:

Otomasyon Katmanı	Denetlenen / Yürütülen İşlem	Kritik Eşik ve Tetiklenen Aksiyon
1. Disk Kapasitesi & Inode Denetimi	Tüm disk bölümlerinin (df -h, Get-PSDrive) ve inode doluluk oranlarının taranması	Doluluk %80’i aştığında uyarı, %90’ı aştığında acil kritik alarm ve log temizliği
2. Fiziksel Disk (S.M.A.R.T.) & RAID Sağlığı	smartctl, zpool status ve donanım RAID kontrolcülerinde bozuk sektör (Bad Sector) kontrolü	Tek bir Reallocated_Sector_Ct artışında veya DEGRADED havuz durumunda anında bildirim
3. Tutarlı Veritabanı Dökümü ve Şifreleme	MSSQL, PostgreSQL, MySQL sıcak yedek (Hot Backup) alımı ve AES-256 ile şifrelenmesi	Çıkış kodu (Exit Code != 0) kontrolü ve yedeğin minimum dosya boyutu doğrulaması
4. Yedek Bütünlüğü ve Geri Yükleme Testi	Alınan arşivin gzip -t, restic check veya test veritabanında otomatik açılıp doğrulanması	Arşiv bozuksa (Corrupted) sağlam eski yedeğin ezilmesini önleme ve acil müdahale
5. Güvenlik ve Servis Sürekliliği Kontrolü	Kritik servislerin (systemd, Windows Services), SSL sertifika ömürlerinin ve açık portların denetimi	Çöken servisi otomatik yeniden başlatma ve yöneticinin telefonuna olay raporu gönderme

Savunmacı Betik (Defensive Scripting) Yazım Standartları

Sıradan bir betik, birinci satırda hata alsa bile alt satırlardaki komutları çalıştırmaya devam eder ve sonunda “İşlem Başarılı” mesajı gönderebilir. Kurumsal seviyede bir yedekleme betiği şu mühendislik kurallarıyla inşa edilir:

1. Katı Hata Yakalama Modu (set -euo pipefail ve $ErrorActionPreference)

Linux Bash betiklerinin en başına mutlaka set -euo pipefail direktifi eklenir. Bu sayede herhangi bir komut hata döndürdüğünde (-e), tanımlanmamış bir değişken kullanıldığında (-u) veya boru hattındaki (|) bir adım çöktüğünde (pipefail) betik anında durur ve trap fonksiyonu devreye girerek yöneticinin telefonuna hangi satırda hata oluştuğunu bildirir. PowerShell tarafında ise $ErrorActionPreference = "Stop" ve try / catch blokları aynı disiplini sağlar.

2. Sıfır Bayt ve Minimum Boyut Doğrulaması

Veritabanı dökümü (pg_dump veya sqlcmd) alındıktan sonra betik yalnızca dosyanın varlığına (-f) bakmaz; dosyanın boyutunu bir önceki günün yedeğiyle karşılaştırır. Eğer dün 4.2 GB olan ERP veritabanı yedeği bugün 12 KB olarak oluştuysa, disk dolmuş veya bağlantı kopmuş demektir; betik bunu Kritik Yedekleme Hatası olarak işaretler.

3. Otomatik Yaşam Döngüsü ve Temizlik (GFS Retention Policy)

Diskin dolmasını önlemek için betikler Büyükbaba-Baba-Oğul (Grandfather-Father-Son) saklama politikasını uygular: Son 7 günün günlük yedekleri, son 4 haftanın Pazar günü yedekleri ve son 12 ayın ay sonu yedekleri korunurken; ara günlerdeki eski yedekler yalnızca yeni yedeğin sağlamlığı doğrulandıktan sonra otomatik silinir. Eğer o geceki yedek başarısız olduysa, eski yedekleri silme adımı kesinlikle çalıştırılmaz.

“Dead Man’s Switch (Ölü Adam Anahtarı)” Mimarisi Nedir?

Klasik bildirim betiklerinde en büyük mantık açığı şudur: “Hata olursa bana mesaj at.” Peki ya sunucunun elektriği tamamen kesildiyse, işletim sistemi kilitlendiyse veya fabrikanın internet hattı koptuysa? Betik hiç çalışamayacağı için size hata mesajı da atamaz ve siz her şeyin yolunda olduğunu sanırsınız.

Bu kör noktayı ortadan kaldırmak için Dead Man’s Switch (Kalp Atışı İzleme) mimarisi kullanılır. Yedekleme betiği her gece işlemini başarıyla bitirdiğinde ve doğrulama testinden geçtiğinde, dışarıdaki bağımsız bir izleme sunucusuna (Uptime Kuma Push URL veya Healthchecks servisi) bir “Ben Hayattayım ve Yedeğimi Aldım” sinyali (HTTP Ping) gönderir. Eğer izleme sunucusu sabah saat 04:00’e kadar bu sinyali almazsa, sunucu tamamen kapanmış olsa dahi sistem yöneticisine acil alarm gönderir.

Yedekleme trafiğinin dış ağlara güvenli aktarımı için Güvenlik Duvarı Hizmetleri ve verilerin yetkisiz erişime karşı şifrelenmesi için DLP Veri Sızıntısı Önleme politikalarıyla tam entegre çalışan otomasyon altyapıları kuruyoruz.

Kurumsal sunucu izleme, otonom yedekleme betikleri ve felaket kurtarma mimarimiz için Sunucu ve Yedekleme Altyapısı sayfamızı inceleyebilirsiniz.

Sıkça Sorulan Sorular

Yedekleme betiklerinin içindeki veritabanı ve sunucu şifreleri düz metin (Plaintext) olarak mı tutulur?

Kesinlikle hayır. Betik dosyalarının (.sh veya .ps1) içerisine açık kullanıcı adı ve parola yazılması büyük bir güvenlik zafiyetidir. Linux ortamlarında kısıtlı erişim izinlerine (chmod 0600) sahip .pgpass / ortam değişkeni kasaları ve SSH açık anahtar (Public Key) kimlik doğrulaması kullanılırken; Windows PowerShell ortamlarında şifreler yalnızca ilgili servis hesabının ve o fiziksel sunucunun çözebileceği DPAPI (Data Protection API / Export-Clixml) veya Yönetilen Servis Hesapları (gMSA) ile şifrelenerek saklanır.

Sıkıştırılmış bir yedek dosyasının gerçekten geri yüklenebilir olduğundan nasıl %100 emin olunur?

Bir .zip veya .tar.gz arşivinin bozuk olmaması, içindeki SQL veritabanının hatasız ayağa kalkacağı anlamına gelmez. Bu nedenle haftalık otomatik doğrulama betiklerimiz (Automated Restore Testing); alınan son veritabanı yedeğini izole bir test konteyneri (Docker / LXC) içerisindeki geçici bir SQL sunucusuna otomatik olarak geri yükler (RESTORE DATABASE), örnek bir SELECT COUNT(*) ve DBCC CHECKDB bütünlük sorgusu çalıştırır ve test sonucunu ekran görüntüsü/rapor olarak sistem yöneticisine iletir.

Bildirimler için neden e-posta yerine Telegram veya Microsoft Teams Webhook tercih edilmelidir?

Bir şirketin kendi e-posta sunucusu (Exchange/SMTP) veya internet DNS altyapısı çöktüğünde, sunucunun gönderdiği uyarı e-postaları da kuyrukta takılır ve yöneticiye ulaşmaz. Ayrıca gün içinde gelen yüzlerce rutin e-posta arasında kritik bir disk uyarısı gözden kaçabilir. HTTPS API üzerinden çalışan Telegram Bot API veya Teams/Slack Webhook kanalları ise doğrudan sistem yöneticisinin cep telefonuna anlık ve yüksek öncelikli bildirim düşürerek müdahale süresini dakikalara indirir.