PHP Web Siteleri için Yedekleme ve Felaket Kurtarma: Pratik Bir Kılavuz

Her PHP web sitesi, bir yığın hareketli parçadan oluşur: bir web sunucusu, PHP çalışma zamanı, MySQL veya PostgreSQL veritabanı, yapılandırma dosyaları, yüklenen varlıklar ve genellikle yüzlerce küçük cron görevi. Bu parçalardan herhangi biri başarısız olabilir — bozuk bir tablo, yanlışlıkla çalıştırılan bir rm -rf, bir fidye yazılımı kilidi — ve eğer geçen haftadan yalnızca tek bir veritabanı yedeğiniz varsa, başınız belada demektir. DigiForge'de, sayamayacağımız kadar çok PHP sitesini kurtardık ve dört saatlik bir kurtarma ile dört günlük bir kabus arasındaki fark her zaman tek bir şeye dayanır: düzgün bir şekilde tasarlanmış bir yedekleme ve felaket kurtarma stratejisi.

Yedekleme Tek Başına Neden Yeterli Değil

Birçok ekip yedeklemeyi felaket kurtarma ile karıştırır. Yedekleme, verilerin periyodik bir kopyasıdır. Felaket kurtarma ise uygulamanızı tekrar çevrimiçi hale getirmek için yapılan tüm süreçtir — verileri geri yükleme, hizmetleri yeniden yapılandırma, trafiği yönlendirme ve her şeyin çalıştığını doğrulama. Bir BT dayanıklılık raporunun belirttiği gibi, "verilerinizi yedeklemelerle korumak artık hayatta kalmak için yeterli değildir" (kaynak). Test edilmiş bir kurtarma planı olmayan bir yedekleme, henüz okumadığınız bir sigorta poliçesidir.

PHP bağlamında fark çok belirgindir. Veritabanı yedeğiniz mükemmel bir şekilde sağlam olabilir, ancak Apache veya Nginx'i geri yüklenen veritabanına nasıl yönlendireceğinizi, .env kimlik bilgilerini nasıl değiştireceğinizi veya PHP opcache'yi nasıl yeniden oluşturacağınızı bilmiyorsanız, hâlâ çevrimdışısınızdır. Ve kesinti süresi, hepimizin bildiği gibi, para ve güven kaybına yol açar. Kapsamlı bir felaket kurtarma (DR) planı, yalnızca verileri değil, sunucu yığınınızın her katmanını kapsamalıdır.

PHP Siteleri için Yedekleme ve Kurtarma Yığını

Bir PHP uygulamasının yedeklemesini beş farklı katmana ayırıyoruz. Bunlardan herhangi birinin eksik olması diğerlerini işe yaramaz hale getirebilir:

1. Kod ve sürüm kontrolü (etiketler ve dallar dahil Git depoları).
2. Veritabanı dökümleri (MySQL, PostgreSQL veya MariaDB).
3. Web sunucusu yapılandırması (Nginx/Apache sanal sunucuları, SSL sertifikaları, PHP-FPM havuzları).
4. Uygulama yapılandırması (.env, yapılandırma dosyaları, sabit kodlanmış kimlik bilgileri).
5. Kullanıcı tarafından yüklenen içerik (resimler, PDF'ler, veritabanı dışında depolanan herhangi bir dosya).

Her katmanı pratik önerilerle birlikte inceleyelim.

1. Kod ve Sürüm Kontrolü

Uygulama kodunuz bir Git deposunda bulunmalıdır — istisnasız. Ancak bir Git push işlemi yedekleme değildir. Ekiplerin tek bir uzak dala güvenip zorunlu push veya bozuk bir depo nedeniyle haftalarca çalışmalarını kaybettiğini gördük. Bir Git barındırma sağlayıcısı (GitHub, GitLab, Bitbucket) kullanın ve ikinci bir konuma otomatik yansıtma ayarlayın. Üretim dağıtımları için her sürümü etiketleyin. Böylece bilinen iyi bir duruma geri dönmeniz gerektiğinde hangi commit'in canlı olduğunu tahmin etmek zorunda kalmazsınız.

2. Veritabanı Yedekleri

Veritabanı yedekleri en kritik ve en çok ihmal edilen konudur. Yerel bir dizine günlük mysqldump yapmak hiç yoktan iyidir, ancak bunların diski doldurup sessizce çalışmayı durdurduğunu gördük. Yedeklemelerinizi, eski yedekleri döndüren, sıkıştıran ve bunları site dışına — S3, Backblaze veya ayrı bir sunucuya — gönderen bir komut dosyasıyla otomatikleştirin. InnoDB tabloları için okuma kilitlenmelerini önlemek amacıyla mysqldump --single-transaction kullanın ve geri yüklemeyi periyodik olarak test edin. Geri yüklenemeyen bir yedek işe yaramaz.

3. Sunucu ve Web Sunucusu Yapılandırması

PHP siteniz yalnızca kod ve veriden ibaret değildir. Nginx veya Apache yapılandırma dosyaları, PHP-FPM havuz ayarları, SSL sertifikaları ve cron iş tanımları sunucunuza özgüdür. Bunları ayrı bir Git deposunda (veya uygulama deposunda deploy/ dizini altında) saklıyor ve diğerleriyle birlikte yedekliyoruz. Certbot gibi hizmetler Let's Encrypt sertifikalarını otomatik olarak yeniler, ancak sunucunuz ölürse bu sertifikalar kaybolur. /etc/letsencrypt/ dizinini yedekleyin veya yeniden yapılandırmada hayatta kalan DNS tabanlı doğrulamaya geçin.

4. Ortam ve Uygulama Yapılandırması

PHP uygulamalarında genellikle veritabanı kimlik bilgileri, API anahtarları ve sırlar içeren bir .env dosyası bulunur. Bunlar asla sürüm kontrolüne dahil edilmemelidir. Üretim ortamında HashiCorp Vault veya envkey gibi bir sır yöneticisi kullanıyoruz, ancak en azından .env dosyasını şifreleyip yedekleme sisteminize bir kopyasını kaydedin. Bu dosyayı kaybederseniz, sitenizi geri yükleyemez, yeniden inşa edersiniz.

5. Kullanıcı Yüklemeleri ve Medya

Görseller, PDF'ler ve diğer yüklemeler genellikle public/uploads dizininde saklanır. Bunlar hızla büyür ve BLOB olarak saklanırsa veritabanı yedeklerini şişirebilir. En iyi uygulama: yüklemeleri ayrı bir birimde veya nesne deposunda (S3, DigitalOcean Spaces) tutmaktır. Sunucunun dosya sistemindeyseler, bu dizini site dışı yedeklemenize dahil edin. Günlük olarak bulut depolamaya senkronize etmek için rsync veya rclone kullanın.

Kurtarma Planınızı Otomatikleştirme ve Test Etme

Bir yedekleme stratejisi ancak kurtarma kadar iyidir. Müşterinin "Yedeklerimiz var" dediği ancak hiç kullanmayı denemediği çok sayıda olay sonrası incelemesine girdik. Felaket kurtarma bir ürün değil, bir süreçtir. PHP sitenizi nasıl geri getireceğinizi yazıya dökmeli ve daha da önemlisi prova etmelisiniz.

• Bir runbook yazın. Her adımı belgeleyin: yedeklerin nerede saklandığı, veritabanının nasıl geri yükleneceği, web sunucusunu hangi komutların yeniden oluşturduğu, IP değişirse DNS'in nasıl güncelleneceği.
• Geri yüklemeleri otomatikleştirin. Yeni bir sunucu sağlamak ve uygulamanızı yedeklerden geri yüklemek için betikler veya orkestrasyon araçları (Ansible, Puppet veya basit bir Bash betiği) kullanın. Bir saatten kısa sürede bir klon oluşturamıyorsanız, DR planınız çok yavaş demektir.
• Üç ayda bir test edin. Tüm PHP yığınınızı yeni bir sunucuda (yeni bir VPS veya yerel VM) geri yükleyin ve sitenin çalıştığını doğrulayın. DNS yayılımını, SSL'i, veritabanı bağlantılarını, cron işlerini ve her kullanıcı akışını test edin. Bozulan her şeyi düzeltin.

Deneyimlerimize göre, kurtarma tatbikatı sırasında en sık karşılaşılan hatalar kimlik bilgisi uyumsuzlukları (geri yüklenen .env ile eşleşmeyen sabit kodlanmış veritabanı şifreleri), eksik PHP eklentileri ve tamamlanmamış yüklemelerdir. Her hata bir hediyedir — gerçek bir felaketten önce düzeltebileceğiniz bir açığı ortaya çıkarır.

"Test edilmiş bir kurtarma planı olmayan yedek, sadece bir umuttur." — DigiForge mühendislik ilkesi

Depolama Konumları ve Biçimlerini Seçme

Eski 3-2-1 kuralı hâlâ geçerli: verilerinizin üç kopyası, iki farklı ortamda ve bir kopya şirket dışında. PHP web siteleri için yaygın bir kurulum şöyledir: (1) canlı sunucunun yerel yedekleme betiği, (2) şirket dışı bir bulut depolama alanı ve (3) aylık anlık görüntüler için soğuk depolama arşivi (ör. Glacier). Yedekleri üçüncü tarafa yüklemeden önce GPG veya istemci tarafı şifreleme ile şifreleyin.

Artımlı yedeklemeler bant genişliği ve depolamadan tasarruf sağlar, ancak geri yükleme karmaşıklığını artırır. Orta trafikli bir PHP sitesi için günlük tam veritabanı dökümü ve gerekirse saatlik ikili günlükler iyi bir denge sağlar. Dosya sistemi yedeklemeleri rsync ile artımlı olarak yapılabilir — yalnızca araçlarınızın artımlı yedeklerden tutarlı bir durum oluşturabildiğinden emin olun.

Felaket Anında: Kurtarma Runbook'u

En kötü senaryoyu simüle edelim: bir fidye yazılımı saldırısı PHP web kökünüzü ve veritabanınızı şifreliyor. İşte DigiForge'da kullandığımız üst düzey kurtarma akışı:

1. Enfekte sunucuyu izole edin — tüm dış erişimi kesin, adli bilişim için gerekirse anlık görüntü alın.
2. Temiz bir sunucu hazırlayın — aynı işletim sistemi ve PHP sürümüne sahip yeni bir VPS.
3. Kodu Git'ten geri yükleyin — saldırıdan önce çalışan etiketli sürümü klonlayın.
4. Yapılandırmayı geri yükleyin — .env, web sunucusu yapılandırmaları, SSL sertifikalarını kopyalayın (veya yeniden düzenleyin).
5. Veritabanını geri yükleyin — en son temiz dökümü içe aktarın, ardından varsa enfeksiyon anına kadar ikili günlükleri tekrar oynatın.
6. Yüklemeleri geri yükleyin — yedek depolamadan yeni sunucunun yükleme dizinine rsync yapın.
7. Her şeyi test edin — sağlık kontrolleri çalıştırın, veritabanı bağlantılarını doğrulayın, cron işlerinin çalıştığından emin olun.
8. DNS'i değiştirin — alan adınızı yeni sunucunun IP'sine yönlendirin (önceden TTL'yi düşürün).
9. İzleyin — 24 saat boyunca günlükleri ve çalışma süresini izleyin. Kurtarmayı ancak sürekli yeşil sinyal aldıktan sonra ilan edin.

Yedekleriniz iyi organize edilmişse ve pratik yaptıysanız bu sürecin tamamı 2-4 saat sürebilir. Pratik yapılmazsa günlerce uzayabilir.

Kurtarma Kültürü Oluşturmak

Felaket kurtarma tek seferlik bir proje değil, sürekli bir uygulamadır. PHP sürümünüzü her güncellediğinizde, yeni bir cron işi eklediğinizde veya bir web sunucusu yönergesini değiştirdiğinizde, runbook'unuzu güncelleyin ve yeniden test edin. Çok fazla ekibin yedeklemeleri bir onay kutusu öğesi olarak ele aldığını gördük. Gerçek bir DR stratejisi, dağıtım hattınıza, izleme sisteminize ve ekibinizin kas hafızasına işlenmiştir.

Bir PHP web sitesinden sorumluysanız, bugün başlayın. Beş katmanın tümü için yedekleme kapsamınızı gözden geçirin, otomatikleştirebildiklerinizi otomatikleştirin ve ilk kurtarma tatbikatınızı planlayın. Stratejiniz hakkında ikinci bir görüş isterseniz, DigiForge ile iletişime geçin. Neyin işe yaradığını ve neyin yaramadığını bilmek için yeterince PHP sitesi kurduk ve kurtardık.