MinIO nedir: topluluk sürümü bakım kipinde, yeni kurulumlar için seçenekler ve yönetilen S3 uyumlu depolama

MinIO nedir sorusunun kısa yanıtı: kendi sunucunuzda çalıştırdığınız, Amazon S3 API'siyle uyumlu bir nesne depolama sunucusu. Uzun süre "kendi S3'ümü kurayım" diyenlerin ilk tercihiydi. 2025 boyunca topluluk sürümünde art arda değişiklikler oldu ve sonunda GitHub deposu bakım kipine alındı. Bu rehber, MinIO çalıştıran ya da kurmayı düşünen sistem yöneticileri ve yazılım ekipleri için: riski nasıl değerlendireceğinizi, hangi seçeneğe ne zaman geçmenin mantıklı olduğunu ve veriyi nasıl taşıyacağınızı adım adım anlatıyor.

MinIO nedir ve nerede kullanılır

MinIO, Go ile yazılmış, tek ikili dosya olarak çalışan bir nesne depolama sunucusudur. Dosyaları klasör ağacı yerine "bucket" ve "nesne" olarak saklar, erişimi S3 API'si üzerinden verir. Bu sayede AWS SDK'ları, rclone, restic, Veeam gibi S3 konuşan her araç MinIO'ya da bağlanabilir.

Tipik kullanım alanları şunlardır:

• Yedek deposu: restic, Velero, veritabanı dökümleri ve sanal makine yedekleri için hedef.
• Uygulama dosyaları: kullanıcı yüklemeleri, ürün görselleri, PDF faturalar.
• Geliştirme ve test ortamı: üretimde AWS S3 kullanan uygulamayı yerelde S3 benzeri bir uçla test etmek.
• Veri gölü ve analitik: Spark, Trino gibi araçların okuduğu parquet dosyaları.
• Kubernetes içinde kalıcı nesne deposu: Loki, Thanos, GitLab gibi araçların arka ucu.

Topluluk sürümü AGPLv3 lisanslıdır. Ticari tarafta firma, AIStor adlı ayrı bir ürün sunar.

2025'te ne değişti: MinIO topluluk sürümü ve bakım kipi

Değişiklikler tek seferde değil, aşamalı geldi. Ayrıntıları MinIO'nun resmi GitHub deposundaki README dosyasından ve sürüm notlarından kendiniz doğrulayın; özetle:

1. Web konsolu sadeleştirildi. Topluluk sürümündeki yönetim arayüzünden kullanıcı, politika ve yapılandırma yönetimi gibi özellikler çıkarıldı. Konsol büyük ölçüde nesne tarayıcısına dönüştü. Bu işlemler artık mc admin komutlarıyla yapılıyor.
2. Hazır ikili dosya ve konteyner imajı dağıtımı durdu. Topluluk sürümü için kaynak koddan derleme önerilir hale geldi. Yeni sürümler için resmi, hazır derlenmiş imaj beklemek artık gerçekçi değil.
3. Depo bakım kipine alındı. README'deki duyuruya göre yeni özellik geliştirilmiyor, katkı kabulü kısıtlı ve güvenlik düzeltmeleri duruma göre değerlendiriliyor. Kısacası düzenli yama takvimi yok.

Bu durum MinIO'nun bir anda çalışmayı bıraktığı anlamına gelmez. Kurulu sunucunuz bugün de veri sunmaya devam eder. Asıl soru, önümüzdeki yıllarda bu yazılımı güvenle işletip işletemeyeceğinizdir.

Mevcut MinIO kurulumları için gerçek risk

Riski üç başlıkta toplayabilirsiniz.

Güvenlik yamaları: İnternete açık bir S3 uç noktası, kimlik doğrulama ve imza doğrulama kodu çalıştırır. Bu katmanda bir açık çıkarsa, düzenli yama gelmeyen bir yazılımda düzeltmeyi kendiniz derlemek ya da beklemek zorunda kalırsınız.

İkili dosya ve imaj sorunu: Birçok kurulum minio/minio:latest gibi bir etiketle çalışır. Etiketin artık güncellenmemesi, "güncel sanılan ama eski" bir imajın üretimde kalması demektir. Topluluk tarafından yeniden paketlenen imajlar da bir seçenek, ama kimin derlediğine ve neyi değiştirdiğine güvenmeniz gerekir.

Araç ve bilgi birikimi: Konsoldaki yönetim özellikleri gidince ekipteki herkesin mc komutlarını bilmesi gerekir. Bu küçük ekiplerde tek kişiye bağımlılık yaratır.

Önce kendi durumunuzu ölçün

Karar vermeden önce şu üç bilgiyi toplayın. Aşağıdaki komutlar Ubuntu 24.04 ve Debian 12 üzerinde MinIO ve mc istemcisi kurulu sunucular için hazırlandı; yalnız okuma yapar, geri alınacak bir değişiklik yoktur. ORNEK_ALIAS yerine mc alias list çıktısındaki kendi takma adınızı yazın.

# 1) Çalışan MinIO sürümü (ikili dosya kuruluysa)
minio --version

# 2) Konteynerde çalışıyorsa hangi imaj ve etiket kullanılıyor
docker ps --format '{{.Image}}  {{.Names}}' | grep -i minio

# 3) Küme bilgisi: sunucu sayısı, disk durumu, toplam kullanım
mc admin info ORNEK_ALIAS

# 4) MinIO portları hangi arayüzde dinliyor (9000 API, 9001 konsol varsayılan)
sudo ss -tlnp | grep -E ':(9000|9001)\b'

ss çıktısında 0.0.0.0:9001 ya da *:9001 görüyorsanız konsol tüm arayüzlerde dinliyor demektir. Konsolun internete açık olması, yamaların belirsizleştiği bir dönemde ilk kapatmanız gereken noktadır. Sürüm çıktısındaki tarih damgası da kurulumunuzun ne kadar geride olduğunu gösterir.

Kendi sunucunuzda devam etmek: SeaweedFS, Garage ve Ceph RGW

Kendi altyapınızda kalmak istiyorsanız üç açık kaynak seçenek öne çıkıyor. Hiçbiri MinIO'nun birebir yerine geçmez; S3 uyumluluk düzeyleri farklıdır. Uygulamanızın kullandığı S3 çağrılarını (multipart upload, versioning, object lock, lifecycle, presigned URL) listeleyip her seçeneğin güncel belgesiyle karşılaştırın.

SeaweedFS

• Artı: Apache 2.0 lisanslı, Go ile yazılmış, çok sayıda küçük dosyada verimli. S3 ağ geçidi, dosya sistemi (filer) ve FUSE bağlama aynı projede.
• Eksi: Bileşen sayısı fazla (master, volume, filer, S3). Mimariyi anlamadan kurmak, sorun anında teşhisi zorlaştırır. Bazı gelişmiş S3 özelliklerinin desteğini belgeden kontrol etmeniz gerekir.
• Uygun olduğu durum: Milyonlarca küçük dosya, orta ölçekli ekip, kendi işletme kapasitesi olan yapı.

Garage

• Artı: Rust ile yazılmış, hafif, birkaç farklı lokasyondaki düşük güçlü sunucularda çalışmak için tasarlanmış. Kurulumu ve yapılandırması sade.
• Eksi: AGPLv3 lisanslı. Kapsam bilinçli olarak dar tutuluyor; versioning ve object lock gibi özellikler ihtiyacınızsa güncel desteği mutlaka doğrulayın.
• Uygun olduğu durum: Küçük ve orta veri hacmi, coğrafi olarak dağıtılmış birkaç düğüm, basit S3 kullanımı.

Ceph RGW

• Artı: Olgun, geniş S3 özellik desteği, büyük ölçekte kanıtlanmış bir proje. Aynı küme blok (RBD) ve dosya (CephFS) depolama da verebilir.
• Eksi: Ağır. Sağlıklı bir küme için birden fazla düğüm, ayrı ağ ve Ceph bilen bir ekip gerekir. Küçük bir yedek deposu için fazlasıyla karmaşıktır.
• Uygun olduğu durum: Çok sayıda terabaytlık veri, zaten Ceph işleten ya da işletmeye hazır bir ekip.

Bunların yanında MinIO'nun topluluk çatalları (fork) da var. Bir çatala geçmeden önce kaç aktif bakımcısı olduğuna, son sürüm tarihine ve güvenlik bildirim sürecine bakın; aksi halde aynı riski başka bir isimle taşırsınız.

Kendi S3 sunucunuzu işletmenin gizli yükü

"Yazılım ücretsiz" diye kendi deponuzu kurmak, maliyetin yalnız görünen kısmıdır. Karar verirken şu kalemleri yazılı olarak listeleyin:

• Disk ve çoğaltma: Tek sunucuda tek disk, depo değil tek hata noktasıdır. Erasure coding ya da çoğaltma için birden fazla disk ve tercihen birden fazla düğüm gerekir. Disk arızasında yeniden yapılandırma süresi boyunca performans düşer.
• İzleme: Disk doluluğu, düğüm sağlığı, hata oranı, gecikme. Uyarı kurmadığınız bir depo, sessizce dolup yazmayı reddedebilir.
• Yedeğin yedeği: Nesne deposunu yedek hedefi olarak kullanıyorsanız, deponun kendisi de bir felakette kaybolabilir. 3-2-1 kuralında depo, kopyalardan yalnızca biridir.
• Güncelleme ve güvenlik: TLS sertifikası yenileme, işletim sistemi yamaları, S3 sunucusu sürüm yükseltmeleri, erişim anahtarlarının döndürülmesi.
• İnsan zamanı: Gece 03.00'te disk arızası uyarısına kim bakacak? Bu sorunun yanıtı yoksa, maliyet hesabınız eksik.

Kendi deponuzu işletmeye devam edecekseniz bu yükün izleme kısmı için sunucu izleme gibi dışarıdan bir uyarı katmanı kurmak, en azından disk doluluğu ve erişilemezlik durumlarını kaçırmamanızı sağlar.

Yönetilen S3 uyumlu depolama ne zaman daha mantıklı

Yönetilen depolamada disk, çoğaltma, donanım arızası ve yazılım güncellemesi sağlayıcının işidir. Siz bucket açar, anahtar alır ve S3 API'sini kullanırsınız. Ancak her durumda doğru seçim değildir.

Yönetilen depolama mantıklıysa:

• Ekibinizde depolama kümesi işletecek zaman ya da kişi yoksa.
• Veri hacminiz birkaç terabayt düzeyindeyse ve kendi kümenizin donanım maliyeti orantısız kalıyorsa.
• KVKK açısından verinin Türkiye'de kalması gerekiyorsa ve yurt dışı bulut sağlayıcısı istemiyorsanız.
• Trafik ücreti öngörülemezliği yaşıyorsanız ve sabit faturayı tercih ediyorsanız.

Kendi deponuz mantıklıysa:

• Yüzlerce terabayt ya da petabayt düzeyinde veri ve bunu işletecek deneyimli bir ekip varsa.
• Depo ile hesaplama aynı yerel ağda olmalı ve çok düşük gecikme şartsa (ör. yoğun analitik işler).
• Kapalı ağda, internete hiç çıkmayan bir ortam zorunluysa.

Seçerken sağlayıcıya şunları sorun: verinin fiziksel konumu ve kopya sayısı, indirme trafiğinin ücretlendirilip ücretlendirilmediği, versioning ve object lock desteği, bucket'ların varsayılan erişim durumu ve sözleşmedeki fiyat değişikliği maddeleri.

MinIO'dan başka bir S3 uyumlu depoya rclone ile taşıma

Hedef ister SeaweedFS, ister Garage, ister yönetilen bir depo olsun, taşıma yöntemi aynıdır. rclone, iki S3 uç noktası arasında doğrudan kopyalama yapar ve ardından iki tarafı karşılaştırabilir.

1. Hazırlık

• Hedefte aynı isimde bucket'ları önceden oluşturun. Object lock gerekiyorsa bucket'ı oluştururken etkinleştirin; çoğu S3 uygulamasında bu ayar sonradan açılamaz.
• MinIO tarafında yalnız okuma yetkili ayrı bir erişim anahtarı oluşturun. Taşıma aracı yanlışlıkla kaynağa yazmasın.
• Kaynaktaki toplam boyutu ve nesne sayısını not edin.

2. rclone yapılandırması

Aşağıdaki yapılandırma rclone 1.6x ve sonrası için hazırlandı, Ubuntu 24.04 ve Debian 12'de ~/.config/rclone/rclone.conf dosyasına yazılır. Geri almak için ilgili iki bölümü dosyadan silmeniz yeterli. Büyük harfli değerleri kendi bilgilerinizle değiştirin.

[kaynak]
type = s3
provider = Minio
access_key_id = ORNEK_MINIO_ERISIM_ANAHTARI
secret_access_key = ORNEK_MINIO_GIZLI_ANAHTAR
endpoint = http://192.0.2.10:9000
region = us-east-1
force_path_style = true

[hedef]
type = s3
provider = Other
access_key_id = ORNEK_HEDEF_ERISIM_ANAHTARI
secret_access_key = ORNEK_HEDEF_GIZLI_ANAHTAR
endpoint = https://s3.example.com
force_path_style = true

3. Kuru çalıştırma, kopyalama ve doğrulama

Aşağıdaki betik tek bir bucket'ı kaynaktan hedefe kopyalar. copy kullanıldığı için hedefte bulunan ama kaynakta olmayan dosyaları silmez, kaynağa hiç yazmaz. Tekrar çalıştırıldığında yalnız eksik ya da değişen nesneleri aktarır, yani idempotenttir. ORNEK_BUCKET yerine bucket adınızı yazın.

#!/usr/bin/env bash
# MinIO bucket'ını başka bir S3 uyumlu depoya kopyalar.
# Ubuntu 24.04 / Debian 12 ve rclone 1.6x+ için hazırlandı.
set -euo pipefail

BUCKET="ORNEK_BUCKET"
LOG="/var/log/rclone-tasima-${BUCKET}.log"

# 1) Boyut ve nesne sayısını karşılaştırma için yazdır
rclone size "kaynak:${BUCKET}"

# 2) Kuru çalıştırma: hiçbir şey aktarılmaz, yalnız ne yapılacağı listelenir
rclone copy "kaynak:${BUCKET}" "hedef:${BUCKET}" --dry-run --log-level INFO

# 3) Gerçek kopyalama; paralellik değerlerini bant genişliğinize göre ayarlayın
rclone copy "kaynak:${BUCKET}" "hedef:${BUCKET}" \
  --transfers 16 --checkers 32 \
  --log-file "${LOG}" --log-level INFO --stats 1m

# 4) Doğrulama: kaynaktaki her nesne hedefte var mı, boyut ve özet uyuyor mu
rclone check "kaynak:${BUCKET}" "hedef:${BUCKET}" --one-way

# 5) Hedef tarafın boyutunu da yazdır
rclone size "hedef:${BUCKET}"

Başarılı bir doğrulamada rclone check çıktısının sonunda 0 differences found satırını görürsünüz; iki rclone size çıktısındaki nesne sayısı ve toplam boyut da aynı olmalıdır. Multipart yüklenmiş büyük nesnelerde iki depo farklı ETag üretebilir; rclone bu durumda karşılaştırmayı boyut ve kayıtlı özetle yapar. Kuşkulu nesneler için --download seçeneğiyle içerik karşılaştırması yapabilirsiniz, ancak bu tüm veriyi indirir ve yavaştır.

4. Kesinti planı

Canlı bir uygulamada önce toplu kopyalamayı yapın, sonra kısa bir yazma kesintisi verip rclone copy komutunu bir kez daha çalıştırarak son farkları aktarın. Ardından uygulamanın uç noktasını ve anahtarlarını değiştirin. MinIO'yu hemen kapatmayın; birkaç hafta salt okunur bırakmak geri dönüş yolunu açık tutar.

Taşıma sonrasında yedeklerinizi aynı depoya almak için S3 yedekleme rehberindeki restic ve rclone adımlarını, şifreli artımlı yedek kurulumu için de restic ile S3 yedekleme yazısını kullanabilirsiniz.

Uygulama tarafında dikkat edilecek farklar

Veri taşındı diye iş bitmez. Uygulamanın S3 istemcisi de yeni depoya uyum sağlamalıdır.

• Path-style ve virtual-hosted adresleme: MinIO çoğu kurulumda https://s3.example.com/bucket/nesne biçimini (path-style) kullanır. Bazı sağlayıcılar https://bucket.s3.example.com/nesne biçimini bekler. SDK'daki forcePathStyle ya da use_path_style ayarını hedefin belgesine göre ayarlayın.
• Bölge (region) değeri: MinIO varsayılan olarak us-east-1 kabul eder. Hedef farklı bir bölge adı istiyorsa imza hatası (SignatureDoesNotMatch) alırsınız.
• İmzalı bağlantılar (presigned URL): İmza uç nokta adresini ve anahtarı içerir. Taşımadan önce üretilmiş bağlantılar yeni depoda çalışmaz. E-postayla gönderilmiş uzun süreli bağlantılar varsa bunu kullanıcılarınıza duyurun.
• Object lock ve versioning: rclone yalnız nesnelerin güncel sürümünü kopyalar; eski sürümler ve saklama (retention) ayarları aktarılmaz. Değiştirilemez yedek gerekiyorsa hedefte kuralı yeniden tanımlayın ve saklama süresinin taşıma tarihinden itibaren başladığını hesaba katın.
• Politikalar, yaşam döngüsü ve bildirimler: Bucket politikaları, lifecycle kuralları ve olay bildirimleri (webhook, kuyruk) taşınmaz. MinIO'dan mc ile dışa aktarıp hedefte elle yeniden oluşturun.
• Herkese açık erişim: MinIO'da anonim okuma açık bir bucket varsa, hedefte bucket'lar varsayılan olarak kapalı olabilir. Sitedeki görsellerin kırılmaması için bunu önceden test edin.

Sık yapılan hatalar

• latest etiketiyle çalışan MinIO imajını "güncel" sanmak.
• Konsol portunu (9001) internete açık bırakmak.
• Doğrulama yapmadan kaynağı kapatmak.
• copy yerine sync kullanıp hedefte önceden duran veriyi silmek.
• Object lock gerektiren bucket'ı kilit olmadan oluşturup sonradan açmaya çalışmak.
• Uygulamadaki imzalı bağlantıları ve region ayarını unutmak.

Sık sorulan sorular

MinIO bakım kipinde olduğu için hemen taşımam gerekir mi?

Hayır, kurulu MinIO çalışmaya devam eder. Ancak düzenli güvenlik yaması beklenmediği için internete açık ya da kritik veri tutan kurulumlarda bir geçiş takvimi belirlemek mantıklıdır. Yalnız iç ağda çalışan test ortamlarında acele etmeniz gerekmez.

Yeni bir projede MinIO topluluk sürümüyle başlamak doğru mu?

Yeni bir projeye, geliştirilmeyen ve hazır imajı güncellenmeyen bir yazılımla başlamak uzun vadede teknik borç yaratır. Kendi sunucunuzda kalacaksanız SeaweedFS, Garage ya da Ceph RGW'yi; işletme yükü istemiyorsanız yönetilen bir S3 uyumlu depoyu değerlendirin.

MinIO'dan taşırken uygulama kodunu değiştirmem gerekir mi?

Genellikle yalnız yapılandırma değişir: uç nokta adresi, erişim anahtarları, region ve path-style ayarı. Object lock, versioning ya da MinIO'ya özgü yönetim API'lerini kullanıyorsanız bu kısımları hedefin desteğine göre gözden geçirmeniz gerekir.

rclone taşıma sırasında kaynak veriyi siler mi?

rclone copy kaynağa yazmaz ve hedefte fazladan duran dosyaları silmez. Silme yapan sync ve move komutlarıdır. Ek güvence için kaynakta yalnız okuma yetkili bir anahtar kullanın.

Bu işi hazır yapmak isterseniz

Kendi S3 kümenizi işletmek yerine verinizi Türkiye'de tutan yönetilen bir depoya geçmek isterseniz, İstanbul'da çalışan, verisi ve kopyaları Türkiye dışına çıkmayan, indirme trafiği dahil sabit aylık paketle sunulan S3 uyumlu Object Storage hizmetini değerlendirebilirsiniz. Yukarıdaki rclone adımları bu depoya da aynen uygulanır.

Sonuç

MinIO, S3 uyumlu nesne depolamayı herkesin erişebileceği hale getiren bir projeydi; topluluk sürümünün bakım kipine geçmesiyle artık "kur ve unut" seçeneği değil. Önce kendi kurulumunuzun sürümünü, açık portlarını ve veri hacmini ölçün. Ardından işletme yükünü taşıyabilecekseniz SeaweedFS, Garage ya da Ceph RGW'den uygun olanı, taşıyamayacaksanız yönetilen bir depoyu seçin. Taşımayı rclone copy ve rclone check ile adım adım yapın, uygulamadaki region, path-style ve imzalı bağlantı ayarlarını test etmeden eski depoyu kapatmayın.