Öne Çıkanlar
- Plesk Backup Manager, dosya, veritabanı ve mail yedeklerini tek paket halinde saklayarak panel üzerinden hızlı geri dönüş sağlar.
- RAID donanım koruması ile yedekleme farklı kavramlardır; yedekler insan hatası, hack veya hatalı güncellemelere karşı gereklidir.
- Zamanlanmış ve incremental yedekler kaynak kullanımını azaltır; disk I/O ve doluluk oranı yedek performansında kritik rol oynar.
- Harici hedeflere yedek aktarırken güvenlik (SFTP/FTPS, IP kısıtlaması, firewall) ve uyumluluk (PHP/DB sürümleri) dikkate alınmalıdır.
| Özellik | Detay |
|---|---|
| Hizmet Türü | Web Hosting / VDS / Cloud (Plesk Kurulu Tüm Ortamlar) |
| Hedef Kitle | Bireysel, Kurumsal, Geliştirici |
| Zorluk Seviyesi | Kolay / Orta (Hesap Büyüklüğüne Göre) |
| Öne Çıkan Özellik | Güvenlik ve Geri Dönüş Kolaylığı |
Plesk Yedek Alma (Backup Manager) Hakkında Bilmeniz Gerekenler
Plesk Yedek Alma (Backup Manager) tam olarak şu ihtiyaca cevap veriyor: “Sunucu patlasa bile, ben sadece panelden bir dosya seçip, en fazla birkaç tıkla siteyi geri getireyim.” Yani burada hedef; dosyaları, veritabanlarını, mail kutularını, hatta bazı panel ayarlarını tek bir paket halinde saklamak. Tek sunucu, tek site, tek kullanıcı yok; karmaşık ortamlar var. Backup Manager bu karmaşayı anlamlı hale getiriyor.
Genelde duyduğum en büyük efsane şu: “Sunucu zaten RAID’li, ayrıca yedek almaya gerek yok.” İşin püf noktası şurada: RAID = donanım arızasına karşı dayanıklılık. Yedek = insan hatasına, hack’e, yanlış güncellemeye, bozuk eklentiye karşı güvence. RAID diski korur, ama yanlışlıkla silinen wp-content klasörünü geri getirmez. Plesk Backup Manager ise tam burada devreye giriyor; panel seviyesinde, dosya ve veritabanı bazında geri dönüş imkanı veriyor.
Bir diğer yanlış algı da “Sunucunun tam yedeğini almak zor, uğraştırır” fikri. Plesk tarafında durum tam tersi: Doğru yapılandırıldığında, zamanlanmış yedekler arka planda sessizce çalışır. Sen sadece gerektiğinde “indir”, “geri yükle” tuşlarına dokunursun. Zor olan kısmı genelde şu: Kaynak limitlerini doğru ayarlamamak ve diski yedeklerle doldurmak. Onu da birazdan konuşacağız.
Yapılandırma ve Yönetim: Adım Adım
Kaynak Yönetimi – Limitleri Zorlamayın
Plesk Yedek Alma (Backup Manager) çalışırken sunucuya ciddi yük bindirebilir. Çünkü ne yapıyor? Dosyaları sıkıştırıyor, veritabanlarını dump ediyor, tek bir arşiv haline getiriyor. Özellikle yüksek trafikli bir WordPress veya e-ticaret sitesi barındırıyorsan, yedek alma zamanını iyi seçmek kritik. Gece trafiği düşükken yedek almak, gün ortası sepet onaylayan müşteriyi bekletmekten çok daha mantıklı.
Kaynak kullanımını kontrol etmenin en pratik yolu, yedekleme sırasında CPU ve disk I/O değerlerine bakmak. Plesk üzerinde “Tools & Settings > Resource Usage” veya sunucu seviyesinde top / htop üzerinden canlı izleme yapılabilir. Dürüst olmak gerekirse, birçoğumuz CPU yüzdesine takılıyoruz; ama asıl dar boğaz çoğu zaman disk I/O oluyor. Yedek alma işlemi diskten okumayı ve diske yazmayı zorladığı için, SSD hızın ve IOPS kapasiten zayıfsa site yavaşlamaları gayet normal.
“Aşırı kaynak kullanımı” uyarısı gördüğünde panik yapmadan önce kontrol edeceğin ilk yer genelde hata logları değil, disk doluluk oranıdır. Çünkü Plesk yedekleri, özellikle “full backup” modunda, diskte ciddi yer kaplar. df -h ile dosya sistemi doluluk oranını, Plesk’te ise “Tools & Settings > Backup Manager” altındaki mevcut yedek boyutlarını kontrol et. Eski yedekleri temizlemeden yeni yedek almaya zorlarsan, hem işlem yarıda kesilir hem de panelde kararsızlıklar yaşarsın.
Güvenlik Duvarı ve Port Ayarları
Yedek almak sadece “panel içi” bir iş gibi görünse de, özellikle yedeği sunucu dışına çıkaracaksan (örneğin FTP, SFTP, uzak depolama) firewall ayarların devreye girer. Şöyle düşün: Dış dünyaya açık her port, açık bir penceredir. Plesk Backup Manager ile harici bir FTP’ye yedek attığında 21/22 gibi portları açman gerekebilir; ama bunu “sınırsız” açmak yerine, mümkünse sadece ilgili IP’lere izin vermek çok daha sağlıklı.
SSH portunu varsayılan 22’den farklı bir değere almak, FTP yerine SFTP veya FTPS kullanmak, gereksiz servisleri (anonim FTP gibi) kapatmak, backup taşırken riskini ciddi ölçüde azaltır. Özellikle VDS veya Cloud sunucu kullanıyorsan, güvenlik duvarını sadece panelden değil, sistem seviyesinde de (iptables, firewalld, ufw) düzenlemek iyi bir alışkanlık.
Özetle: Backup Manager için harici hedef kullanıyorsan, o hedefe giden portu aç; ama tüm dünyaya değil, sadece uzak depo IP’sine. “Bir kere açayım kalsın” mantığı, ileride can sıkıcı log taramaları yapmana sebep olabilir.
Yazılım Uyumluluğu ve PHP/Veritabanı Seçimi
Yedek konusuyla alakalı gibi görünmüyor ama aslında çok bağlantılı: Yedeği alıyorsun, güncelleme yapıyorsun, sonra geri dönmen gerekiyor. İşte burada PHP ve veritabanı sürümleri devreye giriyor. En güncel PHP her zaman en iyisi mi? Güvenlik açısından evet, ama uyumluluk açısından her zaman değil. Özellikle eski yazılımlar, eski framework’ler veya güncellenmeyen eklentiler, PHP 8.x ortamında patlayabiliyor.
Bu yüzden Plesk Yedek Alma (Backup Manager) ile yedek aldıktan sonra, büyük bir sürüm değişikliği yapacaksan (örneğin PHP 7.4’ten 8.2’ye geçiş, MySQL’den MariaDB büyük versiyon atlaması gibi), önce test ortamında denemek mantıklı. Yedekten dönmek elinde seçenek olsun ama “canlı sitede kumar” oynamamış ol.
Veritabanı tarafında altın kural şu: Yedek küçülsün istiyorsan, gereksiz log tablolarını ve çöp verileri (özellikle wp_options içindeki transient’ler, cache tabloları) temizle. Yedek hızlı alınır, geri yükleme süresi kısalır ve arıza anında daha çabuk ayağa kalkarsın. Büyük e-ticaret sitelerinde, log tablosu yüzünden 2 GB’lık veritabanının 20 GB’a çıktığını çok gördük.
Uygulama: Kurulum ve Yayına Alma
Şimdi gelelim pratik tarafa. “Terminali açın, şu komutu girin” demiyorum ama mantık şu şekilde işliyor:
- Plesk panelde ilgili aboneliğe (domain’e) giriyorsun.
- “Backup Manager” / “Yedekleme Yöneticisi” bölümünü açıyorsun.
- “Backup” veya “Full Backup” benzeri butona tıklıyorsun.
Burada genelde şu seçenekler çıkar: Sadece yapılandırma (config) yedeği, tam yedek (dosya + veritabanı + mail), planlanmış (scheduled) yedek ve hedef dizin (sunucu lokali, FTP, S3 benzeri harici depo). Sitenin tam yedeğini bilgisayara indirmek istiyorsan, önce Plesk üzerinde tam yedeği oluşturuyorsun, ardından oluşan backup dosyasını listeden seçip “Download” ile lokaline çekiyorsun.
İşin püf noktası şurada: Yedek formatı Plesk’e özgü olabilir. Yani bu dosyayı doğrudan başka panele (örn: cPanel) restore edemezsin. Ancak Plesk yedeğini elinde bulundurmak; dosyaları açıp içinden httpdocs veya SQL dump’ı manuel çıkarmana da olanak tanır. O yüzden bilgisayara indirirken, dosya boyutunu ve internet bağlantını da göz önünde bulundur. 15–20 GB’lık bir yedeği Wi-Fi üzerinden laptopa çekerken “download yarıda kesildi” senaryosu çok yaşanıyor.
Planlanmış yedek tarafında ise önce bağımlılıkları kontrol ediyorsun: Disk alanın yeterli mi, harici yedek hedefi (FTP/S3) erişilebilir mi, sunucu saat ayarın doğru mu. Ardından Plesk Backup Manager içinde, örneğin her gece 03:00’te incremental (artımlı) yedek, haftada bir kez de full backup tanımlıyorsun. Genelde 5 dakikadan fazla sürmeyen bu ayar, ileride saatlerce veri kurtarma uğraşından seni kurtarır.
Bu arada, performansınızı artırmak için Plesk sayfamızdaki diğer çözümlere de bakabilirsiniz. Yedek sadece güvenlik, performans tarafında da büyük kolaylık; yeni bir optimizasyon deneyeceğin zaman, önce snapshot gibi düşünüp Plesk yedeği alman her zaman akıllıca.
Sık Karşılaşılan Sorunlar ve Pratik Çözümler
| Sorun | Muhtemel Neden | Çözüm |
|---|---|---|
| Site Yavaş Açılıyor | Zayıf önbellekleme veya yüksek sorgu sayısı | Redis/Litespeed Cache kurulumu yapın |
| Bağlantı Zaman Aşımı | Firewall engeli veya hatalı DNS | Port izinlerini kontrol edin |
| Plesk Yedeği Yarım Kalıyor | Disk alanı yetersiz veya I/O sınırı dolu | Eski yedekleri silin, log ve cache’leri temizleyin, gerekirse paket yükseltin |
| Yedek Dosyası Bilgisayara İnmiyor | Tarayıcı zaman aşımı veya internet kopması | Daha küçük parçalara ayırın (incremental/partial backup), mümkünse kablolu bağlantı kullanın |
| Geri Yükleme Sonrası Bozuk Site Görünümü | Eksik dosya veya farklı PHP/DB sürümü | Aynı PHP/DB versiyonunda restore edin, cache’leri temizleyin, dosya izinlerini kontrol edin |
Sıkça Sorulan Sorular
Plesk Yedek Alma (Backup Manager) kullanmak güvenli mi?
Evet, panel içinden çalıştığı için Plesk’in kendi izin ve rol sistemine tabi. Yani doğru kullanıcı yetkilerini verdiğin sürece gayet güvenli. Ek önlem olarak: Yedekleri sunucuya ek olarak harici bir depoda tut, yedek dosyalarını herkese açık bir dizinde barındırma ve mümkünse FTP yerine şifreli transfer (SFTP/FTPS) kullan.
Fiyat/performans dengesini nasıl kurarım?
Burada üç şey dengede olmalı: Disk alanı, işlemci gücü, harici yedek maliyeti. Çok büyük siteler için VDS veya Cloud sunucu tercih edip, harici yedek deposu kullanmak mantıklı. Daha küçük projelerde iyi yapılandırılmış bir web hosting paketi + otomatik Plesk yedekleri çoğu senaryo için yeterli. Temel mantık: Kritik sitelerde yedekten kısmak, en pahalı tasarruf yöntemidir.
Taşıma (Migration) işlemi zor mu?
Plesk’ten Plesk’e geçiş, Backup Manager ve migration araçları sayesinde sandığından daha kolay. Yedeği al, yeni sunucuya aktar, panel üzerinden restore et. Tabii DNS ve SSL tarafını da unutmamak lazım; domain ve SSL tarafında işini kolaylaştırmak için domain ve SSL sertifikası hizmetlerimizle uçtan uca bir kurulum yapabiliyoruz. İşin zor kısmı genelde teknikten çok planlama; biz bu noktada taşıma sürecini mümkün olduğunca “downtime”sız ve kullanıcıya hissettirmeden yönetmeye odaklanıyoruz.
Sonuç
İşin özü şu: Plesk Yedek Alma (Backup Manager) aslında paneldeki bir butondan çok daha fazlası. Doğru planlanmış bir yedek stratejisi, yanlış bir güncelleme, hack girişimi veya insan hatası sonrası seni saatlerce log kazmaktan kurtarır. Yedeklerin hem sunucuda hem harici bir depoda, kritik anlarda tek tıkla erişilebilir olması, dijital işinin sigortası gibi düşünebilirsin. Teknoloji ne kadar karmaşık görünürse görünsün, doğru yapılandırma hayat kurtarır. Eğer bir yerde takılırsan biz buradayız, yorumlarda sorularını bekliyorum.
