Şifreli WordPress yedeğini Drive’a taşımak: yüklemeden gerçek geri dönüş testine

Bir yedeğin buluta yüklenmiş olması, uygulamanın ondan geri açılabileceğini göstermez. Başarılı aktarım kaydı, doğru veritabanı, eksiksiz dosyalar, erişilebilir kurtarma anahtarı ve çalışabilir geri dönüş adımlarıyla tamamlanmalıdır. Temsili batuhanyazici.com yayını için amaç, e-postaya çok sayıda ek dağıtmak yerine doğrulanmış özel uzak kopya ve tek anlaşılır durum bildirimi üretmektir.

Yedek kapsamını uygulamayla birlikte tanımlayın

WordPress dosyaları, medya, veritabanı ve gerekli özel işletim ayarları ayrı kalemlerdir. SQL dökümü olmadan yalnızca yayın dizinini kopyalamak yeterli değildir. Buna karşılık her geçici dosyayı, önbelleği veya eski yedek klasörünü tekrar pakete katmak boyutu gereksiz büyütebilir. Dahil etme ve hariç bırakma kararlarını kurtarma gereksinimine göre verin; aynı hosting hesabındaki başka siteleri otomatik olarak kapsama almayın.

Yoğun yazılan bir sitede SQL ve dosya kopyasının farklı zamanlardan gelmesi tutarsızlık oluşturabilir. Uygulamanın veri yazma biçimine uygun tutarlılık yöntemi belirleyin. Bakım penceresi veya veritabanının desteklediği tutarlı döküm yaklaşımı değerlendirilir. Yedek dosyasının varlığı yerine döküm işleminin çıkış durumu ve arşivin tamamlanma kaydı kontrol edilmelidir.

Önce sıkıştırın sonra şifreleyin

Dosya türlerinin çoğu zaten sıkıştırılmış medya olabilir; bu nedenle her sitede aynı küçülme oranı beklenmez. Sıkıştırmayı şifrelemeden önce uygulamak anlamlıdır. Şifreli veriyi yeniden sıkıştırmak genellikle ek kazanç sağlamaz. XZ gibi bir yöntem kullanırken paylaşımlı hostingin bellek ve CPU sınırlarını dikkate alın. Daha küçük dosya uğruna günlük görevin zamanında bitmemesi işletim sorununa dönüşür.

Gizlilik için doğrulanmış bir şifreleme aracı veya gözden geçirilmiş bir paketleme tasarımı kullanın. Kimlik doğrulamalı şifreleme, değişiklik tespitini de ele alır. Kendi şifreleme algoritmanızı tasarlamayın. Şifre çözme anahtarının tek kopyasını aynı hostingde veya aynı Drive klasöründe tutmayın; erişim kaybı senaryosunda kurtarılabilen ayrı güvenli kopyası bulunmalıdır.

Uzak aktarımı silme işleminden ayırın

Rclone copy hedefteki ilgisiz dosyaları silmez; sync ise kaynağa eşitlemek için hedefte silme yapabilir. Günlük tarihli yedek biriktiren işte bu fark önemlidir. Aşağıdaki komut yalnızca deneme planını gösterir. Remote adı önceden dar kapsamlı yetkiyle hazırlanmış, dizindeki dosyalar da önceden şifrelenmiş olmalıdır. Düz metin wp-config.php veya açık SQL dosyası bu aktarıma yanlışlıkla dahil edilmemelidir.

rclone copy ./sifreli-paketler bydrive:Site-Yedekleri/2026-11-03 \
  --checksum --dry-run
rclone check ./sifreli-paketler bydrive:Site-Yedekleri/2026-11-03 \
  --one-way

Aktarım kabulünü ayrı bir aşama yapın

Deneme çıktısı beklendiği gibi olduktan sonra onaylı görevin gerçek aktarımı yapması gerekir. Yükleme sonrasında dosyanın hedef hesabı, özel paylaşım durumu, boyutu ve sunulan özet değeri incelenir. Rclone check kaynak ve hedefi değiştirmeden karşılaştırma yapabilir. Ortak özet bulunmayan arka uçlarda indirilerek karşılaştırma seçeneğinin ağ ve süre maliyeti ayrıca değerlendirilir.

Boyut eşitliği tek başına içerik eşitliği değildir. Taşıma kontrolündeki MD5 değeri ile saldırgana karşı kriptografik özgünlük iddiasını karıştırmayın. SHA-256 kaydının güvenilir kaynağı ve şifreleme paketinin kimlik doğrulama sonucu birlikte ele alınmalıdır. Bir hata durumunda başarılı bildirim üretmeyin; yerel yedeği koruyup hangi aşamanın durduğunu raporlayın.

Gerçek bir geri dönüş provası yapın

Drive’daki gerçek paketi indirip doğrulamak, yüklemeden önceki yerel dosyayı açmaktan daha güçlü bir kabul adımıdır. Arşiv yapısını, şifre çözme işlemini ve her içerik parçasının bütünlüğünü kontrol edin. Ardından ayrı ve erişimi sınırlı bir test ortamında veritabanı ile dosyaları birlikte değerlendirin. Bu ortamdan müşterilere e-posta çıkmaması ve dış entegrasyonlara gerçek işlem gönderilmemesi gerekir.

İnternet yayınına doğrudan geri yükleme yaparak test etmeyin. Giriş, içerik, medya ve gerekli uygulama işlevleri için kabul listesi hazırlayın. Hedef kurtarma süresi ve kabul edilebilir veri kaybı aralığını iş gereksinimi belirler; bir teknik yazıdan rastgele değer alınmamalıdır. Testten sonra açık SQL ve çözülmüş özel ayarların kontrollü biçimde kaldırılmasını da planlayın.

Bildirim ve saklama kararlarını sade tutun

Tek günlük başarı bildirimi; tarih, paket boyutu, doğrulama sonucu ve özel dosya bağlantısı içerebilir. Aynı gün tekrar çalışan görevin aynı bildirimi yeniden göndermemesi için işlem kimliği veya gün bazlı kayıt tutulur. SMTP kabulü ile gelen kutusuna teslim farklı kanıtlardır. Hata uyarıları başarı bildiriminden ayrılmalı; otomasyon sessizce başarısız olmamalıdır.

Yerel ve uzak saklama sürelerini ayrı belirleyin. Uzak kopya politikasını doğrulamadan yerel yedeği temizlemeyin. Geri dönüşte hangi dosyanın kullanılacağı, anahtara kimlerin ulaşabileceği ve yetkinin nasıl iptal edileceği belgelenmelidir. Bu düzen silinemez veya çevrimdışı bir yedeğin yerine otomatik olarak geçmez; hesap ele geçirilmesi ve yanlış silme gibi senaryolar için ek dayanıklılık seçenekleri değerlendirilir.

İlgili rehberler

• Drive yetkisinin yaşam döngüsü
• Snapshot ile yedeğin farkı