Nextcloud ve ownCloud İçin Güvenli VPS Hosting Mimarisi

Dosyalarınızı tamamen kendi kontrolünüz altında tutmak istiyorsunuz; ama bunu evdeki bir NAS cihazına değil, profesyonel bir veri merkezine emanet etmek istiyorsunuz. Nextcloud veya ownCloud ile self‑hosted bir bulut kurmak tam olarak bu ihtiyaca cevap veriyor. Ancak iş sadece yazılımı kurmakla bitmiyor: VPS seçimi, depolama yapısı, şifreleme katmanları ve yedekleme mimarisi en az yazılım kadar kritik hale geliyor. Tek bir yanlış mimari kararı, yıllar boyunca biriken verinin tek noktadan kaybına, fidye yazılımı saldırılarıyla kilitlenmesine veya KVKK / GDPR gerekliliklerinin ihlal edilmesine yol açabiliyor.

DCHost tarafında onlarca müşterinin Nextcloud/ownCloud kurulumuna dokunurken gördüğümüz temel gerçek şu: Başta iyi tasarlanmış bir VPS mimarisi, sonradan yapılacak onlarca küçük yama güncellemesinden çok daha değerlidir. Bu yazıda, Nextcloud ve ownCloud için güvenli VPS hosting kurarken nelere dikkat etmeniz gerektiğini; depolama, şifreleme ve yedekleme katmanlarının birbirine nasıl bağlanması gerektiğini adım adım konuşacağız. Hedefimiz, hem küçük ekipler hem de kurumsal ölçekte kullanımlar için uygulanabilir, sade ama güvenli bir mimari ortaya koymak.

Nextcloud / ownCloud İçin Neden VPS Tercih Etmelisiniz?

Nextcloud veya ownCloud’u barındırmak için teorik olarak paylaşımlı hosting, ev sunucusu, NAS cihazı ya da dedicated sunucu gibi alternatifleriniz var. Yine de pratikte en dengeli çözüm, çoğu senaryo için doğru boyutlandırılmış bir VPS oluyor.

VPS’in pratik avantajları

• İzolasyon: Kendi sanal sunucunuzda root yetkisine sahipsiniz; başka müşterilerin siteleriyle aynı PHP sürecini veya dosya sistemi alanını paylaşmazsınız.
• Kaynak kontrolü: CPU, RAM ve disk IOPS tamamen size ait olduğu için, dosya senkronizasyonu sırasında performans tahmin edilebilir olur.
• Esneklik: İleride disk alanını büyütmek, RAM eklemek, ek disk bağlamak veya ayrı bir yedekleme diski eklemek çok daha kolaydır.
• Güvenlik sertleştirme: SSH, güvenlik duvarı, fail2ban gibi katmanları istediğiniz kadar sıkılaştırabilirsiniz; paylaşımlı hosting’te bu imkânınız sınırlıdır.

Hangi boyutta VPS ile başlamalı?

Elbette kullanım senaryosuna göre değişiyor, ancak DCHost tarafında gördüğümüz gerçekçi başlangıç değerleri şöyle:

• 3–10 kullanıcı / hafif kullanım: 2 vCPU, 4 GB RAM, 100–200 GB SSD
• 10–50 kullanıcı / ofis kullanımı: 4 vCPU, 8 GB RAM, 500 GB–1 TB SSD
• 50+ kullanıcı / yoğun ofis + mobil istemci: 8 vCPU+, 16 GB+ RAM, ihtiyaca göre 1 TB+ SSD ve ek yedek diski

Burada asıl belirleyici faktör CPU’dan çok disk performansı. Yoğun küçük dosya trafiğinde NVMe farkını çok net hissedersiniz. Bu noktada NVMe SSD, SATA SSD ve HDD karşılaştırmasını anlattığımız rehbere mutlaka göz atmanızı öneririz.

Mimari Tasarım: Tek VPS mi Ayrı Sunucular mı?

Nextcloud/ownCloud kurarken ilk karar, her şeyi tek bir VPS üzerinde mi toplayacağınız, yoksa dosya depolama, veritabanı ve yedeklemeyi ayrı sunuculara mı böleceğinizdir. Küçük ekipler için tek VPS genellikle yeterli iken, büyüyen yapılarda ayrıştırma ciddi avantaj sağlar.

Küçük ekipler: Tek VPS, sade ama güvenli mimari

3–20 kullanıcı arası tipik bir KOBİ senaryosunda şu tasarım gayet sağlıklı çalışır:

• Tek bir VPS üzerinde: Nginx/Apache + PHP-FPM + MariaDB/PostgreSQL + Nextcloud/ownCloud
• Aynı VPS içinde iki ayrı disk veya iki ayrı disk bölümü:
  • Disk 1 (NVMe/SSD): Sistem + veritabanı + uygulama dosyaları
  • Disk 2 (daha büyük SSD/SATA): Kullanıcı dosyaları ve yedekler
• Harici object storage veya uzak yedek sunucusuna düzenli yedek replikasyonu

Bu mimari, maliyeti makul tutarken güvenlik ve yedekleme için gerekli temel esnekliği sağlar.

Orta ve büyük ölçek: Ayrı veritabanı, ayrı depolama, ayrı yedek

50+ kullanıcı, yoğun ofis kullanımı veya dış paylaşımlar varsa, bileşenleri ayırmak anlamlı hale gelir:

• Uygulama VPS’i: Web sunucusu + PHP-FPM + Nextcloud/ownCloud
• Veritabanı VPS’i veya dedicated sunucu: MariaDB/PostgreSQL
• Depolama katmanı: NFS ile bağlanan bir dosya sunucusu veya S3‑uyumlu object storage
• Yedekleme sunucusu: Yalnızca yedekleri alan, erişimi sıkı kısıtlanmış ayrı VPS veya depolama

Bu yaklaşımda her katmanı bağımsız ölçekleyebilir, örneğin önce depolamayı büyütüp, CPU/RAM’i daha sonra artırabilirsiniz. DCHost ortamında veritabanı replikasyonu, ayrı yedek VPS’i ve object storage kombinasyonlarıyla oldukça esnek mimariler kurabiliyoruz.

Depolama Katmanı: Disk Türleri, Dosya Sistemi ve Paylaşım

Nextcloud/ownCloud kurulumlarının %80’inde performans sorununun kaynağı CPU değil, disk I/O ve yanlış depolama tasarımı oluyor. Bu yüzden depolama katmanını detaylı konuşmak şart.

Disk türü seçimi: NVMe mi SATA mı HDD mi?

• NVMe SSD: Çok yüksek IOPS ve düşük gecikme. Küçük dosya okuma/yazma ve veritabanı için ideal. Uygulama + veritabanını burada tutmak, hissedilir hız kazandırır.
• SATA SSD: IOPS değerleri daha düşük ama hâlâ HDD’den çok hızlı. Büyük ama orta performanslı depolama için tercih edilebilir.
• HDD: Yedek veya arşiv için mantıklı olabilir ancak aktif Nextcloud/ownCloud veri dizinini HDD üzerinde tutmak genelde mutsuzluk sebebi olur.

Pratik öneri: OS + veritabanı + cache için NVMe, kullanıcı dosyaları ve yedekler için daha geniş bir SATA SSD çoğu senaryoda ideal dengedir.

Dosya sistemi ve snapshot kullanımı

Linux tarafında klasik ext4 işinizi görür; ancak snapshot ve veri bütünlüğü açısından ZFS veya Btrfs ciddi avantaj sağlar:

• Hızlı anlık görüntüler (snapshot) alarak, birkaç saniye içinde tüm Nextcloud veri dizinini geri döndürebilirsiniz.
• Copy-on-write mimarisi sayesinde, özellikle yanlışlıkla silinen veya bozulmuş dosyaları geri almak kolaylaşır.
• Veri bütünlüğü denetimleri, sessiz disk hatalarına karşı ek güvence sağlar.

Özellikle büyük kurulumlarda, günlük dosya sistem snapshot’larını, harici yedeklerle birlikte kullanmak oldukça sağlıklı bir stratejidir.

Harici depolama: NFS, S3-uyumlu object storage ve hibrit yapı

Depolamayı tek bir VPS diski ile sınırlamak zorunda değilsiniz:

• NFS paylaşımları: Ayrı bir depolama sunucusu kurup VPS’e NFS ile bağlayabilirsiniz. Özellikle çok sunuculu (cluster) Nextcloud/ownCloud kurulumlarında ortak depolama gerekir.
• S3‑uyumlu object storage: Nextcloud, harici depolama özelliğiyle S3 API sunan sistemlere (MinIO gibi) bağlanabilir. Böylece dosyalarınızı ölçeklenebilir bir object storage’ta saklayabilirsiniz.
• Hibrit: Sık erişilen dosyalar VPS diskinde, arşiv veya büyük medya dosyaları object storage üzerinde tutulabilir.

VPS üzerinde kendi S3‑uyumlu depolamanızı kurmak istiyorsanız, VPS üzerinde MinIO ile S3‑uyumlu depolamayı üretim‑hazır kurma rehberimiz tam olarak bu ihtiyaca yönelik.

Ayrıca yedekleri nereye koyacağınızı planlarken, object storage, block storage ve file storage karşılaştırmasını yaptığımız yazıyı da okursanız, hangi katmanda neyi saklamanız gerektiği daha netleşir.

Şifreleme Mimarisi: Disk, Ulaşım ve Uygulama Katmanı

Kurumsal dosyalar, kişisel veriler, hukuki dokümanlar… Bunların sızması, bir “kötü şans” değil, doğrudan kriz sebebidir. Bu yüzden şifrelemeyi tek bir katmana bırakmak yerine, uçtan uca katmanlı bir şifreleme mimarisi kurmak gerekir.

Disk şifreleme (at-rest security)

VPS sunucunuzun diskleri çalınmasa bile, fiziksel seviyede erişim riski her zaman vardır. Bu nedenle:

• Linux tarafında LUKS ile tam disk şifreleme kullanmak mümkündür. Sunucu boot sırasında şifre girilmesi gerekir; bu üretim ortamında pratik değilse, en azından yedek diski şifrelemek iyi bir orta yol olur.
• Yedekleri tuttuğunuz uzak depolama veya object storage üzerinde server‑side encryption veya istemci tarafı şifreleme (ör. restic/borg ile) kullanın.

Ulaşım katmanı: HTTPS, TLS ve güvenli protokol ayarları

Nextcloud/ownCloud paneline ve WebDAV/Sync istemcilerine mutlaka HTTPS üzerinden erişilmelidir. DCHost VPS’ler üzerinde genellikle şu yaklaşımı tercih ediyoruz:

• Let’s Encrypt veya kurumsal SSL sertifikası ile zorunlu HTTPS
• Güncel TLS sürümleri (TLS 1.2+ ve mümkünse ağırlıkla TLS 1.3)
• Güçlü şifre takımları, HSTS ve OCSP stapling gibi modern HTTPS ayarları

HTTPS katmanını doğru kurgulama konusunda daha derinlemesine bir bakış için, TLS 1.3 ve modern şifre kümelerini anlattığımız yazılarımızdan da faydalanabilirsiniz.

Uygulama şifrelemesi ve anahtar yönetimi

Nextcloud ve ownCloud, sunucu taraflı şifreleme desteğine sahiptir. Bu özellik etkinleştirildiğinde, dosyalar diske şifrelenmiş olarak yazılır. Ancak burada kritik konu, anahtar yönetimidir:

• Şifreleme anahtarlarını kod deposunda, yedeklerde veya plain text konfigürasyon dosyalarında asla tutmayın.
• Uygulama ayarlarında kullanılan parolalar, veritabanı şifreleri ve API anahtarlarını ayrı bir secrets katmanında yönetin.

Bu konuda pratik yaklaşımı anlattığımız VPS’te .env ve gizli anahtar yönetimi rehberine göz atmanızı özellikle öneririm. Aynı prensipleri Nextcloud/ownCloud config.php ve diğer servis parolalarınız için birebir uygulayabilirsiniz.

Ek olarak, istemci taraflı şifreleme (örneğin kullanıcıların kendi bilgisayarında dosyaları şifreleyip öyle yüklemesi) ekstra güvenlik sağlar; ancak dosya paylaşımı ve web önizlemeleri açısından bazı kısıtları olduğunu da hesaba katmalısınız.

Yedekleme ve Felaket Kurtarma: Strateji, Araçlar ve Testler

Yedekleri olmayan bir Nextcloud/ownCloud kurulumunu, profesyonel olarak “kabul edilebilir” saymak mümkün değil. Özellikle fidye yazılımı ve kullanıcı hataları, bu tür platformlarda sandığınızdan çok daha sık veri kaybına sebep oluyor.

3‑2‑1 kuralı: Temel iskelet

Sağlam bir yedekleme stratejisi için klasik ama hâlâ geçerli bir kural var: 3‑2‑1 kuralı.

• Verinizin en az 3 kopyası olsun (canlı + 2 yedek)
• Bu kopyalar en az 2 farklı ortamda dursun (ör. VPS diski + harici disk/object storage)
• En az 1 kopya farklı bir lokasyonda (farklı veri merkezi veya bölge) saklansın

Bu kuralı nasıl gerçek ortama uygulayacağınızı, 3‑2‑1 yedekleme stratejisinin neden işe yaradığını anlattığımız yazıda detaylı örneklerle gösterdik. Aynı mantığı birebir Nextcloud/ownCloud için de kullanabilirsiniz.

Hangi seviyede yedek almalısınız?

İdeal bir Nextcloud/ownCloud yedekleme planı şu katmanların hepsini kapsar:

• Veritabanı yedeği: Kullanıcı hesapları, paylaşım kuralları ve meta veriler veritabanında tutulur. Sadece dosya dizinini yedeklemek yetmez.
• Veri dizini yedeği: nextcloud/data veya ownCloud’un veri dizini mutlaka düzenli olarak yedeklenmeli.
• Konfigürasyon yedeği: config.php, web sunucusu ayarları, crontab görevleri vb.
• Dosya sistemi snapshot’ları: ZFS/Btrfs kullanıyorsanız ekstra güvenlik için günlük snapshot iyi bir emniyet kemeri olur.

Uygulama‑tutarlı yedekler (veritabanı yazma işlemleri dondurulmuşken alınan yedekler) almak istiyorsanız, LVM snapshot veya benzeri teknikleri kullanan çözümleri değerlendirmeniz gerekebilir.

Yedek depolama: sıcak, soğuk ve arşiv katmanları

Tüm yedekleri en hızlı ve en pahalı NVMe depolamada tutmak zorunda değilsiniz. Tam tersine, mantıklı olan sıcak, soğuk ve arşiv katmanlı bir depolama stratejisi kurmaktır:

• Sıcak yedekler: Son 1–7 gün, hızlı geri dönüş gerektiğinde anında erişilebilen NVMe/SSD üzerinde.
• Soğuk yedekler: 1–3 ay arası kopyalar, daha ucuz SATA SSD veya yüksek kapasiteli depolamada.
• Arşiv yedekler: 6–12 ay (veya yasal gerekliliklere göre daha uzun) saklanması gereken, düşük erişim sıklıklı kopyalar; object storage veya benzeri çözümler üzerinde.

Bu yaklaşımı pratik örneklerle anlattığımız yedekler için sıcak, soğuk ve arşiv depolama stratejisi rehberinde maliyet ve performans açısından detaylı inceleyebilirsiniz.

Geri dönüş testleri (restore) ve runbook

Bir yedeğin gerçekten işe yarayıp yaramadığını anlamanın tek yolu, geri dönüş testi yapmaktır. Nextcloud/ownCloud için önerdiğimiz pratik:

• Belirli aralıklarla (ör. ayda 1) yedeklerden ayrı bir test VPS’ine restore yapın.
• Rastgele birkaç kullanıcı hesabı ile oturum açıp dosyaların gerçekten açıldığını, paylaşımların çalıştığını kontrol edin.
• Sıfırdan kurulum + yedekten dönüş adımlarını içeren bir felaket kurtarma runbook’u yazın ve dokümante edin.

Bu sayede gerçek bir sorun yaşandığında, panik hâlinde ne yapılacağını doğaçlama belirlemek zorunda kalmazsınız.

Güvenlik Sertleştirme: Erişim, Ağ ve Uygulama Katmanı

Güvenlik sadece güçlü bir parola belirlemekten ibaret değil. VPS’te çalışan Nextcloud/ownCloud ortamını üç katmanda düşünmek gerekir: erişim, ağ ve uygulama.

VPS erişim güvenliği

DCHost’ta önerdiğimiz temel iyi uygulamalar:

• SSH’yi parola ile değil, SSH anahtarı ile girişe kapatın.
• Varsayılan 22 portunu değiştirmek tek başına çözüm değil ama gürültüyü azaltır.
• UFW, firewalld veya nftables ile gereksiz tüm portları kapatın. Sadece 80/443 ve yönetim için SSH açık olmalı.
• fail2ban ile SSH ve web giriş denemelerinde kaba kuvvet (brute force) saldırılarını engelleyin.

Bu konuda adım adım ilerlemek için, VPS sunucu güvenliği için pratik ve ölçeklenebilir yaklaşımlar rehberimizi mutlaka okuyun; oradaki kontrol listesini Nextcloud/ownCloud VPS’inize birebir uygulayabilirsiniz.

Ağ ve WAF katmanı

• Güçlü bir WAF (Web Application Firewall) ile bilinen saldırı imzalarını otomatik engellemek mümkündür (ModSecurity + OWASP CRS gibi).
• Nextcloud/ownCloud giriş ekranı için oran sınırlama (rate limiting) uygulamak, deneme‑yanılma saldırılarını ciddi biçimde yavaşlatır.
• IP bazlı erişim kısıtlamaları (ör. yönetim paneline sadece ofis IP’lerinden erişim) ek bir güvenlik katmanı sağlar.

Uygulama seviyesinde güvenlik

Nextcloud/ownCloud’un kendi içindeki ayarlar da en az altyapı kadar önemlidir:

• Her kullanıcı için güçlü parola politikası belirleyin (minimum uzunluk, karmaşıklık, parola süresi).
• Varsa iki faktörlü kimlik doğrulama (2FA) eklentilerini mutlaka etkinleştirin.
• Uygulama mağazasından sadece güvenilir, gerçekten ihtiyacınız olan eklentileri yükleyin.
• Güncellemeleri ertelemeyin; yeni sürümler çoğu zaman güvenlik düzeltmeleri içerir.

DCHost Üzerinde Örnek Nextcloud / ownCloud Mimarisi

Teoride anlattıklarımızı pratik bir senaryoya indirelim. DCHost üzerinde orta ölçekli bir şirket için yaygın olarak kurduğumuz örnek mimariyi düşünün:

• Uygulama VPS’i: 4 vCPU, 8 GB RAM, 200 GB NVMe SSD
  • Üzerinde Nginx + PHP-FPM + Nextcloud/ownCloud kurulumu
  • Let’s Encrypt ile otomatik yenilenen SSL sertifikaları
  • fail2ban, güvenlik duvarı ve temel hardening ayarları
• Veri diski: Aynı VPS’e bağlı ek 1 TB SSD disk
  • nextcloud/data dizini ve dosya sistem snapshot’ları bu diskte
• Yedekleme VPS’i: 2 vCPU, 4 GB RAM, 2 TB SATA SSD
  • Günlük veritabanı dump’ları ve dosya yedekleri burada saklanıyor
  • Haftalık olarak object storage’a şifreli arşiv kopyaları gönderiliyor

Yedekleme tarafında restic/borg gibi bir araç ile hem şifreli hem de artımlı yedekler alıp, saklama politikalarını (ör. son 7 gün, son 4 hafta, son 12 ay) otomatik yönetmek mümkün. Bu tür bir senaryoda, yedek depolamayı maliyet‑performans dengesinde doğru konumlandırmak için az önce link verdiğimiz sıcak‑soğuk‑arşiv stratejisini doğrudan uyguluyoruz.

Tüm bu katmanların sağlıklı işlemesi için, hem güvenlik hem de yedek stratejilerinin yazılı olması önemli. Özellikle gizli anahtarların ve erişim bilgilerini merkezi ve güvenli şekilde yönetmek için, tekrar hatırlatmak gerekirse .env ve gizli anahtar yönetimi rehberinde anlattığımız pratikleri birebir kullanabilirsiniz.

Özet ve Sonraki Adımlar

Nextcloud veya ownCloud kurmak, “sunucuya yazılım kurdum, bitti” seviyesini çoktan aşan bir konu. Doğru VPS seçimi, depolama mimarisi, şifreleme katmanları ve yedekleme stratejisi tasarlanmadan kurulan her sistem, bir noktada veri kaybı, performans sıkışması veya güvenlik olayıyla sınanıyor. Bu yazıda; disk türlerinden dosya sistemi snapshot’larına, TLS ayarlarından 3‑2‑1 yedekleme kuralına kadar pratikte işe yaradığını gördüğümüz yaklaşımları özetledik.

Sonraki adım, kendi senaryonuzu masaya yatırmak: Kaç kullanıcı, ne kadar veri, hangi mevzuat yükümlülükleri (KVKK/GDPR), hangi yedek saklama süreleri? Bu sorulara net cevap verdiğinizde, DCHost üzerindeki VPS, dedicated veya colocation seçenekleri ile size özel bir Nextcloud/ownCloud mimarisi tasarlamak çok daha kolaylaşıyor. İsterseniz ufak bir pilot kurulumla başlayıp, yedekleme ve güvenlik kontrollerinizi oturttuktan sonra ölçeklendirebilirsiniz. Mimarinizi planlarken takıldığınız noktada, altyapı ekibimizle birlikte teknik ayrıntıları sizinle aynı dilden konuşmaya her zaman hazırız.