Sunucu Yedeği Nasıl Test Edilir? RPO, RTO ve Geri Yükleme Tatbikatı

Bir yedeğin işe yarayıp yaramadığını ancak geri yükleyerek anlarsınız. Önce her sistem için kaybetmeyi göze aldığınız en fazla veriyi (RPO) ve kabul edebileceğiniz en uzun kesintiyi (RTO) yazın. Sonra yedeği canlı sisteme dokunmayan yalıtılmış bir ortama geri yükleyin. Dosyaları sağlama toplamıyla, veritabanını mysqlcheck ve satır sayılarıyla, uygulamayı kısa bir duman testiyle doğrulayın ve her aşamanın süresini ölçün. Ölçülen süre ya da geri gelen en yeni kaydın tarihi hedefinizi aşıyorsa sorun yedek sıklığında, yöntemde ya da geri yükleme hızındadır.

Hedefi sistem başına yazın

"Yedeğimiz var" cümlesi, hangi verinin ne kadar sürede geri geleceğini söylemez. RPO, son kullanılabilir yedekten olay anına kadar kaybedilebilecek veri miktarıdır ve zamanla ölçülür. RTO, olaydan hizmetin yeniden kullanılabilir olmasına kadar geçen süredir. Snapshot ile gerçek yedeğin farkını, 3-2-1 kuralını ve geri dönüş provasının ana adımlarını snapshot ile yedek arasındaki farkı ve 3-2-1 kuralını anlattığımız yazıda özetledik. Burada o provayı ölçülebilir bir tatbikata çeviriyoruz.

Hedefler sistemden sisteme değişir, tek bir rakam bütün sunucuya uymaz. Aşağıdaki tablo varsayımsal bir örnektir:

Tablonun ilk satırı önemli bir gerçeği gösteriyor. Günde bir kez alınan yedek, RPO'yu en kötü durumda 24 saate çıkarır. 15 dakikalık bir hedef döküm sıklığıyla tutturulmaz. MySQL belgesine göre zamana dönük kurtarma, tam bir yedek ile o yedekten sonra oluşan ikili günlük dosyalarını gerektirir ve günlükler mysqlbinlog ile yeniden oynatılır.

Hangi test neyi kanıtlar?

Her test aynı soruyu yanıtlamaz. Hafif testler sık yapılabilir ama yalnız bir kısmı kanıtlar. Tam tatbikat her şeyi gösterir ama zaman ister.

Yalnız ilk iki satırı yapan bir ekip, "yedek dosyamız sağlam" diyebilir. "Sunucumuzu dört saatte geri getiririz" diyebilmek için son satırlara kadar gitmek gerekir.

Varsayımsal bir tatbikat planı

Diyelim ki bir VDS'te WooCommerce mağazası ve şirketin e-postası çalışıyor. Dosyalar ve veritabanı dökümü her gece şifreli olarak başka bir sağlayıcıdaki depoya gönderiliyor. Tatbikatı şöyle kurgulayabilirsiniz:

1. Senaryoyu yazın: "Sunucu 10:00'da tamamen kayboldu." Tatbikatı yürütecek kişi, canlı sunucuya hiç erişmeden yalnız yazılı talimat (runbook) ve yedek deposuyla çalışsın.
2. Saati başlatın. Depoya erişim bilgilerinin ve şifreleme anahtarının nerede olduğunu bulmak, ölçülen sürenin ilk kalemidir.
3. Yalıtılmış bir sanal makine açın ve işletim sistemini kurun. Bu adımın süresini ayrıca not edin.
4. Yedeği indirin, şifresini çözün, dosyaları yerine koyun.
5. Veritabanını yükleyin ve bütünlük denetimlerini çalıştırın.
6. Web sunucusu, PHP ve diğer servis ayarlarını kurun, servisleri başlatın.
7. Duman testini yapın ve geri gelen en yeni siparişin zamanını kaydedin.
8. Saati durdurun, sonuç tablosunu doldurun, test ortamını kapatın.

Bizce talimatı yazan kişiyle tatbikatı yürüten kişinin farklı olması, belgedeki boşlukları ortaya çıkarmanın en kestirme yoludur. Yazan kişi kafasındaki adımı atlar, okuyan takılır.

Geri yüklenen kopya canlıya dokunmamalı

Tatbikatın en sinsi riski, test kopyasının kendini canlı sanmasıdır. Geri yüklenen sunucu, canlının bütün zamanlanmış görevlerini, e-posta ayarlarını ve entegrasyon anahtarlarını taşır. Önlem almazsanız müşterilerinize ikinci kez sipariş e-postası gidebilir.

• Test sunucusunun herkese açık DNS kaydı olmasın. Siteye kendi bilgisayarınızdan hosts dosyasına satır ekleyerek ya da curl --resolve ile erişin.
• Zamanlanmış görevleri ilk açılışta durdurun: RHEL ailesinde systemctl stop crond, Debian ve Ubuntu'da systemctl stop cron. WordPress'te wp-config.php dosyasına define( 'DISABLE_WP_CRON', true ); ekleyin. WordPress 5.5'ten beri WP_ENVIRONMENT_TYPE sabitini staging yapmak, ortam türünü wp_get_environment_type() ile okuyan eklenti ve temalara bunun bir hazırlık kopyası olduğunu bildirir.
• Giden e-postayı kesin: posta aktarıcısını (ör. Postfix) durdurun ya da güvenlik duvarında 25, 465 ve 587 numaralı portlara çıkışı kapatın.
• Ödeme altyapısının bildirim adreslerini, pazaryeri ve ERP entegrasyonlarını devre dışı bırakın, API anahtarlarını test anahtarlarıyla değiştirin. Hangi entegrasyonların bulunduğunu, sipariş kaybı yaşamadan WooCommerce taşımasında çıkarılan envanter gibi bir listeyle önceden belirleyin.
• Geri yüklenen sunucudaki yedek görevini kapatın. Bu görev canlı yedek deposunun erişim bilgilerini taşır. Çalışırsa test kopyasını gerçek depoya yazar, saklama politikası da tetiklenirse ihtiyaç duyabileceğiniz eski yedekleri silebilir.

Geri yüklemeden sonra SSH ile giriş reddedilirse sorun çoğu zaman ~/.ssh klasörünün sahipliği ya da izinleridir. Önce klasörün sahibini ve izinlerini (700 ve 600) kontrol edin. SSH anahtar ve izin hatalarının teşhisi çoğu zaman buradan başlar.

Bütünlüğü nasıl doğrularsınız?

Arşiv ve depo

Yedek aracınızın kendi denetimiyle başlayın. Düz bir tar arşivinde tar -tzf yedek.tar.gz > /dev/null arşivi baştan sona okur ve bozuk bir bölümde hata verir. restic kullanıyorsanız varsayılan restic check deponun yapısını denetler. Paket dosyalarının içeriğini de okumak için --read-data gerekir. Her seferinde bütün depoyu okumamak için restic check --read-data-subset=5% rastgele bir yüzdeyi denetler. BorgBackup'ta borg check --verify-data verinin şifresini çözüp kriptografik doğrulama yapar. Belgesi bunun çok zaman alacağını özellikle belirtiyor.

Dosyalar: sha256sum ile örnekleme

Yedek alınırken dosyaların sağlama toplamı listesini de üretip yedekle birlikte saklarsanız test sırasında karşılaştıracak bir referansınız olur. Göreli yol kullanmak, listeyi başka bir klasöre geri yüklenmiş kopyada da kullanılabilir kılar:

# yedek sırasında, canlı sunucuda
cd /var/www/ornek.com.tr
find . -type f -not -path './wp-content/cache/*' -print0 \
  | xargs -0 sha256sum > /yedek/liste-$(date +%F).sha256

# test sırasında, geri yüklenen kopyada
cd /geri-yukleme/var/www/ornek.com.tr
sha256sum -c --quiet /yedek/liste-2026-10-28.sha256

-c listedeki her dosyayı yeniden hesaplayıp karşılaştırır, --quiet yalnız uyuşmayanları yazar. Çıktı boşsa listedeki bütün dosyalar aynıdır. Liste ile yedek arasında değişen dosyalar (günlükler, oturum dosyaları, önbellek) yanlış alarm üretir. Bu yüzden önbellek klasörlerini listenin dışında tutun ve listeyi yedekle aynı görevde üretin.

Veritabanı: mysqlcheck, satır sayısı ve tazelik

Dökümü test veritabanına yükleyin ve tabloları denetleyin:

mysql -u root -p -e 'CREATE DATABASE magaza_test'
mysql -u root -p magaza_test < magaza-2026-10-28.sql
mysqlcheck -u root -p --check --databases magaza_test

--check, mysqlcheck'in varsayılan işidir. Denetim sırasında her tablo okuma kilidi alır, bu yüzden bu komutu canlıda değil test sunucusunda çalıştırın. MariaDB'nin güncel sürümlerinde aynı araçlar mariadb, mariadb-dump ve mariadb-check adlarını taşır. Eski mysql* adları uyumluluk bağlantısı olarak sürüyor ama MariaDB belgesi bunların kullanımdan kaldırıldığını belirtiyor.

Tablo sağlam olabilir ama boş da olabilir. Yedek sırasında birkaç kritik tablonun satır sayısını kaydedip testte karşılaştırın. WooCommerce 8.2'den beri yeni kurulumlarda varsayılan olan yüksek performanslı sipariş depolamasında (HPOS) siparişler wc_orders tablosunda durur (önüne sitenin tablo öneki gelir, ör. wp_wc_orders):

SELECT COUNT(*), MAX(date_created_gmt)
FROM wp_wc_orders
WHERE type = 'shop_order';

HPOS kapalı bir mağazada siparişler wp_posts tablosunda shop_order türüyle durur. Sorgunun ikinci sütunu ölçülen RPO'nun kendisidir, yalnız değerin UTC olduğunu unutmadan Türkiye saatine çevirin. Geri gelen en yeni sipariş dün gece 23:40 tarihliyse ve senaryodaki olay bugün 10:00'da yaşandıysa, yaklaşık on saatlik siparişi kaybettiniz demektir. Hedef 15 dakikaysa bu tatbikat kalmıştır.

Döküm alınırken yapılan iki hata testte ortaya çıkar. Birincisi tutarlılıktır: --single-transaction yalnız InnoDB tablolarını tutarlı bir anda döker. MyISAM ve MEMORY tabloları döküm sırasında değişmeye devam edebilir ve döküm sürerken başka bir bağlantının ALTER TABLE ya da TRUNCATE TABLE çalıştırması dökümü bozabilir. İkincisi eksik nesnelerdir: MySQL 8.4 belgesine göre --all-databases ile alınan döküm, --routines ve --events açıkça verilmedikçe saklı yordamları ve zamanlanmış olayları içermez. Tetikleyiciler ise varsayılan olarak dökümdedir.

Uygulama: kısa duman testi

DNS'e dokunmadan test sunucusundaki siteyi sorgulamak için:

curl -s -o /dev/null -w '%{http_code} %{time_total}\n' \
  --resolve ornek.com.tr:443:203.0.113.50 https://ornek.com.tr/

--resolve, alan adını yalnız bu komut için verdiğiniz IP'ye yönlendirir. Ardından tarayıcıda hosts dosyası üzerinden şu akışları deneyin: ana sayfa ve bir kategori, ürün sayfası ve görseller, sepete ekleme, yönetim paneline giriş, iletişim formu. E-posta çıkışı kapalı olduğu için formun çalıştığını posta kuyruğundan ya da uygulama günlüğünden doğrulayın.

E-posta: klasör ve ileti sayısı

Bütün posta kutularını değil, bir ya da iki temsilî hesabı geri yükleyin. Dovecot kullanan sunucularda klasör başına ileti sayısını şöyle alırsınız:

doveadm mailbox status -u ad@ornek.com.tr messages '*'

Aynı sayıları yedek sırasında da kaydettiyseniz karşılaştırma birkaç dakika sürer. Klasör ve ileti sayısıyla doğrulama, IMAP ile e-posta taşımalarında da kullanılan yöntemdir. Panel kullanan sunucularda posta kutularının yolu panele göre değişir.

Süreyi aşama aşama ölçün

Toplam süre tek başına neyin iyileştirileceğini söylemez. RTO'yu aşamalara bölün. Sonuç tablosu için şu şablonu kullanabilirsiniz:

Tatbikat bittiğinde tabloda en uzun satır nereyse iyileştirme oradan başlar. İndirme uzunsa son yedeğin bir kopyasını geri yükleme yapılacak yere daha yakın tutmak, veritabanı yüklemesi uzunsa fiziksel yedek alan araçlara bakmak, yapılandırma uzunsa kurulumu betiğe dökmek gerekir.

Tatbikatlarda sık bozulan noktalar

Aşağıdaki sorunların ortak yanı, yedek alınırken hiçbir hata vermemeleridir. Ancak bir geri yükleme denemesinde ortaya çıkarlar.

• Şifreleme anahtarı yalnız kaybolan sunucuda duruyordur. restic belgesi depo parolasını kaybetmenin verinin geri dönülmez biçimde kaybı anlamına geldiğini açıkça yazıyor. Borg'un keyfile kipinde anahtar yedeği alan makinede tutulur ve borg key export ile ayrıca saklanması gerekir.
• Yedek deposunun erişim bilgileri ya da talimat belgesi, yedeklenen sunucunun üzerindedir. Sunucu gidince ikisi de gider.
• Veritabanı, çalışan bir sunucunun veri klasöründen dosya kopyalanarak yedeklenmiştir. Kopya tutarsızdır ve servis açılmaz ya da kurtarma moduna düşer.
• Saklama politikası, ihtiyaç duyulan sürümü çoktan silmiştir. Sorun üç hafta sonra fark edildiyse iki haftalık saklama işe yaramaz.
• Geri yüklenen dosyalar yanlış kullanıcıya aittir. Dosya sahipliği sayısal kullanıcı numarasıyla (UID) saklanır, yeni sunucuda aynı numara başka bir kullanıcıya denk gelebilir.
• Uygulama eski sunucunun ayarına bağlıdır: belirli bir PHP sürümü ve eklentisi, cron satırları, web sunucusu sanal konak dosyaları, PHP-FPM havuzları, SSL sertifikası ve özel anahtarı, güvenlik duvarı kuralları, yapılandırmaya gömülü IP adresi. Bunların hiçbiri site klasörünün yedeğinde yoktur.
• Yedek, aynı sağlayıcı hesabında ya da aynı altyapıda durur. Hesap erişimi ya da altyapı kaybolduğunda yedek de ulaşılamaz hâle gelir.

cPanel kullanıyorsanız tam hesap yedeğinin yeni bir sunucuda açılabildiğini görmek ayrı bir testtir. cPanel belgesine göre bu iş WHM'deki "Transfer or Restore a cPanel Account" arayüzüyle yapılır ve sunucuda arşiv boyutunun en az iki katı boş alan ister. Yedek türlerini ve alma adımlarını cPanel'de tam ve kısmi yedek alma rehberinde bulabilirsiniz.

Ne sıklıkla test etmeli?

Tek bir takvim herkese uymaz, ama şu ritim çoğu küçük ve orta ölçekli sunucu için makul bir başlangıçtır. Yedek görevinin başarı durumu ve arşiv denetimi her çalıştırmada otomatik olsun. Dosya örneklemesi ve veritabanının hazırlık ortamına yüklenmesi ayda bir yapılsın. Tam sunucu tatbikatı yılda en az bir kez, ayrıca işletim sistemi yükseltmesi, panel değişikliği ya da yedek aracının değişmesi gibi büyük değişikliklerden sonra tekrarlansın. E-ticarette yoğun sezon öncesi bir tatbikat, sezonun ortasında öğrenilecek sürprizleri öne çeker.

Fiziksel bir sunucuyu taşıyorsanız da aynı mantık geçerlidir. Sunucuyu veri merkezine teslim etmeden önce hazırlanan bilgiler arasında, taze bir yedeğin başka bir makinede açılabildiğinin kanıtı da yer almalıdır.

Tatbikattan sonra temizlik

Test kopyası, canlı sistemin bütün kişisel verisini taşır. Tatbikat bittiğinde test sanal makinesini silin, indirilen yedek kopyalarını kaldırın, tatbikat için açılan geçici kullanıcıları ve erişim anahtarlarını iptal edin. Sonuç tablosunu, bulduğunuz eksikleri ve bir sonraki tatbikatın tarihini aynı yere yazın. Eksik çıkan her kalem (unutulan bir ayar dosyası, kayıp bir anahtar) yedek kapsamına eklendikten sonra o kısmı yeniden test edin.

Netx VDS'te yedekleme fiyata dahil değildir. Siparişte ek yedek alanı seçebilir ya da kendi dış deponuzu kullanabilirsiniz, ama her iki durumda da yedeğin geri yüklenebildiğini kanıtlamak size kalır. Tam geri yüklemeyi canlı sunucudan ayrı bir VDS üzerinde yapmak, canlı sunucuya dokunmadan gerçek RTO'yu görmenin pratik bir yoludur. Bu işi bir ekibe devretmek isterseniz Netx'in sunucu yönetimi hizmetinde yedekleme kurgusu ve geri dönüş testi kapsamda yer alır, kapsamın ayrıntısı teklif aşamasında yazılı olarak belirlenir.