cPanel Yedekleme ve Geri Yükleme Rehberi – 7 Püf Noktası

Öne Çıkanlar

• cPanel’de hem full hem kısmi yedek stratejisi belirlemek; ne zaman hangi yedeğin kullanılacağını bilmek kurtarıcıdır.
• Yedek alma işlemi kaynak tüketir — backup’ları yönetmek, eski yedekleri harici depolamaya taşımak performans ve süreklilik sağlar.
• Güvenlik (firewall, SSH anahtarları, SFTP/FTPS) ve yazılım uyumluluğu (PHP/MySQL sürümleri) geri yükleme başarısını doğrudan etkiler.
• Otomatikleştirme ve düzenli test (staging üzerinde geri yükleme) en kritik adımlardır; “aldım” demek yetmez, geri yüklenebilir olmalı.

cPanel’de Yedekleme ve Geri Yükleme Rehberi dendiğinde akla gelen ilk şey aslında şu basit korku: “Ya hosting firması bir hata yaparsa, ya dosyaları yanlışlıkla silersem, ya sunucu çökerse?” Bir güncelleme yaparsın, eklenti çakışır, veri tabanı bozulur, sabaha kadar log kovalar, sonra fark edersin: Asıl kurtarıcı, geceden alınmış sağlam bir full backup’mış. İşin güzel tarafı, cPanel bu işi sandığından çok daha kolay hale getiriyor; ama yanlış bir ayar veya eksik bir geri yükleme adımı tüm işi boşa çıkarabiliyor. Bu rehberde, hem ilk defa cPanel gören kullanıcıya hem de SSH’ta “screen” ile yaşayanlara hitap ederek, mantığıyla birlikte gideceğiz: Yedeği nerede, ne sıklıkla, nasıl almalı ve ne zaman hangi geri yükleme yöntemini kullanmalı?

cPanel’de Yedekleme ve Geri Yükleme Rehberi Hakkında Bilmeniz Gerekenler

Şöyle düşünün: Siteniz bir araba, hosting ise garaj. Yedekleme de, arabanın pert olma ihtimaline karşı yaptığınız kasko gibi. Yıllarca belki hiç ihtiyaç duymazsınız ama bir gün lazım olduğunda, “Keşke” dememek için önceden hazırlanmış olmanız gerekir. cPanel’de Yedekleme ve Geri Yükleme Rehberi mantığının temelinde bu var: En kötü senaryoya göre plan yapmak.

Genelde kullanıcılarımızdan duyduğumuz en büyük cümle şu oluyor: “Sunucu zaten RAID’li, hosting firması yedek aldığını söylüyor, benim ayrıca yedek almama gerek var mı?” Aslında durum tam olarak şöyle: Evet, iyi bir hosting sağlayıcı altyapısal yedek alır ama bu, yanlışlıkla sildiğiniz wp-content/uploads klasörü için her zaman bire bir geri dönüş anlamına gelmeyebilir. Hele ki bir eklenti sitenizi bozduysa ve siz fark etmeden üzerine veri yazdıysanız, iş iyice karışır.

Bir de yaygın bir efsane var: “Full backup alırsam, her şeyi saniyeler içinde geri yüklerim.” Teoride doğru gibi görünse de pratikte, hesabın büyüklüğüne, e-posta kutularına, veritabanı boyutuna ve hatta DNS yapılandırmasına kadar birçok faktör devreye girer. Full backup hayat kurtarır; ama bazen sadece veritabanı yedeği ya da bir klasör yedeği ile dakikalar içinde işi çözmek çok daha hızlı ve temizdir. İşin püf noktası şurada: Ne zaman full yedek, ne zaman kısmi yedek kullanacağını bilmek.

Yapılandırma ve Yönetim: Adım Adım

Kaynak Yönetimi – Limitleri Zorlamayın

cPanel üzerinden yedekleme alırken arka planda ciddi I/O ve CPU kullanımı oluşur. Özellikle paylaşımlı hosting kullanıyorsanız, “Yedeği bas geç” mantığı bazen aynı sunucudaki diğer siteleri de etkileyebilir ve hosting firmanızdan “Aşırı kaynak kullanımı” uyarısı alırsınız. Dürüst olmak gerekirse, çoğu kullanıcı bu uyarıyı alınca önce eklentileri suçluyor ama büyük boyutlu backup dosyaları da masum değil.

İşin mantığı şöyle: Full backup alırken cPanel, home dizininizi, veritabanlarınızı, e-postalarınızı, DNS ayarlarınızı tek tek paketler. Bu süreçte en çok zorlanan kısım disk I/O olur. Çok sık veya yoğun trafik anında backup almak, özellikle HDD diskli sistemlerde, sitenizin yavaşlamasına neden olabilir. Mümkünse yedekleme saatlerini, trafiğin görece düşük olduğu zaman dilimlerine denk getirin.

“Aşırı kaynak kullanımı” uyarısı geldiğinde panik yapmadan önce kontrol edilecek ilk dosya genellikle error_log değil, home dizininizdeki devasa boyutlu backup-*.tar.gz dosyaları olmalı. Bir bakmışsınız, aylarca manuel yedek almışsınız ama eski yedekleri silmeyi unutmuşsunuz; disk dolmuş, MySQL yazamıyor, siteler patır patır hata veriyor. Tıpkı dolmuş bir SSD’de Windows’un hantallaşması gibi, Linux tarafında da %90 üzeri disk doluluk oranı performansı hissedilir biçimde aşağı çeker.

Özet mantık: Backup alın, ama backup’ları da yönetin. En azından son 2–3 full backup’ı saklayın, daha eski olanları manuel olarak silin ya da harici bir depolama alanına (remote storage, S3, başka bir VDS) taşıyın.

Güvenlik Duvarı ve Port Ayarları

“Dış dünyaya açık her port, açık bir penceredir.” Yedekleme konusu deyince çoğu kişi sadece dosyalara odaklanıyor ama işin güvenlik tarafı da en az dosyanın kendisi kadar kritik. Özellikle VDS veya cloud sunucu üzerinde kendi cPanel/WHM kurulumunuzu yönetiyorsanız, firewall yapılandırması yedekleme trafiğini de etkiliyor.

Örneğin, harici bir sunucuya SCP/RSYNC ile otomatik backup atıyorsanız, ilgili portların (genelde 22 veya alternatif SSH portu) sadece belirli IP’lere açık olması çok daha güvenlidir. “Her yerden erişeyim” kolaycılığı, bir gün brute-force saldırısıyla birleştiğinde can yakar. SSH portunu 22’den farklı bir değere almak, root erişimini kapatıp sudo kullanan bir kullanıcı ile bağlanmak ve mümkünse sadece anahtar (SSH key) kabul etmek temel üçlü set gibi düşünebilirsiniz.

FTP tarafında da benzer durum geçerli. Hâlâ plain FTP açık sunucu görmek, günümüzde emniyet kemersiz araba sürmek gibi. Mümkün olduğunca FTPS veya SFTP kullanın, gerekmediği sürece FTP servisini aktif tutmayın. Yedekleme için remote FTP kullanıyorsanız, sadece o uzak sunucunun IP adresine izin verin.

cPanel tarafında, özellikle CSF gibi popüler firewall’lar kullanıyorsanız, otomatik yedekleme için kullanılan uzak IP’leri whitelist’e eklemeyi unutmayın. Yoksa backup cron’u çalışır, bağlantı firewall tarafından kesilir, siz de “Yedekleme alıyorum sanıyordum” diye düşünürken aslında haftalardır boşa log üretiyor olursunuz.

Yazılım Uyumluluğu ve PHP/Veritabanı Seçimi

cPanel’de Yedekleme ve Geri Yükleme Rehberi konuşurken, yazılım versiyonlarını da denklemin içine koymak şart. Çünkü aldığınız yedek, farklı bir sürüme taşındığında sürpriz hatalarla karşılaşabilirsiniz. En güncel sürüm her zaman en iyisi mi? Güvenlik açısından çoğu zaman evet; ama uygulamanız eskiyse, bazı durumlarda hayır.

Şöyle düşünün: PHP 8.2’ye yükseltip, PHP 5.6 zamanında yazılmış ve güncellenmemiş bir scripti ayağa kaldırmaya çalışıyorsunuz. Yedek geri yüklendiğinde dosyalar sağlam, veritabanı tam ama site 500 hata veriyor. Sorun yedekte değil, uyumsuzlukta. Bu yüzden, geri yükleme yapmadan önce hedef sunucudaki PHP ve MySQL/MariaDB sürümlerini mutlaka kontrol edin.

Veritabanı optimizasyonu için altın kural şu: “Yedek almadan önce tabloları onar, yedek aldıktan sonra gerektiğinde indeksleri gözden geçir.” Özellikle WordPress gibi çok sorgu atan sistemlerde, wp_options ve log tabloları şişmişse, aldığınız her yedek gereksiz megabaytlar taşır ve geri yükleme süreleri uzar. Ara sıra OPTIMIZE TABLE ve gereksiz log temizliği yapmak, hem yedeğin boyutunu küçültür hem de sitenin hissedilir derecede hızlanmasını sağlar.

Uygulama: Kurulum ve Yayına Alma

Terminali açın, şu komutu girin demiyorum ama mantık şu: cPanel’de yedekleme ve geri yükleme süreçlerini tasarlarken üç adımı akılda tutmak gerekiyor: Planla, test et, otomatikleştir.

Planlama kısmında, sitenizin dinamikliğine göre yedek sıklığını belirlersiniz. Günde onlarca yorum ve sipariş alan bir e-ticaret sitesiyse günlük veritabanı, haftalık full backup mantıklıdır. Durağan bir kurumsal site için haftalık ya da 15 günde bir full backup bile çoğu zaman yeterli olur. Burada önemli olan, backup’ın hem sık hem de geri yüklenebilir olması. 30 günde bir alınan tam backup, hack’lenmiş ama geç fark edilen bir site için çoğu zaman anlamını yitirir.

Test kısmı, çoğu kullanıcının es geçtiği ama asıl kritik alan. Full backup aldınız, harika. Peki bu yedeği hiç başka bir test hesabına geri yüklemeyi denediniz mi? Bir staging hesabına, alt domainde, sadece bir kez bile olsa denemek, ileride yaşayacağınız panikleri ciddi oranda azaltır. “Teoride çalışan sistem, pratikte de çalışır” yanılgısına kapılmamak gerek.

Otomatikleştirme tarafında ise cPanel’in dahili backup özelliğini veya WHM kullanıyorsanız “Backup Configuration” bölümünü devreye alabilirsiniz. Harici FTP/SFTP, uzak cloud sunucu veya farklı bir VDS’e periyodik backup göndermek, tek sunucuya bağımlı kalmamanızı sağlar. Özellikle cloud sunucu veya VDS mimarisinde, farklı datacenter’lar arası yedek tutmak, donanım arızası senaryolarını neredeyse önemsiz hale getirir.

Bu arada, performansınızı artırmak için Web Panelleri sayfamızdaki diğer çözümlere de bakabilirsiniz. Panel optimizasyonu ve cache yapılandırması, yedekleme stratejinizle birlikte çalıştığında, hem hızlı hem de dayanıklı bir altyapınız olur.

Sık Karşılaşılan Sorunlar ve Pratik Çözümler

Sıkça Sorulan Sorular

cPanel’de yedek almak gerçekten güvenli mi?

Doğru yapılandırılmış bir cPanel yedekleme sistemi oldukça güvenlidir; ama tek başına yeterli değildir. Aynı sunucuda hem siteyi hem yedeğini tutmak, yangın merdivenini binanın içine yapmak gibi. En azından periyodik olarak harici bir sunucuya ya da lokal bilgisayarınıza kopya almanızı öneririm. Ayrıca, veritabanı parolaları ve sertifikalar gibi hassas bilgileri içeren yedekleri, herkese açık bir dizine koymamak ve mümkünse ek şifreleme ile korumak gerekir. Özellikle SSL tarafında, sertifikaların ve anahtarların yedeğini alırken dikkatli olun; SSL sertifikası güvenliği çoğu zaman sunucunun kendisi kadar önemlidir.

Fiyat/Performans dengesini nasıl kurarım?

Yedekleme tarafında asıl maliyet, çoğu zaman depolama ile ilgili. Paylaşımlı hosting kullanıyorsanız, panel içi yedekleri minimumda tutup, büyük arşivi harici bir lokasyonda saklamak daha mantıklı olur. VDS veya cloud kullanıyorsanız, disk tipini (SSD/NVMe), kapasiteyi ve uzak backup alanının maliyetini birlikte düşünün. Örneğin, ana sunucuda yüksek performanslı ama nispeten küçük NVMe disk, backup tarafında ise daha ekonomik ve daha büyük bir depolama mantıklı bir kombinasyondur. Bu dengeyi kurarken, sitenizin büyüme hızını ve trafik artışını da hesaplamak gerekiyor. Günde 1–2 sipariş alan bir siteyle, saniyede onlarca işlem alan bir e-ticaretin yedekleme stratejisi aynı olamaz. Uygun bir web hosting veya VDS paketi seçerken, disk ve yedekleme alanını birlikte değerlendirmeniz bu yüzden önemli.

Taşıma (Migration) işlemi zor mu?

Eski hostingten yeni sunucuya geçerken en kritik konu, yedeklemenin temiz ve tam olması. cPanel’den cPanel’e geçişlerde, full account backup ile migration aslında oldukça konforlu. WHM üzerinden “Transfer Tool” ile hızla taşıma yapılabiliyor. Kullanıcı tarafında görülen asıl zorluk, DNS değişikliği, e-posta hesaplarının senkronu ve taşıma sırasında veri kaybetmeme stresi. Burada Bilhost tarafında işini bilen bir teknik ekip devreye girdiğinde süreç ciddi anlamda kolaylaşıyor. Genelde şöyle ilerliyoruz: Eski sunucudan full backup alınıyor, yeni panele aktarılıyor, DNS geçişi planlanıyor ve trafiğin tam taşındığından emin olana kadar eski sunucu kısa süreli paralel tutuluyor. Yani, işin en zahmetli kısmını biz üstleniyoruz; sen sadece hangi domenlerin hangi pakete geçeceğine karar veriyorsun. İstersen domain tarafındaki süreci de domain sorgulama ve yönetim paneliyle bizden takip edebilirsin.

Sonuç

İşin özü şu: Teknoloji ne kadar karmaşık görünürse görünsün, doğru yedekleme ve geri yükleme kurgusu hayat kurtarır. cPanel’de Yedekleme ve Geri Yükleme Rehberi dediğimiz şey, aslında birkaç tıklamadan çok daha fazlası; neyi, ne zaman, nereye ve hangi sürümle aldığını bilmek işi profesyonel yapar. Full backup, kısmi yedek, harici depolama, firewall, PHP/MySQL uyumu… Bunların hepsi aynı resmin parçaları. Eğer bir yerde takılırsanız biz buradayız, yorumlarda sorularınızı bekliyorum.