Ne Sıklıkta Yedek Alınmalı? Site Tipine Göre Yedekleme Planı

Ne sıklıkta yedek alınmalı sorusuna Türkçe kaynakların verdiği cevap neredeyse her zaman aynı: "düzenli olarak yedek alın." Bu cümle hiçbir işe yaramaz, çünkü "düzenli" ne demek olduğunu söylemiyor. Yılda iki kez telefon numarası güncellenen bir kurumsal tanıtım sitesiyle saatte 40 sipariş alan bir mağazanın yedekleme planı aynı olamaz; birincisinde günlük yedek boşuna kaynak harcamak, ikincisinde günlük yedek kabul edilemez bir kayıp riskidir.

Bu yazıda yedekleme sıklığını tahminle değil hesapla belirliyoruz. Cevap tek bir sayıda değil, iki soruda saklı: kaç saatlik veri kaybını kabul edebilirsiniz ve siteniz çöktüğünde ne kadar sürede ayağa kalkması gerekiyor. Bu iki soruyu somut örneklerle cevaplayıp blog, kurumsal site, üyelikli portal ve e-ticaret için hazır planlar, dosya ile veritabanının neden ayrı sıklıkta yedeklenmesi gerektiği ve sıklığı artırırken diski patlatmamanın yolu olan saklama politikasını ele alıyoruz.

Sıklığı Belirleyen Tek Soru: Kaç Saatlik Kaybı Kabul Edersiniz#

Yedekleme sıklığı, kaybetmeye razı olduğunuz süreye eşittir; bundan daha karmaşık bir formül yoktur. Gecelik yedek alıyorsanız en kötü senaryoda 24 saatlik veri kaybedersiniz, çünkü çöküş bir sonraki yedeğin hemen öncesinde olabilir.

Bu süreye kurtarma noktası hedefi denir. Yanında ikinci bir ölçü daha vardır: sitenin yeniden ayağa kalkması için geçen süre. İkisi farklı şeylerdir ve farklı çözümleri vardır:

Bu ayrım pratikte şuna benzer: 40 GB'lık bir arşivi gece 3'te alıyor olabilirsiniz (veri kaybı 24 saat), ama o arşiv uzaktaki bir depolamada duruyorsa indirmek 3 saat sürer (kesinti 3+ saat). Sıklığı artırmak ikinci sorunu çözmez; onun için yedeğin nerede durduğu ve ne kadar hızlı açıldığı önemlidir.

Kendinize sorulacak somut soru şudur: "Şu an her şey silinse, son yedekten bu yana kaybettiklerimi yeniden üretmek kaç saatimi alır ve bunun bedeli nedir?" Cevap "bir gün blog yazısı yazarım" ise haftalık yedek yeterlidir. Cevap "18 siparişin kime gittiğini bilemem" ise saatlik yedek bile geç kalmış olabilir.

Dosyalar ve Veritabanı Ayrı Sıklıkta Yedeklenmeli#

Bu, sıklık kararının en çok gözden kaçan ve en çok kaynak tasarrufu sağlayan kısmıdır: bir web sitesinde dosyalar ve veritabanı tamamen farklı hızlarda değişir, dolayısıyla aynı takvimde yedeklenmeleri için hiçbir sebep yoktur.

Dosyalar (tema, eklenti, wp-content/uploads, statik dosyalar) yalnızca siz müdahale ettiğinizde değişir: güncelleme yaptığınızda, yeni görsel yüklediğinizde, tema düzenlediğinizde. Boyutları büyüktür — çoğu WordPress sitesinde toplam boyutun %90'ından fazlası buradadır.

Veritabanı ise siz uyurken bile değişir: yeni yorum, yeni üye kaydı, yeni sipariş, iletişim formu kaydı, WooCommerce stok hareketi. Boyutu genellikle küçüktür; 5.000 ürünlü bir mağazada bile sıkıştırılmış dökümü birkaç yüz megabaytı geçmez.

Sonuç: veritabanını sık, dosyaları seyrek yedekleyin. 12 GB'lık bir siteyi saatte bir yedeklemek sunucuyu dize getirir; aynı sitenin 180 MB'lık veritabanını saatte bir yedeklemek fark edilmez bile.

Veritabanının tek başına dökümünü almak komut satırında tek satırdır:

mysqldump -u kullanici -p --single-transaction --quick veritabani_adi | gzip > db-$(date +%F-%H%M).sql.gz

--single-transaction parametresi InnoDB tablolarında tabloları kilitlemeden tutarlı bir döküm alır; bu olmadan yoğun bir mağazada yedek sırasında site kısa süreli takılabilir. Bu komutun ayrıntıları ve geri yükleme tarafı için mysqldump ile veritabanı yedekleme yazısına bakın.

Site Tipine Göre Hazır Yedekleme Planları#

Aşağıdaki tablo, sahada işe yarayan başlangıç planlarıdır. Kendi durumunuza en yakın satırdan başlayıp gerekirse sıkılaştırın.

Birkaç satırı açalım.

Statik tanıtım sitesi. Yılda iki kez telefon numarası değişen bir siteyi her gece yedeklemek, 365 tane birbirinin aynı arşiv üretir. Burada doğru yaklaşım aylık bir rutin artı her değişiklikten hemen önce manuel bir yedektir. Asıl risk zamanla gelen veri kaybı değil, sizin yaptığınız bir düzenlemedir.

Kurumsal site. İletişim formundan gelen talepler veritabanında durur ve bunlar müşteri adayıdır. Dosyalar haftalık yeter ama veritabanı günlük olmalı; aksi hâlde bir hafta boyunca gelen formları kaybedersiniz.

Üyelikli portal. Kullanıcılar içerik üretir, yorum yazar, profil günceller. Bir günlük kaybı kullanıcıya açıklamak zordur; 6 saatlik pencere makul bir dengedir.

E-ticaret. Burada kayıp doğrudan paradır ve daha kötüsü, hukuki bir sorumluluktur. Ödemesi alınmış ama veritabanında kaydı olmayan bir sipariş, müşteriye ulaşmayan bir üründür. Bu yüzden mağazalarda veritabanı sıklığı saatlik seviyeye çekilir; dosya tarafı ise ürün görselleri dışında neredeyse hiç değişmediği için günlükte kalabilir.

Sürekli yedek (binlog). Saatlik bile yetmiyorsa MySQL'in ikili günlük (binary log) mekanizmasıyla noktadan kurtarma yapılır: gecelik tam yedek + o andan itibaren tüm işlemlerin günlüğü. Böylece "dün gece 03:00 yedeği + bugün 14:22'ye kadarki işlemler" şeklinde neredeyse kayıpsız dönüş mümkün olur. Bu, kendi sunucunuz olduğunda uygulanabilir bir yöntemdir.

İçerik Değişim Hızını Nasıl Ölçersiniz#

Tahmin yerine ölçün: veritabanınızın gerçekten ne kadar hızlı değiştiğini birkaç sorguyla görebilirsiniz.

Son 24 saatte kaç kayıt eklendiğini WordPress'te şöyle görürsünüz:

SELECT COUNT(*) FROM wp_posts
WHERE post_date > NOW() - INTERVAL 1 DAY;

SELECT COUNT(*) FROM wp_comments
WHERE comment_date > NOW() - INTERVAL 1 DAY;

WooCommerce siparişleri için:

SELECT DATE(post_date) AS gun, COUNT(*) AS siparis
FROM wp_posts
WHERE post_type = 'shop_order'
  AND post_date > NOW() - INTERVAL 30 DAY
GROUP BY gun
ORDER BY gun DESC;

Bu sorgunun çıktısı size doğrudan planı verir. Günde ortalama 3 sipariş görüyorsanız günlük yedekte kaybınız 3 siparişle sınırlıdır ve telefonla telafi edilebilir. Günde 150 sipariş görüyorsanız aynı plan 150 siparişlik bir kaosa denk gelir.

Dosya tarafında ise son bir haftada kaç dosyanın değiştiğine bakın:

find ~/public_html -type f -mtime -7 | wc -l
find ~/public_html -type f -mtime -7 -printf '%TY-%Tm-%Td %p\n' | sort | tail -20

Çıkan sayı sadece önbellek ve log dosyalarından ibaretse dosya yedeğinizi seyrekleştirebilirsiniz; uploads altında düzenli yeni görseller varsa sıklaştırın.

Sıklığı Artırırken Diski Patlatmamak: Saklama Politikası#

Sıklığı artırmanın bedeli disktir ve bu bedel kontrol edilmezse yedekleme sisteminin kendisi siteyi çökertir. Saatlik yedek alıp hepsini saklarsanız ayda 720 arşiv birikir.

Çözüm, sıklık ile saklama süresini birbirinden ayıran kademeli bir politikadır. Klasik ve işe yarayan model:

• Son 24 saatin saatlik yedekleri (24 kopya)
• Son 7 günün günlük yedekleri (7 kopya)
• Son 4 haftanın haftalık yedekleri (4 kopya)
• Son 12 ayın aylık yedekleri (12 kopya)

Bu, toplam 47 kopyayla hem "bir saat öncesine dön" hem de "sekiz ay öncesine dön" ihtiyacını karşılar. Sekiz ay önceki bir kopyaya neden ihtiyaç duyarsınız? Çünkü bazı hasarlar hemen fark edilmez: siteye aylar önce yerleştirilmiş bir arka kapı ya da yavaş yavaş bozulan bir veritabanı tablosu, ancak geç fark edilir ve o zamana kadar tüm yakın yedekler zaten bozulmuş kopyayı içerir.

Disk hesabı yapmak için kaba formül:

Toplam alan ≈ (dosya yedeği boyutu × dosya kopya sayısı)
            + (veritabanı yedeği boyutu × veritabanı kopya sayısı)

2 GB'lık bir dosya arşivi ve 150 MB'lık bir veritabanı dökümü için 7 günlük + 4 haftalık dosya, 24 saatlik + 30 günlük veritabanı planı:

2 GB × 11  = 22 GB
150 MB × 54 = ~8 GB
Toplam     ≈ 30 GB

Disk maliyetini düşürmenin en etkili yolu artımlı yedektir: yalnızca değişen blokları saklayan araçlarla aynı geçmiş çok daha az yerle tutulur. 47 kopyalık bir plan tam arşivle 90 GB isterken, artımlı yöntemle çoğu sitede bunun beşte birine sığar.

Anlık Görüntü ile Yedeğin Sıklığı Aynı Şey Değildir#

VDS kullanıcılarının en sık yaptığı hata, "günde bir snapshot alıyorum" deyip yedek planını tamamlanmış saymaktır. Anlık görüntü genellikle sunucunun kendi depolama altyapısında durur; sunucu ya da o depolama katmanı kaybedilirse anlık görüntü de kaybedilir.

Doğru kurgu ikisini birlikte kullanmaktır: sık anlık görüntü (hızlı geri dönüş için, örneğin güncelleme öncesi) ve daha seyrek ama dışarıda duran gerçek yedek (felaket için). İkisinin farkını snapshot mı yedek mi yazısında ayrıntılı karşılaştırıyoruz.

Aynı mantık paylaşımlı hostingde sağlayıcının aldığı yedekler için de geçerlidir: sağlayıcı yedeği bir felaket kurtarma önlemidir, sizin arşiviniz değildir ve genellikle sınırlı bir süre saklanır. Bu ayrımın pratik sonuçlarını hosting yedeği mi kendi yedeğim mi yazısında ele alıyoruz.

Takvim Dışı Yedekler: Değişiklikten Önce Mutlaka#

Planlı sıklık, planlı olmayan riskleri kapsamaz. Aşağıdaki durumların her birinde, takvim ne derse desin manuel yedek alın:

1. WordPress çekirdek sürümü yükseltmeden önce
2. Tema veya eklenti güncellemesinden önce (özellikle ana sürüm atlamalarında)
3. PHP sürümü değiştirmeden önce
4. Alan adı ya da sunucu taşımadan önce
5. Veritabanında toplu değiştirme (search & replace) yapmadan önce
6. Ödeme altyapısı ya da kargo entegrasyonu ayarlarını değiştirmeden önce
7. Yeni bir geliştiriciye erişim vermeden önce

Bu liste tecrübeyle uzar. Yıllardır gördüğüm veri kayıplarının çoğu sunucu arızasından değil, "küçük bir güncelleme" sonrası açılmayan siteden çıkıyor. Manuel yedeğin nasıl alınacağını ve hangi bileşenleri kapsaması gerektiğini site yedeği nasıl alınır yazısında adım adım anlatıyoruz. WordPress tarafında bu takvimi otomatikleştirmek isterseniz UpdraftPlus nasıl kullanılır yazısındaki zamanlama ayarları işinizi görür.

Planın Gerçekten Çalıştığını Doğrulama#

Bir yedekleme planı, geri yükleme testi yapılmadan sadece bir niyet beyanıdır. Sıklığı ne kadar artırırsanız artırın, arşivler bozuksa hiçbir işe yaramaz.

Üç aylık bir doğrulama rutini önerilir:

1. Arşiv listesini kontrol edin. Planlanan sıklıkta gerçekten dosya oluşmuş mu? Tarihler arasında boşluk var mı? Cron çalışmadığında yedekler sessizce durur ve bunu kimse fark etmez.
2. Boyutlara bakın. Veritabanı dökümü her gece aynı boyuttaysa (özellikle şüpheli derecede küçükse) döküm muhtemelen boş çıkıyordur.
3. Bir geri yükleme yapın. Test alt alan adına ya da bir staging ortamına en son yedeği açın. Site açılıyor mu, görseller geliyor mu, son yazı orada mı?

Şu basit kontrol, döküm dosyasının içinde gerçekten veri olup olmadığını saniyeler içinde söyler:

zcat db-2026-08-11-0300.sql.gz | grep -c "INSERT INTO"

Sonuç 0 ise elinizde yalnızca tablo yapısı vardır, tek satır veri yoktur — ve bu, felaket anına kadar fark edilmeyecek türden bir hatadır.

Sıkça Sorulan Sorular#

Günlük yedek her site için yeterli mi#

Günlük yedek çoğu blog ve kurumsal site için yeterlidir ancak e-ticaret ve üyelikli siteler için yetersizdir. Ölçüt basittir: son yedekten bu yana biriken veriyi kaybetseniz ne olur? Bir günlük blog yazısını yeniden yazabilirsiniz, ama bir günlük siparişi hangi müşterinin verdiğini hatırlayamazsınız. Sipariş, üyelik veya form kaydı alan sitelerde veritabanı yedeğini birkaç saatlik aralıklara çekmek, dosya yedeğini ise günlük ya da haftalık bırakmak doğru dengedir.

Haftalık yedek hangi durumlarda yeterli olur#

Haftalık yedek, içeriği kullanıcı etkileşimiyle değil yalnızca sizin müdahalenizle değişen sitelerde yeterlidir. Yılda birkaç kez güncellenen tanıtım siteleri, portfolyo sayfaları ve statik kurumsal siteler bu gruba girer. Ancak bu sitelerde bile iletişim formu kayıtları veritabanında tutuluyorsa veritabanı tarafını günlük yapmak gerekir. Haftalık planın vazgeçilmez tamamlayıcısı, her manuel değişiklikten hemen önce alınan ek yedektir.

Yedek sıklığını artırmak siteyi yavaşlatır mı#

Yedekleme çalıştığı süre boyunca CPU ve disk kullanımı arttığı için site yavaşlayabilir, ancak bu etki neyin yedeklendiğine bağlıdır. Küçük bir veritabanı dökümü saniyeler sürer ve pratikte hissedilmez; buna karşılık gigabaytlarca dosyayı sıkıştırmak paylaşımlı hostingde kaynak limitine takılıp hem yedeği hem siteyi durdurabilir. Bu yüzden sıklığı artırırken dosya ve veritabanını ayırmak, büyük dosya yedeklerini trafiğin en düşük olduğu saatlere almak gerekir.

Kaç adet yedek saklamalıyım#

Yalnızca sıklığa değil, hasarı ne kadar geç fark edebileceğinize göre karar verin. Üç günlük yedek tutuyorsanız beş gün önce bulaşan bir zararlı yazılımı temiz bir kopyaya dönerek temizleyemezsiniz, çünkü elinizdeki tüm kopyalar zaten bulaşmıştır. Kademeli model işe yarar: son günlerin sık kopyaları, son haftaların günlük kopyaları ve son ayların birer kopyası. Böylece hem yakın geçmişe ince ayarla, hem uzak geçmişe makul bir disk maliyetiyle dönebilirsiniz.

Hosting firmam zaten günlük yedek alıyor, ayrıca yedek almalı mıyım#

Almalısınız, çünkü sağlayıcı yedeği bir felaket kurtarma önlemidir ve sizin arşiviniz yerine geçmez. Bu yedekler genellikle sınırlı bir süre saklanır, kapsamı pakete göre değişir ve hesabınız herhangi bir sebeple askıya alınırsa onlara erişiminiz de kesilir. Kendi yedeğiniz ise sizin kontrolünüzdedir, istediğiniz süre saklanır ve sağlayıcıdan bağımsız bir yere kopyalanabilir. İkisi birbirinin alternatifi değil, tamamlayıcısıdır.

Yedekleme sıklığını neye göre artırmalıyım#

Sıklığı artırma kararını hislere değil ölçüme dayandırın: veritabanınızda son 24 saatte kaç yeni kayıt oluştuğunu sorgulayın ve bu kayıtları kaybetmenin bedelini parayla ya da iş yüküyle ifade edin. Bedel, artan yedekleme maliyetinden büyükse sıklığı artırın. Ayrıca sezonluk davranış da önemlidir; kampanya dönemlerinde sipariş hacmi katlanan bir mağaza, o dönemde sıklığı geçici olarak sıkılaştırıp sonra normale dönebilir.

Yedeği aynı sunucuda tutmak sıklık kadar önemli mi#

Daha önemlidir. Saatlik yedek alıyor ama hepsini sitenin bulunduğu sunucuda tutuyorsanız, sunucu kaybında, hesabın askıya alınmasında ya da fidye yazılımı saldırısında tüm kopyalarınız aynı anda gider. Sıklık, veri kaybı penceresini daraltır; yedeğin başka bir yerde durması ise yedeğin var olmaya devam etmesini sağlar. Doğru yaklaşım, sıklığı ihtiyaca göre ayarlarken en az bir kopyayı fiziksel olarak farklı bir ortamda tutmaktır.

Kapanış#

Doğru sıklık, site tipinden çok içeriğinizin değişim hızına ve kaybı telafi etme maliyetine bağlıdır. Veritabanını sık, dosyaları seyrek yedekleyin; sıklığı artırırken saklamayı kademelendirip diski koruyun; takvimin yanına "her değişiklikten önce" kuralını ekleyin ve üç ayda bir gerçek bir geri yükleme testiyle planın çalıştığını kanıtlayın. Bu dört madde, "düzenli yedek alın" öğüdünü ölçülebilir bir plana dönüştürür.

Bu planı kurmak ve her gün çalıştığını takip etmek istemiyorsanız, sunucu tarafında otomatik çalışan ve kopyaları sitenizden bağımsız bir yerde tutan bir yedekleme hizmeti bu işi üstlenir. Sipariş yoğunluğu yüksek mağazalar için altyapı seçerken kaynak ve yedek politikasını birlikte değerlendirmek gerekir; e-ticaret hosting paketleri bu ihtiyaca göre yapılandırılır. Kendi sunucunuzda anlık görüntü ile gerçek yedeği birlikte kurgulamak, saklama politikasını satır satır kendiniz belirlemek istiyorsanız VDS sunucu tarafı bu esnekliği verir.