Disk Doldu: Medya Dosyalarını Object Storage'a (R2, S3, Spaces) Taşıma

Panelde disk kullanımı çubuğu kırmızıya döndü. wp-content/uploads klasörü 180 GB ve içinde altı yıllık ürün fotoğrafı, etkinlik albümü veya proje görseli var. Hiçbirini silemezsiniz; hepsi yayında bir sayfaya bağlı. Aramaya başladığınızda karşınıza çıkan her cevap aynı üç şeyi söylüyor: eski dosyaları silin, görselleri sıkıştırın, kullanılmayan medyayı temizleyin.

Bu tavsiyeler yanlış değil ama bir tavan var. 40 GB'lık bir arşivi agresif WebP dönüşümüyle 25 GB'a indirebilirsiniz — sonra arşiv büyümeye devam eder ve altı ay sonra aynı noktadasınızdır. Sıkıştırma bir kereye mahsus kazanç sağlar, oysa sorun sürekli büyüyen bir eğri. Arşivi büyüyen bir sitede disk sorunu bir temizlik meselesi değil, bir mimari karar meselesidir: statik dosyalar hosting diskinde mi duracak, yoksa depolamak için tasarlanmış ayrı bir servise mi taşınacak?

Bu yazı o kararı kurmakla ilgili. Önce object storage'ın hosting diskinden ne farkı olduğunu, sonra paket yükseltmenin aylık maliyetiyle depolama + istek + egress maliyetinin nasıl kıyaslanacağını, ardından WordPress tarafında taşımanın nasıl yapıldığını ele alacağız. En sonda da kimsenin anlatmadığı bölüm var: bu karardan dönmek, ona girmekten daha zordur ve neden öyle olduğunu bilerek başlamak gerekir.

Object Storage Nedir, Hosting Diskinden Farkı Ne?#

Hosting hesabınızdaki disk, bir dosya sistemidir: klasörler, dosya izinleri, inode'lar. PHP oradan dosya okur, include eder, yazar. Sunucunun kendisine bağlı olduğu için hem hızlıdır hem de sınırlıdır — paketinizde ne kadar yer varsa o kadar.

Object storage ise dosya sistemi değil, HTTP üzerinden konuşulan bir anahtar-değer deposudur. Her dosya bir "nesne"dir, bir anahtarı (2026/08/urun-1.jpg) ve içeriği vardır. Klasör kavramı gerçekte yoktur; anahtarın içindeki eğik çizgiler sadece görsel bir düzenleme sağlar. Dosyaya erişim open() ile değil, GET isteğiyle olur.

Bu farkın üç pratik sonucu var:

• Kapasite pratikte sınırsızdır. 10 GB de koyabilirsiniz 10 TB de; paket değiştirmezsiniz, sadece kullandığınız kadar ödersiniz.
• Her erişim bir HTTP isteğidir ve ücretlidir. Hosting diskinde bir görseli 10 milyon kez okumanın ek maliyeti yoktur; object storage'da vardır.
• PHP kodu oradan çalıştırılamaz. Object storage yalnızca statik dosyalar içindir: görsel, video, PDF, yedek arşivi. Temanız, eklentileriniz ve veritabanınız hosting diskinde kalır.

Bu yüzden çözüm "siteyi buluta taşımak" değil, sadece uploads klasörünü ayırmaktır. Sitenin kendisi olduğu yerde durur, ağırlığı taşıyan kısım dışarı çıkar.

Hangi Boyuttan Sonra Mantıklı Hale Gelir?#

Küçük siteler için object storage bir kazanç değil, gereksiz bir karmaşıklık katmanıdır. Kaba bir eşik:

Bu tablo kesin bir kural değil; arşivinizin büyüme hızıyla birlikte okunmalı. Ayda 2 GB büyüyen 20 GB'lık bir arşiv, bir yıl sonra 44 GB olacaktır. Kararı bugünkü boyuta değil, on iki ay sonraki boyuta göre verin.

Paket Yükseltme mi Object Storage mı? Maliyet Hesabı#

Karşılaştırmayı doğru kurmanın yolu, iki tarafı da aylık toplam maliyete indirgemektir. Paket yükseltme tarafı basittir: mevcut paketinizle bir üst paket arasındaki aylık fark. Bu farkın içinde sadece disk yok — genelde daha fazla CPU, RAM ve e-posta hesabı da vardır ve bunlara ihtiyacınız olabilir. Hosting paketini yükseltme zamanı yazısındaki kriterler burada da geçerli: sorun yalnızca diskse, yükseltme aslında ihtiyacınız olmayan kaynakları da satın almanız demektir.

Object storage tarafı ise üç kalemden oluşur ve bunları ayrı ayrı hesaplamak zorundasınız:

1. Depolama — GB başına aylık ücret. Genelde en küçük kalem budur.
2. İstek (operation) — nesne yazma/listeleme (Class A) ve okuma (Class B) sayısı. Milyon istek başına ücretlendirilir.
3. Egress (dışa veri transferi) — ziyaretçilere gönderilen bayt miktarı. Sağlayıcılar arasındaki en büyük fark bu kalemdedir ve çoğu zaman kararı tek başına belirler.

Önce hangi verilere ihtiyacınız olduğunu ölçün. Medya boyutu için:

# Toplam uploads boyutu
du -sh wp-content/uploads

# En çok yer kaplayan yıl/ay klasörleri
du -sh wp-content/uploads/* | sort -h | tail -20

# Dosya sayısı (istek maliyetini tahmin etmek için)
find wp-content/uploads -type f | wc -l

Aylık egress için hosting panelinizdeki bant genişliği raporuna bakın; medyanın toplam trafiğin ne kadarını oluşturduğunu yaklaşık olarak çıkarabilirsiniz. Görsel ağırlıklı bir sitede bu oran çoğu zaman %70'in üzerindedir.

Egress Ücreti: Sağlayıcı Seçimini Belirleyen Tek Kalem#

Depolama ücretleri sağlayıcılar arasında birkaç kat farklıdır; egress ücretleri ise sonsuz kat farklıdır, çünkü bazılarında hiç yoktur. Bu, aylık faturayı 5 dolar ile 50 dolar arasında ayıran şeydir.

Aşağıdaki tablo sağlayıcıların yayınlanmış liste fiyatlarına dayanır. Fiyatlar değişir; karar vermeden önce ilgili sağlayıcının güncel sayfasından doğrulayın.

Somut bir örnek üzerinden bakalım: 200 GB medya, ayda 500 GB dışa trafik olan bir site.

Aradaki fark depolamadan değil, tamamen egress'ten geliyor. S3 diğerlerinden on kat pahalı çıkıyor ve bunun tek sebebi ziyaretçilere gönderilen 500 GB.

Wasabi satırındaki uyarı önemli ve gözden kaçar: "egress ücretsiz" ifadesi koşulsuz değildir. Aylık indirdiğiniz veri, hesabınızdaki aktif depolamayı aşmadığı sürece ücretsizdir. Bu örnekte 500 GB egress'e karşılık 200 GB depolama var — yani politika aşılıyor. Wasabi soğuk arşiv ve yedek için mükemmeldir; sıcak, çok okunan bir medya kütüphanesi için sınıra takılırsınız. Aynı şekilde 90 günlük minimum saklama süresi, sık sildiğiniz dosyalar için sürpriz bir maliyet doğurur.

İstek Ücreti Ne Zaman Sorun Olur?#

Depolama ve egress küçük görünüp istek kalemi büyüyen tek bir senaryo vardır: çok sayıda küçük dosya. Her görsel için WordPress varsayılan olarak thumbnail, medium, large ve tema kaynaklı ek boyutlar üretir; tek bir yüklemeden altı, sekiz, bazen on iki dosya çıkar. 50.000 görsellik bir kütüphane kolaylıkla 400.000 nesneye dönüşür.

Bu, taşıma sırasında (Class A yazma) ve önbelleğe alınmamış her okumada (Class B) doğrudan istek sayısına yansır. İki önlem işi kökten çözer: taşımadan önce kullanılmayan görsel boyutlarını kapatmak — medya kütüphanesini düzenli tutma yazısındaki yöntemler tam olarak bunun içindir — ve önüne bir CDN koyarak okumaların büyük bölümünü object storage'a hiç ulaştırmamak.

WordPress'te Medyayı Object Storage'a Taşıma Adımları#

Sıra uygulamada. Aşağıdaki akış Cloudflare R2 üzerinden anlatılıyor ama S3, Spaces, Wasabi ve diğer S3 uyumlu servislerde adımlar birebir aynıdır; yalnızca uç nokta (endpoint) adresi değişir.

1. Bucket ve Erişim Anahtarı Oluşturun#

Sağlayıcı panelinde bir bucket açın ve yalnızca o bucket'a yetkili bir erişim anahtarı çifti üretin. Hesabın tamamına yetkili bir anahtar kullanmayın: anahtar WordPress veritabanında veya wp-config.php içinde duracak ve sitenin ele geçirilmesi durumunda saldırganın eline geçecektir. Yetkiyi tek bucket ve okuma/yazma ile sınırlayın.

Bucket'ı herkese açık okuma moduna alın (medya dosyaları zaten herkese açık) ve tarayıcıdan erişilebilmesi için CORS politikasını tanımlayın:

[
  {
    "AllowedOrigins": ["https://ornek.com"],
    "AllowedMethods": ["GET", "HEAD"],
    "AllowedHeaders": ["*"],
    "MaxAgeSeconds": 3600
  }
]

2. Bucket'a Özel Bir Alan Adı Bağlayın#

Bu adımı atlamayın. Sağlayıcının size verdiği ham adresi (bucket.hesapkimligi.r2.cloudflarestorage.com gibi) doğrudan kullanırsanız, ileride sağlayıcı değiştirmek istediğinizde sitedeki her URL'yi tekrar yazmak zorunda kalırsınız.

Bunun yerine cdn.ornek.com gibi kendi alt alan adınızı bucket'a yönlendirin. Böylece sağlayıcı değişse bile URL'ler aynı kalır; siz sadece DNS kaydını başka yere çevirirsiniz. Bu tek adım, taşınma kararını geri alınabilir kılan en önemli şeydir.

3. Bir Offload Eklentisi Kurun ve Yapılandırın#

WordPress tarafında işi yapan eklentilerden bazıları: Advanced Media Offloader (ücretsiz, R2/S3/Spaces/Wasabi/B2 destekler), WP Offload Media, Media Cloud. Hepsi aynı iki işi yapar: yeni yüklemeleri otomatik olarak buluta gönderir ve medya URL'lerini yeniden yazar.

Anahtarları arayüz yerine wp-config.php içinde tutmak, veritabanı yedeği paylaşırken sızma riskini azaltır — kullandığınız eklentinin dokümantasyonunda tanımladığı sabit adını kullanın. Yapılandırmada üç ayar kritiktir:

• Yerel kopya politikası: İlk aşamada "yerel kopyayı sakla" seçeneğiyle başlayın. Yer kazancını hemen görmezsiniz ama geri dönüş yolunuz açık kalır. Doğrulamayı bitirdikten sonra yerel dosyaları silersiniz.
• URL yeniden yazma: Özel alan adınızı (https://cdn.ornek.com) buraya girin.
• Yol öneki (prefix): wp-content/uploads yapısını korumak, ileride geri dönüşü kolaylaştırır.

4. Önce Küçük Bir Pilot Klasörle Deneyin#

Toplu aktarımı başlatmadan önce tek bir ayın klasörünü taşıyın — örneğin 2026/01. Ardından:

• O aya ait yazılardan birini açın, görseller yükleniyor mu bakın.
• Tarayıcının ağ sekmesinde görsellerin cdn.ornek.com üzerinden geldiğini doğrulayın.
• Medya kütüphanesinde küçük önizlemeler (thumbnail) görünüyor mu kontrol edin.
• Yeni bir görsel yükleyip doğru yere gittiğini görün.

Bu adım on dakika sürer ve 180 GB'lık bir aktarımın yarısında keşfedeceğiniz bir yapılandırma hatasını baştan yakalar.

5. Mevcut Medyayı Toplu Aktarın#

Eklentilerin kendi toplu aktarım ekranları çoğu site için yeterlidir. Ancak arşiv büyükse, PHP zaman aşımlarına takılmamak için aktarımı sunucu üzerinden rclone ile yapmak çok daha güvenilirdir:

# Sağlayıcıyı tanımla (interaktif sihirbaz, "s3" tipini seçin)
rclone config

# Dosyaları kopyala — sil değil, kopyala
rclone copy ./wp-content/uploads r2:site-medya/wp-content/uploads \
  --progress --transfers 16 --checkers 32

# Aktarımın eksiksiz olduğunu doğrula
rclone check ./wp-content/uploads r2:site-medya/wp-content/uploads --size-only

rclone check adımını atlamayın. copy komutu tek tek dosya hatalarını sessizce geçebilir; check size iki taraf arasındaki farkı verir. Fark sıfır olmadan yerel dosyalara dokunmayın.

Aktarım bittikten sonra eklentinin veritabanı kaydını tazelemesi gerekir — çoğu eklenti "bulutta zaten var olan dosyaları eşleştir" anlamına gelen bir seçenek sunar. Bu adım, rclone ile taşınmış dosyaların WordPress tarafında da bilinmesini sağlar.

6. URL'leri Doğrulayın#

Eklenti URL'leri çalışma anında yeniden yazar, yani veritabanındaki eski adresler olduğu gibi kalır. Bu normaldir ve aslında iyidir — eklentiyi kapattığınızda site eski hâline döner. Ancak yazı içeriğine elle gömülmüş sabit adresler varsa bunlar yeniden yazılmaz. Kontrol edin:

# Kaç yazıda sabit uploads adresi geçiyor?
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%/wp-content/uploads/%';"

# Değiştirmeden önce mutlaka kuru çalıştırma yapın
wp search-replace 'https://ornek.com/wp-content/uploads' 'https://cdn.ornek.com/wp-content/uploads' \
  --all-tables-with-prefix --precise --dry-run

--dry-run çıktısını okumadan gerçek çalıştırmayı yapmayın. wp search-replace komutunun wp db query veya düz SQL'e üstünlüğü, serileştirilmiş (serialized) verileri doğru işlemesidir; tema ayarları ve sayfa oluşturucu verileri bu formatta saklandığı için düz bir REPLACE sorgusu onları bozar.

CDN'i Object Storage'ın Önüne Almak#

Object storage bir CDN değildir. Tek bir bölgede durur ve her istek oraya gider. Türkiye'den bir ziyaretçi Frankfurt'taki bir bucket'tan görsel çekiyorsa, gecikme hosting diskinden okumaktan daha kötü olabilir.

Önüne CDN koymak iki sorunu birden çözer: ziyaretçiye en yakın düğümden servis edilir ve — daha önemlisi — istekler artık object storage'a ulaşmaz. Önbellek isabet oranı %90 civarındaysa, istek ve egress maliyetiniz onda birine iner. Egress ücreti alan bir sağlayıcı kullanıyorsanız bu, faturayı belirleyen tek ayar olabilir.

Cloudflare kullanıyorsanız cdn.ornek.com kaydını proxy (turuncu bulut) modunda tutmak yeterlidir. Yapılandırma detayları ve önbellek kuralları için WordPress'e CDN kurulumu yazısına bakın.

Bir ayrıntı: object storage'a yüklenen dosyalara uzun bir Cache-Control başlığı verin. Medya dosyaları değişmez; max-age=31536000 güvenlidir. Bir görseli değiştirmeniz gerekirse yeni bir dosya adıyla yükleyin.

Karardan Dönmek: Kırık Görsel Riski#

Bu yazının en dürüst olması gereken bölümü burası. Taşıma işlemi tek yönlü bir kapı gibi hissettirmez ama pratikte öyleye yakındır.

Sebep şu: taşımadan sonra sitenizdeki medya bağlantıları artık başka bir alan adına işaret ediyor. O alan adı çalışmayı bıraktığında — aboneliği iptal ettiğinizde, bucket'ı silmenin geri alınamaz olduğunu fark ettiğinizde, faturayı ödemeyi unuttuğunuzda ya da eklenti bir WordPress sürümüyle uyumsuz hale geldiğinde — sitedeki her görsel aynı anda kırılır. Hosting diskindeyken en kötü ihtimalle disk dolar ve yeni yükleme yapamazsınız; buradaysa mevcut içerik görünmez olur.

Riski yönetmenin dört kuralı var:

1. Taşımadan önce tam yedek alın ve o yedeği object storage'a koymayın. Yedek, taşıdığınız sistemden bağımsız bir yerde durmalı. Bu apaçık görünüyor ama sıkça atlanır.
2. Yerel kopyaları hemen silmeyin. En az bir ay iki tarafta da tutun. Disk hâlâ doludur, evet — ama o bir ay, geri dönüşün maliyetsiz olduğu tek dönemdir.
3. Özel alan adı kullanın. Yukarıda anlatıldı; sağlayıcı değiştirmenin DNS kaydı değiştirmekten ibaret olmasını sağlar.
4. Eklentiyi kapatmayı test edin. Sağlıklı bir kurulumda eklentiyi devre dışı bırakmak, URL'leri yerel yollara geri döndürür. Yerel dosyalar hâlâ duruyorsa site çalışmaya devam eder. Bunu bir kere denemek, geri dönüş planınızın gerçekten var olduğunu kanıtlar.

Yerel kopyaları sildikten sonra geri dönmek isterseniz yol şudur: rclone copy ile ters yönde çekin, rclone check ile doğrulayın, eklentiyi kapatın, sonra URL'leri geri yazın. Eğer içeriğe sabit adres gömülmüşse:

-- Önce yedek alın. Serileştirilmiş alanları bozabileceği için
-- mümkünse bunun yerine wp search-replace kullanın.
UPDATE wp_posts
SET post_content = REPLACE(
  post_content,
  'https://cdn.ornek.com/wp-content/uploads/',
  'https://ornek.com/wp-content/uploads/'
)
WHERE post_content LIKE '%cdn.ornek.com%';

Eklenti tamamen ortadan kalkmışsa ve zaman kazanmanız gerekiyorsa, bir mu-plugin ile URL'leri geçici olarak yönlendirebilirsiniz:

<?php
// wp-content/mu-plugins/medya-url-geri-donus.php
// Geçici köprü: kalıcı çözüm veritabanındaki adresleri düzeltmektir.
add_filter( 'wp_get_attachment_url', function ( $url ) {
    return str_replace(
        'https://cdn.ornek.com/wp-content/uploads',
        'https://ornek.com/wp-content/uploads',
        $url
    );
}, 20 );

Taşıma Sonrası Kontrol Listesi#

Aktarım bittikten sonra, yerel dosyaları silmeden önce şunları tek tek doğrulayın:

• Ana sayfa, bir kategori sayfası ve üç farklı yazı görsellerle birlikte açılıyor.
• Medya kütüphanesi ızgara görünümünde önizlemeler görünüyor.
• Yeni bir görsel yüklendiğinde bulutta oluşuyor ve yazıya eklenebiliyor.
• Ürün görselleri, slider'lar ve sayfa oluşturucu blokları çalışıyor (bunlar genelde farklı yollar kullanır).
• Tarayıcı konsolunda karma içerik (mixed content) uyarısı yok.
• Site haritasındaki görsel URL'leri güncel.
• Yedekleme sisteminiz artık uploads klasörünü yedeklemiyorsa, bucket için ayrı bir yedekleme planı var.

Son madde en çok atlanandır. Hosting yedeğiniz medyayı kapsıyordu; artık kapsamıyor. Object storage dayanıklıdır ama yanlışlıkla silmeye karşı korumaz. Bucket'ta sürüm (versioning) özelliğini açın ya da haftalık olarak başka bir sağlayıcıya kopyalayın.

Disk sorununuz object storage'la çözülmüyorsa — örneğin yer kaplayan şey medya değil, e-posta veya veritabanıysa — kaynağı doğru tespit etmek için önce cPanel disk kullanımı aracıyla klasör bazında bir döküm alın. Ayrıca disk boş görünürken hata alıyorsanız sorun kota değil inode sınırı olabilir.

Sıkça Sorulan Sorular#

Object storage'a taşıyınca sitem hızlanır mı?#

Doğrudan hızlanmaz, hatta önüne CDN koymazsanız yavaşlayabilir. Object storage tek bir bölgede durur; ziyaretçiniz uzaktaysa gecikme artar. Hız kazancı, medya isteklerinin hosting sunucunuzdan alınmasıyla dolaylı gelir — sunucu artık yalnızca PHP ve veritabanıyla ilgilenir. Gerçek hız kazancı için mutlaka bir CDN katmanı ekleyin.

Yerel dosyaları ne zaman silebilirim?#

En az bir ay bekleyin ve o süre içinde sitenin tüm bölümlerini gezin. Sezonluk içerik (kampanya sayfaları, yıllık raporlar) bir ay içinde ziyaret edilmemiş olabilir. Silmeden önce mutlaka tam bir yedek alın ve yedeği taşıdığınız bulut sisteminden bağımsız bir yerde tutun. Silme işlemi geri dönüşün maliyetsiz olduğu dönemi kapatır.

Hangi sağlayıcı en ucuz?#

Sadece depolamaya bakarsanız yanlış cevap verirsiniz. Aylık dışa trafiğiniz depolamanızın birkaç katıysa egress ücreti almayan bir sağlayıcı (R2 gibi) belirgin biçimde ucuzdur. Trafiğiniz düşük ve arşiviniz soğuksa Wasabi'nin TB başına sabit fiyatı öne çıkar. Kararı vermeden önce kendi depolama ve egress rakamlarınızı tabloya yerleştirip hesaplayın.

Eklenti bir gün desteklenmezse ne olur?#

Yerel kopyalarınız duruyorsa eklentiyi kapatmanız yeterlidir; URL'ler yerel yollara döner. Yerel kopyaları sildiyseniz dosyaları rclone ile geri çekip veritabanındaki adresleri düzeltmeniz gerekir. Bucket'a kendi alt alan adınızı bağlamış olmanız bu senaryoyu çok kolaylaştırır, çünkü URL'ler sağlayıcıya değil size ait bir adrese işaret eder.

Videoları da object storage'a taşımalı mıyım?#

Depolama açısından evet, ama servis açısından hayır. Video egress'i görselin kat kat üzerindedir ve tarayıcı ilerletme (seek) için parçalı istek gönderir, bu da istek sayısını artırır. Uzun videolar için özel bir video barındırma servisi hem maliyet hem oynatma kalitesi açısından daha uygundur. Kısa tanıtım videoları object storage'da sorunsuz durur.

Medya kütüphanesinde önizlemeler kayboldu, ne yaptım?#

En yaygın iki sebep: URL yeniden yazma ayarındaki alan adının yanlış girilmesi ve bucket'ta CORS politikasının tanımlanmamış olması. Tarayıcının ağ sekmesinde bir önizleme isteğine bakın — 403 dönüyorsa bucket erişim izni, CORS hatası görüyorsanız politika eksiktir. Kırık dosya yolu görüyorsanız eklentinin yol öneki ayarı ile buluttaki gerçek klasör yapısı uyuşmuyordur.