Panelde "Yedekleme tamamlandı" satırını gördüğün gün rahatladın. Klasörde tarih tarih sıralanmış zip dosyaları var, hosting panelinde de "otomatik yedek aktif" yazıyor. Çoğu satıcı burada işin bittiğini sanır: yedek varsa veri güvende. Oysa yedek almak bir şey, geri yükleyebilmek tamamen başka bir şeydir. Bu ikisi arasındaki farkı çoğu işletme sahibi, sitenin çöktüğü gece saat üçte öğrenir.
Dijital ürün satış scriptinde yedeğin geri yüklenememesi neredeyse hiç tek bir sebepten olmaz. Genelde üst üste binmiş üç dört küçük ihmal vardır: yarım kalmış bir SQL dump, sunucuda kalan ama yedeğe girmeyen bir şifreleme anahtarı, farklı bir MySQL sürümü, bir de kimsenin hiç denemediği bir geri yükleme prosedürü. Bu yazıda o zinciri tek tek söküyoruz. Sonunda elinde "umarım çalışır" değil, provası yapılmış bir kurtarma planı olacak.
Yedek Aldın mı, Yoksa Sadece Dosya Kopyaladın mı?
Bir e-pin satış scripti iki ayrı bacak üzerinde durur: dosya sistemi ve veritabanı. Dosya tarafında tema, eklenti, fatura PDF'leri, ürün görselleri ve yapılandırma dosyaları vardır. Veritabanı tarafında ise siparişler, bakiye hareketleri, stok kodları ve kullanıcı kayıtları oturur. Sadece public_html klasörünü zip'leyip indiren biri, aslında sitenin kabuğunu yedeklemiştir. İçindeki para akışını değil.
Ters durum da aynı derecede sakat. Sadece SQL dump alıp dosyaları atlarsan, geri yüklemede siparişler görünür ama ödeme sağlayıcının sertifika dosyası, yükleme dizinindeki teslimat kanıtları ve özelleştirdiğin şablonlar kaybolur. Müşteri "benim kodum nerede" diye yazdığında elinde bir kayıt satırı olur, kodun kendisi olmaz. Doğru yedek her zaman üç parçalıdır: dosyalar, veritabanı ve webroot dışındaki gizli yapılandırma. Bu üçlüden biri eksikse, elindeki şey yedek değil arşivdir.
Neden Tam Geri Yükleme Anında Her Şey Çöküyor?
Geri yükleme sırasında en sık görülen hata mesajları aslında birer ipucu. Unknown collation: utf8mb4_0900_ai_ci görüyorsan, yedeği MySQL 8 üzerinde aldın ve MariaDB'ye basmaya çalışıyorsun. Cannot add foreign key constraint görüyorsan, dump tablo sırasını korumuş ama FOREIGN_KEY_CHECKS kapatılmamış. MySQL server has gone away görüyorsan sorun yedekte değil, max_allowed_packet değerinde.
Bir başka klasik: phpMyAdmin üzerinden alınan dump'ın zaman aşımına uğrayıp yarıda kesilmesi. Dosya indirilir, boyutu makul görünür, ama son tablo yarım kalmıştır. Bunu anlamanın en hızlı yolu dump'ın son satırına bakmaktır; sağlıklı bir dump genelde -- Dump completed benzeri bir kapanış satırıyla biter. O satır yoksa dosya bozuktur ve aylardır bozuk yedek topluyorsundur. Kontrol etmesi otuz saniye, atlamanın bedeli ise tüm sipariş geçmişin.
| Yedek türü | Neyi kapsar | Geri yükleme süresi | Tipik kırılma noktası |
|---|---|---|---|
| Panel otomatik yedeği | Dosya + DB (çoğunlukla) | 20-60 dakika | Saklama süresi kısa, sadece son 1-2 gün |
| Manuel phpMyAdmin dump | Sadece veritabanı | 10-40 dakika | Zaman aşımında yarım kesilir |
| mysqldump (SSH) | Veritabanı, tam ve tutarlı | 5-15 dakika | SSH erişimi olmayan paketlerde imkânsız |
| FTP klasör kopyası | Sadece dosyalar | 2-6 saat | Binlerce küçük dosyada aktarım kopar |
| Dış depoya artımlı yedek | Üçü birlikte, sürümlü | 15-45 dakika | Anahtar/parola kaybında geri açılamaz |
E-pin Scriptinde Yedeğin En Kritik Tablosu Hangisi?
Bir dijital ürün satış yazılımında tüm tablolar eşit değildir. Ürün açıklamaları yeniden yazılabilir, kategori ağacı yeniden kurulabilir, hatta tema sıfırdan yüklenebilir. Ama stok kodlarının tutulduğu tablo ile bakiye hareketlerinin tutulduğu tablo kaybolursa elinde para kaybı vardır. Müşteri bakiyesi sıfırlanmış bir panel, saatler içinde yüzlerce destek talebine dönüşür.
Bu yüzden yedek stratejisini tek bir sıklıkla kurmak hatalı. Ürün ve içerik tablolarını günde bir kez almak yeterliyken, sipariş ve bakiye tablolarını saatlik almak mantıklıdır. Pinova'da bu ayrım yapılandırılabilir; kritik tabloların ayrı sıklıkta ve ayrı hedefe gönderilmesi, tek bir bozuk dosyanın tüm zinciri düşürmesini engeller. Özellik setini özellikler bölümünden inceleyebilirsin.
Geri yükleme başarısızlıklarının gerçek nedenleri
- Yarım/bozuk SQL dump 45%
- Sürüm ve collation uyuşmazlığı 25%
- Eksik yapılandırma veya anahtar 20%
- Kota, inode ve alan yetersizliği 10%
Şifreleme Anahtarını Yedeklemeyi Unuttun, Değil mi?
Ciddi bir epin yazılım kurulumunda stok kodları veritabanında açık metin durmaz; şifrelenmiş tutulur. Anahtar ise güvenlik gereği webroot dışında, ayrı bir dosyada bekler. Buradaki ironi şu: güvenliği artıran bu yaklaşım, yedek stratejisi eksikse kurtarmayı imkânsız hale getirir. Veritabanını harfi harfine geri yüklesen bile anahtar elinde yoksa, satılmamış tüm kodlar okunamaz veri yığınına dönüşür.
Aynı mantık ödeme sağlayıcı sertifikaları, API imza anahtarları ve .env türü dosyalar için de geçerli. Bunları yedeğe dahil etmek gerekir, ama aynı sunucuda ve aynı klasörde tutmamak gerekir. Pratik yol: anahtar dosyalarının şifreli bir kopyasını tamamen farklı bir yerde, tercihen kendi bilgisayarında ve bir parola yöneticisinde tutmak. Anahtarın kopyası olmayan bir yedek, kilitli bir kasayı kamyona yükleyip anahtarı yanan binada bırakmaktır.
Dump dosyasının son 20 satırına bak. Kapanış satırı yoksa dosya yarım kesilmiştir; boyut büyük olsa bile güvenmemelisin.
Hosting Firmasının Yedeği Seni Kurtarır mı?
Paylaşımlı hosting sözleşmelerinde yedek çoğu zaman "iyi niyet" maddesidir; garanti değildir. Saklama süresi genelde bir ila yedi gün arasındadır ve bu, sessiz bir veri bozulmasını yakalamak için fazlasıyla kısa. Bir stok tablosu on gün önce bozulduysa, firmanın elindeki tüm kopyalar da bozuktur. Ayrıca geri yükleme talebi bir destek kaydına bağlıdır; yoğun bir cuma akşamı bu birkaç saat bekleme anlamına gelir.
Buradaki doğru yaklaşım firmanın yedeğini reddetmek değil, ona tek dayanak olarak güvenmemek. Sunucu yedeği en hızlı kurtarma katmanıdır; kendi aldığın haftalık arşiv ise en derin katmandır. İkisini birlikte kullanan satıcılar, hem iki saatlik bir hatadan hem de iki ay önce başlamış bir bozulmadan dönebilir.
Geri Yükleme Provası Yapmadıysan Yedeğin Yok
Bu cümle sert ama pratikte tam olarak böyle. Prova yapılmamış bir yedek, test edilmemiş bir yangın tüpüdür. Provanın maliyeti çok düşük: alt alan adı açarsın, boş bir veritabanı oluşturursun, son yedeği oraya yüklersin ve üç şeyi kontrol edersin. Panele giriş yapılıyor mu, son sipariş görünüyor mu, bir test kodunu çözebiliyor musun. Bu üçü geçtiyse yedeğin gerçekten var.
Provayı üç ayda bir takvime almanı öneririm. Yılda dört kez, yarım saatlik bir iş. Karşılığında ise gece yarısı çöken bir kurulumda ne yapacağını bilerek hareket edersin. Fiyatlandırma ve kapsam karşılaştırması için fiyat bölümüne göz atabilirsin.
| Kontrol | Nasıl doğrularsın | Sıklık | Geçti mi? |
|---|---|---|---|
| Dump bütünlüğü | Dosya sonundaki kapanış satırı var mı | Her yedekte | Evet / Hayır |
| Şifre anahtarı kopyası | Sunucu dışında erişilebilir mi | Aylık | Evet / Hayır |
| Kritik tablolar | Sipariş, bakiye, stok satır sayısı tutuyor mu | Haftalık | Evet / Hayır |
| Sürüm uyumu | Hedef MySQL/PHP sürümü kaynakla eşleşiyor mu | Her taşımada | Evet / Hayır |
| Dış kopya | Yedek aynı diskin dışında mı | Haftalık | Evet / Hayır |
| Tam prova | Alt alan adında geri yükleme denemesi | 3 ayda bir | Evet / Hayır |
Yedek stratejisini şansa bırakma
Pinova, kritik tabloları ayrı sıklıkta yedekleyen ve geri yükleme provasını kolaylaştıran bir dijital ürün satış scripti altyapısı sunar.
Yedek dosyam açılıyor ama siteye yüklenince bakiyeler sıfır görünüyor, neden?
Büyük olasılıkla bakiye hareketleri ayrı bir tabloda tutuluyor ve dump sırasında o tablo zaman aşımı yüzünden eksik alındı. Satır sayılarını kaynak ile karşılaştır; fark varsa dump'ı SSH üzerinden tekrar al.
E-pin kodlarını yedekten geri aldım ama okunamıyor, kurtarma şansı var mı?
Kodlar şifreli tutuluyorsa, şifreleme anahtarı olmadan çözüm yok. Anahtarın eski sunucuda kalmış bir kopyası varsa hâlâ şans var; yoksa satılmamış stoğu tedarikçiden yenilemek gerekir.
Hosting firmasının yedeği yeterli değil mi?
Hızlı kurtarma için iyidir ama saklama süresi kısa olduğu için haftalar önce başlayan bozulmaları yakalamaz. Kendi haftalık arşivinle birlikte kullanmalısın.
Geri yükleme provasını canlı sitede yapabilir miyim?
Yapmamalısın. Alt alan adı ve boş bir veritabanı kullan; canlı veriyi asla hedef olarak seçme, yanlış bir komut mevcut siparişleri silebilir.
Yedek meselesi teknik bir konu gibi görünür ama aslında bir işletme kararıdır: bir gecelik veri kaybını kaldırabilir misin, kaldıramaz mısın. Kaldıramıyorsan üç parçalı yedek, sunucu dışında bir kopya ve üç ayda bir prova senin asgari standardın olmalı. Pinova'nın bu akışı nasıl yönettiğini kendi gözünle görmek istersen canlı demo üzerinden panele girip yedek ve kurtarma ekranlarını rahatça dolaşabilirsin.