Çoğu satıcı hosting panelindeki "Yedekle" butonunu görür ve rahatlar. Panel her gece bir arşiv üretiyorsa veri güvende sayılır, öyle değil mi? Değil. O buton çoğu zaman aynı diskte, aynı sunucuda, aynı hesabın altında bir kopya bırakır. Disk arızalanırsa, hesap askıya alınırsa ya da bir saldırgan panele girip rm -rf çekerse yedek de gider. Aynı sepette taşınan ikinci yumurta, yedek değildir.
İkinci ve daha sinsi mesele şu: bir e-pin scripti sıradan bir tanıtım sitesi değildir. İçinde para değeri taşıyan kod stokları, teslim edilmiş sipariş kayıtları, bayi bakiyeleri ve tedarikçi anahtarları bulunur. Burada veri kaybı sadece "siteyi yeniden kurarım" meselesi değil, doğrudan müşteriye borçlanmak demektir. Kimin hangi kodu aldığını kanıtlayamazsan hem iadeleri hem itibarını kaybedersin. Bu yazı, bir dijital ürün satış yazılımı için yedekleme otomasyonunu ilk günden doğru kurmanın pratik yol haritasıdır.
Neyi yedeklediğini biliyor musun? Üç ayrı varlık var
Yedekleme planı yapmadan önce sistemi üç parçaya ayırmalısın, çünkü üçünün değişim hızı ve kritikliği tamamen farklıdır. Birincisi veritabanı: siparişler, kullanıcılar, bakiyeler, stok kodları, loglar. Saniye saniye değişir ve en değerli parçadır. İkincisi yüklenen dosyalar: ürün görselleri, faturalar, teslimat dosyaları. Yavaş büyür ama kaybı geri getirilemez. Üçüncüsü kod ve yapılandırma: scriptin kendisi, tema özelleştirmeleri, .env veya config dosyası, .htaccess.
Üçüncü grubun içinde kritik bir ayrıntı saklı: yapılandırma dosyasındaki şifreleme anahtarı. Olgun bir epin yazılım kurulumunda stok kodları veritabanında düz metin tutulmaz, uygulama anahtarıyla şifrelenir. Veritabanını yedekleyip anahtarı yedeklemezsen, geri yüklediğinde elinde okunamayan bir şifreli metin yığını kalır. Bu tuzağa düşenlerin sayısı sandığından fazladır ve genellikle taşınma gecesinde fark edilir.
| Varlık | Önerilen sıklık | Saklama süresi | Kayıp maliyeti |
|---|---|---|---|
| Veritabanı (tam döküm) | Günde 1 (gece) | 30 gün | Kritik: sipariş ve bakiye geçmişi |
| Veritabanı (artımlı / binlog) | 15 dakika | 7 gün | Kritik: son saatlerin siparişleri |
| Yükleme klasörü (uploads) | Günde 1 | 14 gün | Yüksek: faturalar, görseller |
| Kod ve tema | Her değişiklikte | Sürüm bazlı, süresiz | Orta: yeniden kurulabilir ama zaman kaybı |
| Yapılandırma ve anahtarlar | Her değişiklikte | Süresiz, ayrı kasada | Kritik: olmazsa veri okunamaz |
| Sunucu ayarları (cron, SSL, mail) | Haftalık not | Güncel sürüm | Düşük: yeniden kurulur |
Veritabanı dökümünü yanlış alıyorsan yedek zaten bozuk
Basit bir mysqldump veritabani > yedek.sql komutu, yoğun bir panelde tutarsız yedek üretebilir. Döküm sürerken yeni bir sipariş düşerse, siparişler tablosu ile stok tablosu farklı anlara ait olur; geri yüklediğinde teslim edilmiş ama stokta hâlâ duran kodlarla karşılaşırsın. Doğru komut InnoDB tabloları için şudur: mysqldump --single-transaction --quick --routines --triggers --events --default-character-set=utf8mb4 veritabani | gzip > /yol/yedek/db-$(date +%F-%H%M).sql.gz.
Buradaki --single-transaction, tabloları kilitlemeden tek bir anlık görüntü alır; site yavaşlamaz ve veri tutarlı kalır. --routines --triggers olmadan saklı yordamlar ve tetikleyiciler kaybolur, geri yükleme sonrası "her şey var ama bazı hesaplamalar çalışmıyor" tablosu çıkar. utf8mb4 belirtmezsen Türkçe karakterler ve emoji içeren müşteri notları bozulur. Son olarak parolayı komut satırına yazmak yerine ~/.my.cnf dosyasına koy ve dosyayı 600 izniyle kilitle; aksi halde parolan sunucu süreç listesinde herkese görünür.
Gerçek dünyada veri kaybının nedenleri
- İnsan hatası, yanlış silme 35%
- Sunucu ve disk arızası 30%
- Güncelleme veya göç hatası 25%
- Saldırı ve fidye yazılımı 10%
Dış konum: aynı sunucudaki dosya yedek değildir
Yedeğin ilk kopyası hızlı erişim için sunucuda kalabilir, ama en az bir kopya başka bir sağlayıcıda durmalı. Pratikte üç seçenek işini görür: nesne depolama (S3 uyumlu kovalar), ikinci bir sunucuya rsync veya şifreli arşivleri saklayan bir yedekleme servisi. Kritik kural, uzak hedefin sunucudan silinemez olmasıdır. Sunucuya giren saldırgan aynı kimlik bilgileriyle uzaktaki arşivleri de siliyorsa, dış konum sadece coğrafi bir yanılsamadır.
Bunu çözmenin yolu sürüm koruması ve tek yönlü izindir. Nesne depolamada "versioning" ve nesne kilidi aç, yükleme yapan anahtara yalnızca yaz yetkisi ver, sil yetkisini verme. Daha basit bir kurulumda uzak sunucuyu çekici (pull) yap: uzak makine SSH ile gelip yedeği alsın, kaynak sunucunun uzağa erişimi hiç olmasın. Böylece kaynak tamamen ele geçse bile arşiv el değmemiş kalır.
Arşivi gpg veya age ile şifrelemek doğrudur; ancak çözme anahtarını aynı arşivin yanına koymak, kasayı kilitleyip anahtarı kapının üstüne bırakmaktır. Anahtarı ayrı bir parola yöneticisinde ve çevrimdışı bir kopyada tut. Uygulamanın kendi şifreleme anahtarı için de aynı kural geçerlidir: onsuz stok kodların kalıcı olarak okunamaz hale gelir.
Saklama politikası olmadan disk dolar, yedek durur
Otomasyonu kuran çoğu kişi silme kuralını yazmayı unutur. İlk üç hafta her şey güzel gider, sonra disk dolar, mysqldump yarıda kesilir ve sistem her gece 0 baytlık bir dosya üretmeye başlar. Klasörde 40 dosya vardır, hepsi boştur, kimse bakmaz. Bu senaryo, hiç yedek almamaktan daha tehlikelidir çünkü sana yanlış bir güven verir.
Bu yüzden döngüsel (rotational) bir politika yaz: son 7 günün günlük yedeği, son 4 haftanın haftalık yedeği, son 12 ayın aylık yedeği. Temizlik komutunu yedekleme betiğinin sonuna değil, başına koy; böylece yeni dosya için yer açılmış olur. Ayrıca her arşiv üretildikten sonra boyutunu ve bütünlüğünü doğrula: gzip -t dosya.sql.gz ile sıkıştırma testi yap, boyut önceki günün yüzde ellisinin altındaysa alarm üret. Boyut düşüşü, sessizce bozulan bir yedeğin en erken sinyalidir.
Test edilmemiş yedek yoktur: geri yükleme provası
Sektörde acı bir gerçek vardır: insanlar yedeklemeyi kurar, geri yüklemeyi hiç denemez. İlk deneme, gerçek felaketin ortasında, müşteriler yazarken yapılır ve tam o anda kodlamanın bozuk olduğunu, tabloların eksik olduğunu ya da anahtarın kayıp olduğunu öğrenirsin. Bunu önlemenin tek yolu ayda bir prova yapmaktır: yedeği ikinci bir alt alan adına veya yerel bir ortama yükle, panele gir, bir siparişin detayına bak, şifreli bir stok kodunun düzgün çözüldüğünü doğrula.
Prova aynı zamanda süreyi ölçmenizi sağlar. "Yedeğim var" demek yeterli değil; "sıfırdan 40 dakikada ayağa kalkarım" demek gerekir. Bu süreyi kısaltmak için kurulum notlarını, cron satırlarını ve DNS adımlarını tek bir kurtarma dosyasında tut. Pinova tarafında kurulum ve yapılandırma adımlarının belgelenmiş olması bu süreyi belirgin biçimde düşürür; sistemin kapsamını özellikler sayfasından, sürüm ve destek seçeneklerini fiyat bölümünden görebilirsin.
| Kurulum adımı | Doğrulama yöntemi | Başarılı sayılma ölçütü | Öncelik |
|---|---|---|---|
| Tutarlı DB dökümü | --single-transaction parametresi var mı? | Site yavaşlamadan arşiv üretiliyor | P0 |
| Arşiv bütünlüğü | gzip -t testi otomatik koşuyor | Bozuk arşivde uyarı geliyor | P0 |
| Dış konum kopyası | Uzak kovada dosya listesi kontrolü | Son 24 saatlik kopya mevcut | P0 |
| Silme yetkisi kısıtlaması | Sunucudan uzak dosya silmeyi dene | İşlem reddediliyor | P0 |
| Anahtar yedeği | Parola yöneticisinde kayıt var mı? | Arşivden bağımsız erişilebilir | P0 |
| Saklama politikası | Klasördeki dosya sayısını say | Sınır aşılmıyor, disk dolmuyor | P1 |
| Boyut sapma alarmı | Önceki günle karşılaştırma | %50 düşüşte bildirim | P1 |
| Aylık geri yükleme provası | Test ortamına yükleme | Panel açılıyor, kodlar çözülüyor | P1 |
Yedekleme ve kurtarmayı baştan düşünülmüş bir altyapı ile başla
Pinova, yapılandırma ayrımı, şifreli stok yönetimi ve belgelenmiş kurulum akışıyla hem yedeklemeyi hem geri dönüşü basitleştirir.
Hosting firmamın otomatik yedeği yeterli değil mi?
Genellikle değil. Sağlayıcı yedekleri çoğu zaman aynı altyapıda tutulur, saklama süresi kısadır ve hesap askıya alınırsa erişemezsin. Onu birinci katman say, kendi dış konum kopyanı ikinci katman olarak mutlaka kur.
Veritabanını ne sıklıkla yedeklemeliyim?
Günde bir tam döküm taban çizgisidir. Günlük sipariş hacmin yükseldikçe artımlı yedek veya binlog arşivi ekleyerek kayıp penceresini 15 dakikaya indir. Ölçüt şudur: kaç dakikalık siparişi kaybetmeyi kabul edebilirsin?
Yedekleri şifrelemek zorunda mıyım?
Dış konuma çıkan her arşiv şifrelenmelidir, çünkü içinde müşteri bilgileri ve stok kodları vardır. Şifreleme anahtarını arşivden ayrı, parola yöneticisinde ve çevrimdışı bir kopyada tut; anahtarsız yedek işe yaramaz.
Geri yükleme provasını canlı sitede yapabilir miyim?
Hayır, asla. Prova için ayrı bir alt alan adı veya yerel bir ortam kullan; test veritabanını farklı isimle oluştur. Canlı üzerinde denemek, kurtarmaya çalıştığın veriyi kaybetme riskini doğurur.
Yedekleme, e-pin işinde ödeme geçidi kadar temel bir altyapı parçasıdır; farkı, işe yarayıp yaramadığını sadece en kötü günde öğrenmendir. Bu yüzden ilk kurulumda tutarlı döküm, dış konum, kısıtlı silme yetkisi, anahtar ayrımı ve aylık prova beşlisini tamamla. Bu disiplinin üstüne oturan bir e-pin satış yazılımı görmek istiyorsan canlı demo içinde sipariş, stok ve yapılandırma katmanlarının nasıl ayrıldığını inceleyip kendi kurtarma planını bu yapıya göre yazabilirsin.