Beş VPS'ten Proxmox'lu Tek Bir Adanmış Sunucuya Geçtim ve Barındırıcıları Beslemeyi Bıraktım

TL;DR: Üç sağlayıcıdan alınan beş VPS'in parçalanmış altyapısı → Proxmox VE üzerinde tek bir Ryzen 7 9700X / 64GB ECC / 2× NVMe ZFS-mirror adanmış sunucu. İçeride rollerine göre VM/LXC'ler, port yönlendirme yerine NetBird-mesh, engelleri aşmak ve TLS sonlandırması için ayrı bir VPS'de çıkış nodu, yedeklemeler için PBS. Para artı, kontrol artı, sinirler artı. Bu makalede — neden, nasıl ve yolda nereye bastığım, böylece siz basmayasınız.

Open

Neden Bunu Başlattım?

Geçen yılın sonuna doğru, üç farklı barındırıcının beş farklı VPS'i için ödeme yaptığımı fark ettim. Biri Discourse forumu için, ikincisi PHP ve MySQL üzerinde eski bir forum için, üçüncüsü faturalandırma ve Telegram botları için, dördüncüsü VPN/proxy, beşincisi statik içerik ve çeşitli küçük araçlar için. Ayrıca n8n, Vaultwarden ve birbirini sürekli izleyen birkaç Uptime Kuma örneği de oradaydı (başka nasıl olabilirdi ki).

Kötü olanlar şunlardı:

• Para. Toplamda, bu özelliklere sahip tek bir iyi adanmış sunucunun maliyetiyle kabaca aynı miktara geliyordu (ancak orada paylaşımlı, burada ise adanmış).
• İzolasyon yok. Bir istemcinin botu bellek sızdırmaya başlarsa — benim forumum yavaşlamaya başlar. Aynı sunucuda. Harika.
• Yedeklemeler — berbat. Her VPS'de kendi rsync cron'u S3'e, her yerde farklı saklama süreleri, artımlı yedekleme yok, geri yükleme — tam bir macera.
• Ağ salatası gibi. Farklı portlar üzerinden SSH, Cloudflare Tunnels üzerinden yönlendirilen, iki VPS arasında manuel olarak kurulan WireGuard üzerinden, üç farklı yerde yapılandırmalarla. Yeni bir makine eklediğimde her seferinde entegrasyon günü sürüyordu.
• Güncelleme kıyameti. Beş farklı Ubuntu/Debian sürümünde ve farklı paketlerde yükseltmeleri manuel olarak yapmam gerekiyordu ve asla aynı anda yapamazdım. Altı ayda bir, "her şeyi güncelle, hiçbir şeyi bozma" görevini kahramanca tamamlıyordum.
• CPU ve RAM boşa harcanıyor. Her VPS "zirveye göre" rezerve edilmişti, ancak ortalama olarak %15-20 kullanılıyordu. Boşa giden para.

Kısacası — altyapının "oy, bir hizmet daha lazım — VPS alayım" prensibiyle büyüdüğü klasik bir durum. Hepsini birleştirmem gerekiyordu.

Ne Seçtim ve Neden

Donanım

Adanmış bir sunucu aldım:

• CPU: AMD Ryzen 7 9700X (8 çekirdek / 16 iş parçacığı, Zen 5)
• RAM: 64 GB DDR5 ECC 5200 MHz
• Diskler: 2× NVMe 512 GB kurumsal → ZFS ayna
• Ağ: 1 Gbps sınırsız
• Fiyat: Aynı OVH'deki iki orta seviye VPS kadar

Hipervizör

Proxmox VE 9.x. Alternatifleri düşündüm, ancak kısaca:

• Saf Docker — izolasyon yok, normal anlık görüntüler yok, yalnızca compose araçlarıyla yedekleme, disk — tek bir çöp kutusu.
• VMware ESXi — artık ücretsiz değil, Broadcom lisansı harika, teşekkürler.
• XCP-ng — iyi, ama kişisel olarak Proxmox'u ezbere biliyorum ve topluluğu orada daha canlı.
• Kubernetes — hayır, ben tek kişiyim, mağazaya gitmek için uçak toplamak istemiyorum.

Proxmox bana ihtiyacım olan her şeyi veriyor: izolasyon gerektiren her şey için KVM sanal makineleri (Docker, özel çekirdekler, farklı dağıtımlar); kaynakları (Veritabanları, izleme, küçük hizmetler) kaydetmek mümkün olduğunda LXC kapsayıcıları; yedeklemeler için yerleşik PBS; ZFS kutudan çıktığı gibi; anlık görüntüler; canlı geçiş (eğer bir gün ikinci adanmış sunucu olursa); terminale yazmak istemediğimde fareyle tıklayabileceğim web arayüzü.

Mimari: Genel Şema

Önce ne elde ettiğimi göstereceğim, sonra oraya nasıl ulaştığımı anlatacağım. Open

Mantık şöyle:

1. Adanmış sunucuda Proxmox çalışıyor. vmbr0 üzerinde herkese açık IP Y.Y.Y.Y'yi tutuyor.
2. İçeride, özel ağ 10.10.10.0/24 ile ikinci bir köprü vmbr1 oluşturuldu. Bu, "iç LAN"'ın bir benzeridir — tüm VM'ler ve LXC'ler orada asılıdır, ana makineden NAT üzerinden dışarıya çıkar, dışarıdan gelen herkese açık portları yoktur.
3. Ana makinenin kendisinde yalnızca üç şey çalışıyor: Caddy (iç ters proxy), nftables (güvenlik duvarı) ve NetBird (VPN ajanı). Ana makinede Docker yok, ana makinede uygulama mantığı yok. Ana makine kutsal bir kovadır, görevi hipervizör olmak ve düşmemektir.
4. Sanal makineler rollere göre ayrılmıştır: biri forum için, biri arka plan hizmetleri ve botlar için, biri Dokploy ve kullanıcı uygulamaları için vb. Aralarında doğrudan 10.10.10.x üzerinden görünürlük var, dışarıya — yalnızca ana makine Caddy'si üzerinden.
5. LXC kapsayıcıları — "hafif" her şey için: birkaç sürümde Postgres örnekleri, Proxmox Yedekleme Sunucusu, izleme panoları. Bunlar da vmbr1'de.
6. Ayrı bir çıkış nodu ("Peer Caddy") — başka bir sağlayıcıda, hedef kitlem için uygun bir ağda küçük bir VPS. Üzerinde TLS (Let's Encrypt) sonlandıran ve HTTP'yi NetBird-mesh üzerinden adanmış sunucuya proxy'leyen bir Caddy çalışıyor. Tüm genel alan adları için DNS, bu VPS'ye bakar, adanmış sunucuya değil.
7. NetBird mesh, adanmış sunucuyu, çıkış nodunu ve benim dizüstü bilgisayarımı (ayrıca henüz her şeyin taşınmadığı birkaç eski sunucuyu) birbirine bağlar. Bu, SSO kimlik doğrulaması üzerinden WireGuard'dır, dışarıdan açık portlar olmadan.

Bu tür bir izolasyonun çıkış nodu aracılığıyla neden gerekli olduğu ayrı bir konuşma, ona tekrar döneceğim.

Proxmox Kurulumu: Nasıl Kurdum?

Adanmış sunucuyu sipariş ettim, ilk önyüklemede Proxmox'u kurtarma modu/KVM aracılığıyla yükledim (OVH'de her ikisi de var — KVM benim için daha uygun, tüm süreci görüyorum). Kurulum sırasında:

• ZFS RAID1 her iki NVMe'de (ashift=12, compression=lz4 hemen etkinleştirildi)
• varsayılan bölümleme, Proxmox rpool/ROOT, rpool/data, takas alanını kendisi oluşturur.

Ardından — kurulumdan sonra temel temizlik. Bu bir zorunluluktur, aksi takdirde Proxmox abonelik hataları verir ve optimum şekilde çalışmaz.

1# 1. Kurumsal depoyu kaldır (abonelik yok)
2sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list
3echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" \
4  > /etc/apt/sources.list.d/pve-no-subscription.list
5apt update && apt full-upgrade -y
6
7# 2. "Geçerli abonelik yok" bildirim penceresini kaldır
8sed -Ezi.bak "s/(Ext\.Msg\.show\(\{[^}]+?title: gettext\('No valid sub)/void\(\{ \/\/\1/g" \
9  /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
10systemctl restart pveproxy
11
12# 3. Host adı / saat dilimi
13hostnamectl set-hostname dedik-waw
14timedatectl set-timezone Europe/Warsaw

SSH Sertleştirme

Hemen. "Sonra değil". Sonra asla gelmez.

1cat > /etc/ssh/sshd_config.d/hardening.conf << 'EOF'
2Port 22222
3PermitRootLogin prohibit-password
4PasswordAuthentication no
5MaxAuthTries 3
6ClientAliveInterval 300
7ClientAliveCountMax 2
8EOF
9
10mkdir -p ~/.ssh
11echo "ssh-ed25519 AAAA... sizin-anahtarınız" >> ~/.ssh/authorized_keys
12chmod 600 ~/.ssh/authorized_keys
13systemctl restart sshd

Güvenlik duvarında 22 numaralı portu kapattım, yalnızca standart dışı olanı bıraktım. Bu, belirsizlik yoluyla güvenlik değil, loglardaki arka plan gürültüsünü azaltmaktır — ilk saat içinde 22 numaralı porta 50 bin tane kaba deneme gelir, loglarda hiçbir şey görünmez. 22222'de — sessizlik ve anomalileri gerçekten izleyebilirsiniz.

NVMe ve 64GB RAM için ZFS Yapılandırması

ZFS varsayılan olarak ARC için RAM'in yarısını yemek ister. Bu, dosya sunucusu için normaldir ve hipervizör için kesinlikle tavsiye edilmez, çünkü sanal makineler için bellek gereklidir. ARC'yi makul 16 GB'a sıkıştırıyoruz:

1cat > /etc/modprobe.d/zfs.conf << 'EOF'
2options zfs zfs_arc_max=17179869184
3options zfs zfs_arc_min=4294967296
4EOF
5update-initramfs -u

Bellek dağılımım:

• ~16 GB — ZFS ARC
• ~44 GB — VM/LXC
• ~4 GB — sistem, tamponlar, ek yük

Havuzun kendisi için yararlı ayarlar:

1zfs set compression=lz4 rpool
2zfs set atime=off rpool
3zfs set xattr=sa rpool
4zfs set dnodesize=auto rpool
5zfs set relatime=on rpool
6
7zfs set recordsize=64K rpool/data    # VM diskleri için
8zfs set sync=standard rpool/data
9
10zpool set autotrim=on rpool          # NVMe için kritik

compression=lz4 CPU maliyeti neredeyse sıfırla %20-30 yer tasarrufu sağlar. VM blok cihazları için recordsize=64K yazma amplifikasyonu ile performans arasında en iyi ödünleşmedir.

İç Ağ ve Güvenlik Duvarı

NAT ile dışarıya dışarıya çıkan bir iç ağ için ikinci bir köprü oluşturdum:

1auto vmbr1
2iface vmbr1 inet static
3    address 10.10.10.1/24
4    bridge-ports none
5    bridge-stp off
6    bridge-fd 0
7    post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
8    post-up   iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE
9    post-down iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE

Artık vmbr1 köprüsündeki herhangi bir VM/LXC, 10.10.10.x yerel adresini alır ve ana makine üzerinden internete çıkar, ancak dışarıdan görünmez.

nftables ile policy drop. Yalnızca açık olması gerekenler açıktır, geri kalanı sessizce bırakılır. Minimum set:

1table inet filter {
2    chain input {
3        type filter hook input priority 0; policy drop;
4
5        iif lo accept
6        ct state established,related accept
7        ip protocol icmp accept
8        ip6 nexthdr icmpv6 accept
9
10        tcp dport 22222 accept           # SSH
11        tcp dport 8006 accept            # Proxmox UI (yalnızca NetBird'den, aşağıya bakın)
12        tcp dport { 80, 443, 8080 } accept   # Caddy
13        udp dport 29899 accept           # NetBird
14
15        iif vmbr1 accept                 # iç ağ — her şey izinli
16        iif wt0 accept                   # NetBird arayüzü — güvenilir de
17    }
18
19    chain forward {
20        type filter hook forward priority 0; policy drop;
21        iif vmbr1 oif vmbr0 accept
22        ct state established,related accept
23    }
24}

Proxmox UI (8006 portu) erişimini CF/güvenlik duvarı aracılığıyla fiziksel olarak internetten kapattım ve yalnızca NetBird üzerinden erişiyorum. Genel IP üzerinden arayüz hiç yanıt vermiyor. PBS UI, pano ve tüm yönetici arayüzleri için de aynı durum — yalnızca mesh üzerinden. Dışarıdan yalnızca hizmetlerin gerçekten genel portları açıktır.

NetBird mesh: Neden Klasik WireGuard Değil?

Normal WireGuard'ı uzun süre kullandım ve sunucu sayısı üçü geçtiğinde iyiydi. Sonrasında yapılandırmaları yönetmek acı verici hale geldi: her yeni eş eklemesi "tüm nodlardaki yapılandırmayı güncelle, allowed_ips'yi unutma, servisi yeniden başlat, başka bir eşe giden rotayı bozmadığından emin ol" haline geldi.

NetBird, WireGuard üzerine bir yönetim düzlemidir. Teknik olarak arka planda hala wg kullanıyor, ancak:

• nodlar sinyal sunucusu aracılığıyla birbirini bulur, NAT-traversal otomatik olarak gerçekleşir
• SSO üzerinden kimlik doğrulaması (benim durumumda — Authentik aracılığıyla), anahtar paylaşımı olmadan
• erişim, web arayüzü üzerinden politikalarla yönetilir, makine grupları ve aralarındaki kurallar oluşturulabilir
• yerleşik SSH proxy'si: ssh user@machine.netbird.cloud üzerinden bağlanabilir ve SSO kimlik doğrulaması alabilirsiniz (Authentik'te onay ile). Noddaki port 22'yi bile dışarı açmaya gerek yok.

NetBird ajanını kurdum:

• Proxmox ana makinesinde
• yönetici veya diğer VM'ler tarafından görülmesi gereken her VM'de
• çıkış nodunda
• dizüstü bilgisayarımda

Sonuç olarak, dizüstü bilgisayarımdan herhangi bir makineye, port yönlendirme, güvenlik duvarı delikleri veya ek koruyucu ana bilgisayar olmadan tek bir komutla bağlanıyorum. Ve özel VM'lerin hiçbirinde açık SSH yok — hepsi sadece vmbr1 artı mesh wt0'da.

Sanal Makineler vs Kapsayıcılar: Kendim İçin Nasıl Çözdüm?

Neredeyse her zaman işe yarayan basit bir kural:

Sonuç olarak, şöyle bir durumum oluştu:

Sanal Makineler (KVM):

• forum — Discourse standart başlatıcı kapsayıcısında. İçinde Docker var.
• services — bir sürü küçük şey: webhook botları, AI botu, faturalandırma paneli, Vaultwarden, Uptime Kuma. Hepsi Docker compose içinde, servis başına bir klasör.
• legacy — eski PHP forumu (IPS) yerel PHP-FPM ve Caddy ile VM üzerinde. Docker'a paketlemek istemedim — çok fazla eski kod var, olduğu gibi bırakmak daha kolaydı.
• dokploy — kullanıcı uygulamaları (Next.js, Postgres, Redis) için Docker Swarm + Dokploy, Git üzerinden dağıtım.

LXC:

• pbs — Proxmox Yedekleme Sunucusu (aşağıya bakın).
• pg16, pg17, pg18 — üç ayrı, farklı büyük sürümlerdeki Postgres. Ek: farklı uygulamalar farklı büyük sürümler istiyor ve ben her birini yukarı/aşağı taşımak istemiyorum.
• dashboards — Homarr (başlangıç sayfası), Uptime Kuma ve Beszel hub içeren tek bir kapsayıcı. Hepsi aynı compose içinde, çünkü mantıksal olarak aynı şeyi — gözlemlemeyi — yapıyorlar.

Her VM, yüke bağlı olarak 2-8 vCPU çekirdeği ve 2-8 GB RAM alır. Çekirdekler güvenli bir şekilde aşırı tahsis edilebilir — VM'ler için toplamda fiziksel çekirdeklerden daha fazla çekirdek belirttim ve bu mükemmel çalışıyor, kimse aynı anda CPU'ya takılmadığı sürece.

Ters Proxy: İki Katlı Caddy

Open

Proxmox içinde Caddy'yi bir VM yerine ana makineye kurdum. Neden? Çünkü adanmış sunucunun genel portlarını dinlemesi ve Host başlığına göre ilgili VM'ye yönlendirmesi gerekiyor ve bunun için port yönlendirmeli ayrı bir VM oluşturmak fayda sağlamayan fazladan bir katman. Caddy hafif, Go ile yazılmış, systemd birimi, yapılandırma tek dosyada.

Bu ana makine Caddy'si yalnızca 8080 HTTP portunu dinliyor ve 10.10.10.x üzerindeki arka uçlara yönlendiriyor. Üzerinde TLS yok.

1:8080 {
2    @forum host forum.example.com www.forum.example.com
3    handle @forum {
4        reverse_proxy http://10.10.10.111:80 {
5            header_up X-Forwarded-Proto https
6            header_up X-Real-IP {header.X-Real-IP}
7            header_up Host {host}
8        }
9    }
10
11    @panel host panel.example.com api.panel.example.com
12    handle @panel {
13        reverse_proxy http://10.10.10.111:8081 {
14            header_up X-Forwarded-Proto https
15            header_up X-Real-IP {header.X-Real-IP}
16            header_up Host {host}
17        }
18    }
19
20    @dokploy host app1.example.com app2.example.com
21    handle @dokploy {
22        reverse_proxy http://10.10.10.114:80 {
23            header_up X-Forwarded-Proto https
24            header_up X-Real-IP {header.X-Real-IP}
25            header_up Host {host}
26        }
27    }
28}

TLS sonlandırması ve sertifikaları — ayrı bir çıkış nodunda, Docker içinde, aynı prensiple:

1{
2    email me@example.com
3}
4
5forum.example.com {
6    reverse_proxy http://100.x.y.z:8080 {
7        header_up X-Forwarded-Proto {scheme}
8        header_up X-Forwarded-For {remote_host}
9        header_up X-Real-IP {remote_host}
10        header_up Host {host}
11    }
12}

100.x.y.z — adanmış sunucunun NetBird adresi. İstek çıkış noduna HTTPS üzerinden gelir, şifresi çözülür, NetBird-mesh üzerinden HTTP olarak adanmış sunucuya gider, orada Proxmox Caddy Host'a göre eşleştirir ve iç VM'ye yönlendirir. Çıkış nodu ile adanmış sunucu arasındaki HTTP tasarım gereği — mesh'e güveniyoruz, burada dış trafik yok.

Neden Çıkış Nodu?

Birkaç neden:

1. Engelleri Aşma. OVH alt ağlarının bir kısmı Rusya Federasyonu'nda engelleniyor. Çıkış nodu, IP'si engellenmeyen bir sağlayıcıda bulunuyor. Genel alan adları için DNS oraya bakar.
2. TLS Sonlandırması Tek Bir Yerde. Sertifikalar yalnızca bu tarafından yayınlanır, Let's Encrypt'in yalnızca IP'si kontrol sırasında kullanılır. Bu, tüm DNS kontrol testlerini basitleştirir ve adanmış sunucunun 80/443 üzerinden internetten tamamen görünmez olmasını sağlar.
3. Ek İzolasyon Katmanı. Birisi DDoS saldırısı başlatırsa — adanmış sunucuya değil, çıkış noduna saldırır. Çıkış nodunda minimum verim var, onu yeniden oluşturmak 10 dakika sürer.
4. Genel Ön Yüzü Arka Uçtan Ayırma. Adanmış sunucudaki Caddy güncellemelerini veya deneylerini rahatça yapabilirim, oysa internete gerçek arayüzüm ayrı ve kararlı.

Tek bir dezavantajı var: her istek için ek bir atlama nedeniyle ~5-15 ms eklenir. Web için bu fark edilmez.

Ayrıca, bazı hizmetler için ana makinede doğrudan Caddy 80/443 üzerinde, çıkış nodu olmadan çalışır — bu çıkış noktası üzerinden geçirmem gereken alan adları için (örneğin, durum uç noktaları, izleme, DNS'in zaten adanmış sunucuya baktığı hizmet). Bu paralel çalışır: ana makinedeki Caddy hem :8080 (çıkış nodundan iç) hem de :80/:443 (internet'ten doğrudan) dinler, rotalar farklıdır.

Geçiş: Gözyaşı Olmadan ve Neredeyse Kesintisiz Nasıl Geçtim?

Bu en ürkütücü aşamaydı. Beş sunucu, otuz civarı hizmet, canlı kullanıcıları olan üretim forumu, kesinlikle kaybedilemeyecek aktif abonelikleri olan faturalandırma, veritabanları.

Strateji — tek tek hizmet geçişi, "en az kritik olandan en kritik olana" sırasına göre:

1. Önce küçük araçlar ve statik web siteleri taşındı (bir şey olursa kimse fark etmez).
2. Sonra botlar ve arka plan hizmetleri (bunlar da bir dakika kesintiye dayanır).
3. Sonra veritabanları (önceden test edilmiş geri yüklemelerle).
4. Sonra bu veritabanlarına bakan uygulamalar.
5. En son olarak — uzun bir son senkronizasyon turu ve DNS değişikliği ile ana forum.

Geçiş Kanalı

Önce eski sunucularda NetBird'ü kurdum. Bu hemen iki şeyi çözdü: özel ağlarda güvenli bir şekilde SSH ile bağlanabiliyorum ve rsync verileri açık internete göstermeden NetBird üzerinden WireGuard üzerinden gidiyor.

Her hizmet için savaş komutu şöyleydi:

1# Yeni adanmış sunucudan, eski sunucunun NetBird IP'si üzerinden:
2rsync -avzP --delete \
3  -e "ssh -p 5322" \
4  root@100.76.108.210:/var/discourse/shared/standalone/ \
5  /target/discourse/shared/standalone/

Veritabanları için — dosya kopyası değil, yedek al + geri yükle. Postgres/MySQL dosyalarını "sıcakken" asla kopyalamayın, bu ölüm bileti.

1# Eski sunucuda
2docker exec -it shm-vsem-mysql mysqldump -u root -p shm-vsem | \
3  gzip > /tmp/shm-vsem.sql.gz
4
5# Yeni sunucuda, NetBird üzerinden
6scp -P 5322 root@100.76.108.210:/tmp/shm-vsem.sql.gz /tmp/
7zcat /tmp/shm-vsem.sql.gz | docker exec -i shm-vsem-mysql mysql -u root -p shm-vsem

Discourse için — yerel discourse backup / discourse restore ./launcher enter app aracılığıyla. İçinde Postgres yedekleri + yüklemeler + yapılandırmalar doğru bir şekilde toplar ve tam olarak aynı şekilde geri yükler.

DNS Değişikliği

Hizmet yeni yerde kurulup iç adresten çalıştığı doğrulandıktan sonra — her iki kurulumu da 5-15 dakika boyunca paralel çalıştırdım, veri senkronizasyonunu izledim ve ardından DNS'i yeni sunucuya değiştirdim. Kayıtların TTL'sini geçişten bir gün önce önceden 60-300 saniyeye düşürmüştüm.

Sürekli gönderi yapan aktif kullanıcıları olan Discourse için şöyle yaptım:

1. Her şeyi yeni yerde kurdum.
2. Doğrulamayı çalıştırdım (giriş, gönderi, S3'e dosya yükleme, arama).
3. Eski kurulumda read_only_mode'u etkinleştirdim (Discourse bunu kutudan çıktığı gibi yapabiliyor).
4. Son bir rsync yüklemesi + son veritabanı yedeğini aldım.
5. Yenisinde kurdum, read-only'yi kapattım.
6. DNS'i değiştirdim.
7. Eski sunucuda bir hafta boyunca hiçbir şeye dokunmadım — "ya olursa" ihtimaline karşı.

Kullanıcılar için gerçek kesinti süresi — hizmet başına yaklaşık iki dakika.

Yoldaki Sürprizler

• pct restore sırasında izinler. unprivileged 1 altındaki LXC, UID'leri 100000 kaymasıyla eşler. Eski sunucuda dosyalara 1000 UID'si ile sahipseniz — yenisinde 101000 UID'si ile olacak ve uygulama onları görmeyecektir. Bu, restore'dan sonra chown ile veya riskleri anlıyorsanız --unprivileged 0 ile çözülür.
• OVH sanal makinelerindeki Docker ipv6 bazen sorunlu başlıyordu — Docker daemon'unda ipv6'yı devre dışı bırakarak çözdüm ("ipv6": false).
• VM'lerde zaman. Birkaç kez ana makine ile VM arasındaki sistem saati farkını yakaladım, bu da TLS ve imzaları bozuyordu. Çözüm — her VM'de systemd-timesyncd veya chrony ve Proxmox ajanında host.use-time.
• İki sürüm arasında Discourse geçişi. Eski sunucudaki Discourse, yenisinde kurduğunuzdan daha yeniyse — restore başarısız olur. Yeni kurulumda sürüm aynı veya daha yüksek olmalıdır.
• Dokploy için resim kayıt defteri. Dokploy meta verilerini dokploy-postgres yedeği aracılığıyla taşıdığımda, veritabanında eski IP'deki eski yerel kayıt defterine başvurular kaldı. Uygulamalar başlatılmaya çalıştığında 100.76.117.115:5000'e gidiyor ve No such image hatasıyla çöküyordu. Çözüm — Dokploy UI'da her uygulamayı yeniden derlemek; yerel derleme resmi zaten yeni sunucuya yerleştirir.

Yedeklemeler: Aynı Adanmış Sunucuda PBS + Site Dışı

Burada kendimle ayrı bir felsefi tartışma yaptım: aynı donanıma yedeklemek veya değil. Cevap: hem evet, hem hayır.

Open

Seviye 1 — Havuzun kendisindeki ZFS anlık görüntüleri. Neredeyse ücretsizdirler (copy-on-write), anında alınırlar, anında geri yüklenirler. Otomatik rpool/data anlık görüntülerini her 15 dakikada bir 24 saat saklama süresiyle, ayrıca günlük olarak bir hafta saklama süresiyle tutuyorum. zfs-auto-snapshot kullanılır. "Ah, az önce üretim veritabanını sildim" durumuna karşı koruma:

1apt install zfs-auto-snapshot
2# Sonra bu otomatik olarak cron aracılığıyla frequent/hourly/daily/weekly/monthly oluşturur

Seviye 2 — Aynı ana makinede ayrı bir LXC'de Proxmox Yedekleme Sunucusu. Bu, vzdump aracılığıyla VM/LXC'nin tam artımlı yedekleridir, parça düzeyinde tekilleştirilmiştir. PBS, anlık görüntüleri ayrı bir ZFS veri kümesinde saklar, onları bir depo olarak görür, her VM'nin kendi artımlı zinciri vardır.

Proxmox'ta ayar: Datacenter → Backup → Add. Zamanlama: her gün sabah 4'te, saklama keep-daily=7 keep-weekly=4 keep-monthly=3. Hepsi fareyle.

PBS'yi aynı ana makinedeki bir LXC'ye yerleştirmek bir uzlaşmadır. Artısı: ayrı bir donanıma gerek yok, yedekleme localhost üzerinden gidiyor, yerel SSD hızında, saklama/tekilleştirme mükemmel çalışıyor. Eksisi: adanmış sunucu tamamen ölürse — yedeklemeler de ölür. Bu yüzden var...

Seviye 3 — PBS deposunu site dışı S3'e senkronize etme. PBS, S3 uyumlu depoya sync job yapabilir. Her gece Selectel'in S3'ündeki ayrı bir kovaya (herhangi biri olabilir — Backblaze, Wasabi, Cloudflare R2) anlık görüntüleri yüklüyorum. Oradaki saklama süresi iki haftadır, çünkü daha fazlası gerekmiyor: uzun vadeli kullanım için yerel PBS var ve site dışı yedekleme — "tüm veri merkezi yandı" sigortasıdır.

Seviye 4 — Uygulama verileri ayrı olarak. Discourse kendi yedeklerini alır ve bunları S3'e koyar (bu onun yerel özelliğidir). Yani PBS ve hatta tüm adanmış sunucu kaybolsa bile — hala Discourse'un kendi bulutlarındaki tutarlı yedekleri var.

1# PBS'den tam bir VM geri yükleme — kelimenin tam anlamıyla tek komut:
2pvesm list backup-pbs    # ne olduğunu görmek için
3qmrestore backup-pbs:backup/vzdump-qemu-201-2026_04_06-04_00_03.vma.zst 999 \
4  --storage local-zfs
5# ve bir dakika sonra 999 VMID'sinde, 4 sabah itibarıyla forum-VM'nin bir kopyası çalışıyor.

Bu kritik bir nokta: geri yüklemeyi denemediğiniz yedeklemeler yedekleme değildir. Ayda bir kez rastgele bir VM'yi boş bir VMID'ye test geri yüklemesi yaparım, çalıştığını kontrol ederim ve silerim. Sıkıcı ama bir keresinde tam olarak bu şekilde, cron'lardan birinin /tmp/... içine yazdığını ve yedekleme sırasında atlandığını, bu yüzden uygulamanın geri yüklemeden sonra manuel bir adım gerektirdiğini buldum.

İzleme

15 makinem varken Prometheus + Grafana + Alertmanager + Loki gibi derleyiciler toplamayı sevmiyorum. Bu yüzden üç hafif araçta durdum, hepsi tek bir LXC'de:

• Beszel — her VM'deki ajanlardan metrik toplar (CPU, RAM, diskler, ağ arayüzleri, Docker kapsayıcıları). Hub LXC'de yaşar, ajanlar her VM/LXC'de systemd birimi aracılığıyla. Beszel'in kendi kimlik doğrulaması var, PocketBase üzerinden, bu bazen sakıncalı (aşağıya tıklama hakkında) ama genel olarak çalışıyor.
• Uptime Kuma — HTTP/HTTPS/Ping/TCP üzerinden sorgular. Tüm genel (alan adları), tüm iç hizmetler (NetBird üzerinden) ve mesh'teki tüm nodların ping'leri oraya kaydedildi. Uyarılar — Telegram'da.
• Homarr — tüm yönetici arayüzlerine bağlantılar içeren başlangıç sayfası. PBS UI'nin hangi portta asılı olduğunu, Dokploy'un hangi portta, Vaultwarden'ın hangi portta olduğunu hatırlamamak için. Sadece Homarr'ı açıp tıklıyorum.

Üçü de tek bir Docker compose içinde, tek bir LXC'de, yalnızca NetBird üzerinden erişilebilir.

Beszel ile Tıklama, siz basmayasınız diye: Beszel'in PocketBase'de iki kullanıcı tablosu var — _superusers (CLI/API için) ve users (web arayüzü için). CLI superuser upsert üzerinden parolayı sıfırlarsanız — yalnızca _superusers'ı sıfırlarsınız ve UI'da users üzerinden oturum açarsınız ve parola uymuyor. Bu, REST API aracılığıyla /api/collections/users/records/<id>'ye bir PATCH isteği ile düzeltilir.

Sonuç Olarak Ne Elde Ettim?

Yaklaşık üç haftalık bir geçişin ardından, son hizmetler oturduğunda, bir çizgi çektim:

Bana duygusal olarak en büyük faydası — bir şeye dokunmaktan korkmamayı öğrenmek oldu. Herhangi bir tehlikeli işlem (yükseltme, geçiş, deney) şimdi bir anlık görüntü ile başlar ve 30 saniyede bir onay veya geri alma ile biter. Hata maliyeti bir büyüklük mertebesi düştüğü için yeni şeyler denemeye daha sık başladım.

Tekrarlayacaksanız Kontrol Listesi

Kendinizi benimle aynı belirtileri yaşarken bulursanız — işte hangi sırayla hareket etmenin mantıklı olduğuna dair kısa bir kontrol listesi:

1. Tüm VPS'ler için birlikte ne kadar ödediğinizi hesaplayın ve OVH/Hetzner/LeaseWeb'deki adanmış sunucu fiyatlarıyla karşılaştırın. Şaşıracaksınız.
2. ZFS planlıyorsanız ECC RAM alın. Tasarruf etmeyin.
3. Ayna içinde en az iki disk alın. Tek disk satış için uygun değil.
4. Proxmox'u kurtarma modu + debootstrap ile değil, KVM/IPMI üzerinden kurun. Daha az acı.
5. Hemen SSH anahtarlarını, standart dışı portu ayarlayın, parolaları devre dışı bırakın, fail2ban'ı kurun.
6. Hemen ZFS ARC'yi sınırlayın. Varsayılan olarak RAM'in yarısını tüketecektir.
7. Özel ağ ve NAT için ikinci bir vmbr1 köprüsü oluşturun. Tüm VM/LXC'ler oraya. Sanal makinelerde genel IP yok.
8. Hizmetleri taşımaya başlamadan önce NetBird'ü (veya Tailscale, veya Headscale) kurun. Bu sizin geçiş kanalınız ve yönetici erişiminizdir.
9. Proxmox UI'yi dışarıya açmayın. Yalnızca VPN ağı üzerinden.
10. TLS sonlandırması ve engelleri aşmak için başka bir sağlayıcıda küçük bir çıkış VPS'si — zorunlu değil, ancak çok kullanışlıdır. Maliyeti çok düşük, faydaları çok.
11. Ayrı bir LXC'de PBS + site dışı S3'e senkronizasyon. Yedeklemeler otomatik olmalıdır.
12. Ayda en az bir kez test geri yüklemesi yapın. Aksi takdirde yedekleriniz değil, kendinizi rahatlatmak için dosyalarınız olur.
13. Hizmetleri tek tek taşıyın, kritiklik sırasına göre. "Tümünü hafta sonu taşımaya" çalışmayın.
14. DNS'teki TTL'yi geçişten bir gün önce düşürün, bir saat önce değil.
15. Her hizmet için belge tutun: yapılandırmalar nerede, nasıl başlatılır, nasıl yedeklenir, nasıl geri yüklenir. Altı ay sonra kendinize teşekkür edeceksiniz.

Yapılacaklar Listesi

Tamlık adına: geçişim hala %100 tamamlanmadı. Kalanlar:

• Eski sunucudan birkaç Remnawave paneli (gelecek hafta sonu planlandı).
• Caddy ve eklentilerini taşımak (özel derleme var), şimdilik geçici olarak çalışıyor.
• Eski CrowdSec — sıfırdan ayrı kuruyorum, taşımıyorum.

Ancak tüm kritik öğeler (forumlar, faturalandırma, botlar, veritabanları) — zaten adanmış sunucuda, kararlı çalışıyor, yedekleniyor ve izleniyor.

Open

Belirli adımlar, yapılandırmalar veya bastığım tıklamalar hakkında sorularınız varsa — yorumlarda yazın, genişletmeye çalışacağım. Özellikle diğer hipervizörlerde (XCP-ng, ESXi veya tamamen saf Docker Swarm) benzer sorunları nasıl çözdüğünüzü duymak isterim — belki bir şeyleri kaçırıyorumdur.

Altyapılarınızı birleştirirken bol şans. Daha az fatura, daha fazla kontrol — buna değer.