VPS Snapshot, Yedek ve Klon Arasındaki Farklar

Snapshot, yedek ve klon kavramlarının gerçek anlamları

VPS snapshot'ı, sunucunuzun sağlayıcınız tarafından, sağlayıcının altyapısında ve hesabınızın içinde tutulan bir disk görüntüsüdür. Yedek, verilerinizin, orijinal veriyi tutan sağlayıcıdan bağımsız olarak başka bir yere geri yükleyebileceğiniz bağımsız bir kopyasıdır. Klon ise bir snapshot üzerinden dağıtılan yeni bir örnektir; dolayısıyla yaşamına, kimlik bilgileri dahil olmak üzere orijinalin tam bir kopyası olarak başlar.

Bu yöntemler farklı sorunları çözer. Bir snapshot, hatalı bir yükseltmeyi dakikalar içinde geri almanızı sağlar ancak hesabınızın kapatılması durumunda hiçbir işe yaramaz. Bir yedek, sağlayıcınızın hizmet vermeyi bırakması durumunda verilerinizi korur; ancak önce makineyi yeniden oluşturmanız gerektiği için geri yükleme süreci daha uzun sürer. Bir klon, tek adımda ikinci bir çalışan sunucu elde etmenizi sağlar; ancak bu durum, aynı makine olduklarını düşünen iki makineye sahip olmanıza yol açar.

VPS snapshot'ı neden yedek değildir

Sorun imajın kalitesi değil, hata etki alanıdır. Snapshot, sunucunuzun bulunduğu sağlayıcının depolama platformunda, genellikle sunucuyla aynı bölgede ve her zaman aynı hesap içerisinde tutulur. Tek bir olay, hem sunucuyu hem de snapshot'ı aynı anda yok edebilir.

• Hesap askıya alınır, ödeme başarısız olur veya giriş bilgileri çalınır.
• API erişimi olan bir kişi veya betik, sunucu örneğini siler. Birçok sağlayıcıda bir örneği silmek, onunla ilişkili snapshot'ları da siler. Aksi bir durum varsaymadan önce sağlayıcınızın belgelendirilmiş davranışlarını okuyun.
• Bölgesel bir kesinti yaşanır ve o bölgedeki her şey aynı anda erişilemez hale gelir.
• Sunucuda root yetkisiyle çalışan bir süreç, /root içerisinde bıraktığınız sağlayıcı API anahtarını bulur ve diske dokunmadan önce snapshot'ları siler.

Yedek, bu dört durumun tamamından sağ kurtulan kopyadır. Test tek bir soruya dayanır: Sağlayıcı hesabınız bu öğleden sonra var olmasaydı, neyi geri yükleyebilirdiniz ve bunu nereye geri yüklerdiniz? Bu soruyu geçemeyen her şey bir geri alma aracıdır. Snapshot almaya devam edin, çünkü hiçbir şey daha hızlı geri yüklenemez. Ardından, sağlayıcınızın kontrol etmediği bir depolama alanında ikinci bir kopya tutun.

Eski kural geçerliliğini koruyor: verinin üç kopyası, iki farklı depolama türünde ve bunlardan biri platformun dışında. Bir sağlayıcı snapshot'ı ile ayrı bir altyapıdaki restic yedekleme deposu, bu gereksinimi iki bileşenle karşılar.

Çalışan bir veritabanının snapshot'ı neden bozuk geri yüklenebilir

Bir sağlayıcı snapshot'ı, blok cihazını tam o andaki haliyle kopyalar. Uygulamalarınızın önce durmasını istemez ve sayfa önbelleğinde (page cache) bekleyen hiçbir şeyi göremez. Bu nedenle görüntü en iyi ihtimalle "crash-consistent" (çökme tutarlı) durumdadır. Birisi güç kablosunu çekmiş gibi diskin nasıl görünecekse tam olarak öyle görünür.

Yığının çoğu bunu yönetebilir. ext4 ve XFS, mount sırasında günlüklerini (journal) yeniden oynatır, böylece dosya sistemi ayağa kalkar. PostgreSQL, başlangıçta yazma öncesi günlüğünü (write-ahead log) yeniden oynatır ve günlük bunu şu şekilde belirtir:

LOG:  database system was not properly shut down; automatic recovery in progress

InnoDB de aynı işlemi yapar ve başlangıç sırasında kendi çökme kurtarma satırlarını yazdırır. Bu kurtarma, veritabanının tasarlandığı gibi çalışmasıdır; bu nedenle sessiz bir PostgreSQL veya MySQL'in tek bir birimden alınan snapshot'ı genellikle sorunsuz geri yüklenir.

Çökme tutarlılığının yeterli olmadığı durumlar gerçektir ve can yakanlar bunlardır. Verileriniz iki birime yayılmışsa, kök disk ve ayrı bir veri diski farklı anlarda snapshot'lanır; bu durumda veri dosyaları ve günlük dizini birbiriyle uyumsuz olabilir ve kurtarma işleminin yeniden oynatabileceği doğru bir veri kalmaz. Bir uygulamanın fsync çağırmadan yazdığı herhangi bir dosya (yarıda kesilmiş bir yükleme veya kuyruk dosyası gibi) kesilmiş olarak geri gelebilir. Uygulamanın bellekte tuttuğu ve zamanlayıcı ile diske yazdığı her şey görüntüde basitçe yer almaz.

Bu nedenle snapshot almadan önce diske bir döküm (dump) yazın. O zaman görüntü, canlı veri dosyalarının durumu ne olursa olsun, dahili olarak tutarlı olduğunu bildiğiniz tek bir dosya içerir.

sudo -u postgres pg_dumpall --clean --file=/var/backups/pg-$(date +%F).sql
sudo mysqldump --single-transaction --routines --all-databases > /var/backups/mysql-$(date +%F).sql

--single-transaction, yazma işlemlerini engellemeden InnoDB tablolarının tutarlı bir dökümünü sağlar; çünkü döküm, tekrarlanabilir okuma (repeatable-read) işlemi içinde çalışır. Bu, kilit veya durdurulmuş bir sunucu gerektiren MyISAM tablolarını kapsamaz. Güvenmeden önce dökümün boş olmadığını ve kesilmediğini kontrol edin: Tamamlanmış bir mysqldump üzerindeki tail -n 1 /var/backups/mysql-$(date +%F).sql, Dump completed yorumuyla biter.

Ayrı bir veri biriminiz varsa, snapshot'ın ihtiyaç duyduğu saniyeler boyunca onu dondurabilirsiniz:

sudo fsfreeze -f /srv
# take the snapshot from your provider's panel or API
sudo fsfreeze -u /srv

Yalnızca veri birimini dondurun. Asla /'i dondurmayın. Dondurulmuş bir kök dosya sistemi, dondurmayı kaldırma komutunu yazmak için kullanacağınız kabuk dahil olmak üzere sunucudaki her yazma işlemini engeller; böylece kendinizi sistemin dışında bırakır ve zorunlu bir yeniden başlatma (hard reset) beklemek zorunda kalırsınız.

Sunucu dışı yedekleme: restic veya Borg

Snapshot işlemi hızlı olan kısımdır. Sunucu dışı kopya ise sağlayıcınızın başına bir şey gelmesi durumunda verilerinizi koruyan kısımdır. restic; verileri tekilleştirdiği, istemci tarafında şifrelediği ve S3 uyumlu nesne depolama, SFTP veya doğrudan bir dizine yazabildiği için iyi bir varsayılan tercihtir. Sunucu dışı hedef olarak depolama odaklı bir VPS, yedekleme depoları yüksek IOPS değerinden ziyade kapasiteye ihtiyaç duyduğu için burada oldukça verimli çalışır.

sudo apt update && sudo apt install -y restic
sudo sh -c 'umask 077; head -c 24 /dev/urandom | base64 > /root/.restic-pass'
sudo chmod 600 /root/.restic-pass
sudo cat /root/.restic-pass

Bu parola ifadesini şimdi, üzerinde çalıştığınız sunucu dışındaki bir cihazda bulunan bir parola yöneticisine kopyalayın. Bir restic deposu bu parola olmadan açılamaz ve herhangi bir kurtarma yolu bulunmamaktadır. Parolanın tek kopyası az önce kaybettiğiniz sunucudaysa, yedekleriniz şifrelenmiş anlamsız verilerden ibaret kalacaktır.

export RESTIC_REPOSITORY="s3:https://s3.example.com/vps-backups"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
sudo -E restic init
sudo -E restic backup /etc /srv /var/backups
sudo -E restic snapshots

sudo -E bu değişkenleri korur; aksi takdirde root kullanıcısı temiz bir ortamla çalışır ve restic herhangi bir depo konumu belirtilmediği hatasını verir. restic snapshots, az önce gerçekleştirdiğiniz yedekleme işlemini, ana bilgisayar ve yollarla birlikte listelemelidir. Deponun kendisini düzenli bir program dahilinde doğrulayın ve yalnızca yapısını kontrol etmekle kalmayıp verilerin bir kısmını geri okuyarak test edin:

sudo -E restic check --read-data-subset=5%
sudo -E restic restore latest --target /tmp/restore-check
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Test edilmemiş bir yedekleme, sadece bir tahmindir. En az bir kez farklı bir VPS üzerine geri yükleme yapın, süreyi tutun ve bu süreyi not edin; çünkü bu rakam sizin gerçek kurtarma hedefinizdir. Borg diğer sağlam seçenektir ve deposunu nesne depolama yerine SSH üzerinden saklar; aralarındaki farklar restic ve BorgBackup karşılaştırması bölümünde ele alınmıştır.

Klonlanmış bir VPS canlı ortama alınmadan önce yapılması gerekenler

Klon, orijinalin birebir kopyasıdır. Bu durum hem en büyük avantajı hem de temel sorundur. Orijinali benzersiz kılan her şey kopyalanır ve bu kopyalar çakışır.

SSH host anahtarlarını yeniden oluşturun. Klon, orijinalin /etc/ssh/ssh_host_* dosyalarını taşır; dolayısıyla iki sunucu aynı kimliği sunar. Birine erişimi olan herkes, o anahtarı kabul etmiş tüm istemcilere karşı diğer sunucuyu taklit edebilir. Anahtar istemcinin beklediğiyle aynı olduğu için SSH herhangi bir uyarı vermez.

sudo rm -f /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart ssh
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

ssh-keygen -A, daemon'ın beklediği her türden yeni bir anahtar oluşturur. Son komuttan alınan parmak izi, orijinal sunucudakinden farklı olmalıdır. Mevcut oturumunuz yeniden başlatma sonrasında devam eder, çünkü sshd'yi yeniden başlatmak kurulu bağlantıları koparmaz. Bunu, klona kimse bağlanmadan önce yapın. Eğer sonraya bırakırsanız, devralınan anahtara güvenen her istemci WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! hatası alır ve önce ssh-keygen -R <host> komutunu çalıştırması gerekir.

Makine kimliğini (machine ID) sıfırlayın. /etc/machine-id, systemd tarafından ilk açılışta bir kez oluşturulan benzersiz bir tanımlayıcıdır ve klon bunu devralır.

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id
sudo reboot

Boş bir /etc/machine-id dosyası, systemd'ye bir sonraki açılışta yeni bir değer oluşturmasını söyler; bu yüzden dosyayı silmek yerine içeriğini boşaltıyoruz (truncate). Klonlandığında iki şey bozulur. Adresini DHCP ile alan imajlarda, systemd-networkd varsayılan olarak DHCP istemci tanımlayıcısını makine kimliğinden türetir. Bu durumda her iki klon da aynı istemci olarak IP adresi talep eder ve sunucu onlara aynı adresi verir. Ayrıca journald, her girdiyi makine kimliği ile damgalar; bu da merkezi bir log toplayıcının her iki sunucuyu tek bir makine olarak kaydetmesine neden olur. Yeniden başlatmanın ardından cat /etc/machine-id komutunu çalıştırın ve değerin değiştiğini doğrulayın.

Hostname'i değiştirin.

sudo hostnamectl set-hostname web-02
grep 127.0.1.1 /etc/hosts

hostnamectl, /etc/hostname dosyasını yazar ve ismi anında uygular. /etc/hosts dosyasına dokunmaz, bu yüzden 127.0.1.1 satırını yeni isimle eşleşecek şekilde düzenleyin. Bunu atlarsanız yeni isim hiçbir yere çözümlenmez ve her sudo çağrısı başarısız bir sorgu için bekleyip sudo: unable to resolve host web-02: Name or service not known hatasını yazdırır.

İmajın içine gömülü tüm kimlik bilgilerini yenileyin. Klon, orijinalin sırlarını tutar ve artık iki makine de orijinal gibi davranabilir. SSH authorized_keys dosyalarını, sağlayıcı ve DNS API token'larını, uygulama .env dosyalarını, veritabanı şifrelerini, TLS özel anahtarlarını, izleme (monitoring) kayıt token'larını ve restic depo şifresini gözden geçirin. Aşağıdaki komut bunların çoğunu bulmanıza yardımcı olur:

sudo grep -rIlE 'PASSWORD|SECRET|TOKEN|API_KEY' /etc /srv /opt /home 2>/dev/null
sudo find / -name '.env' -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

Eğer klon, trafik almayacak bir test kopyasıysa, yenilemek yerine yetkilerini iptal edin. Canlı bir üretim API token'ı barındıran bir staging sunucusu, yamaları eksik bir üretim sunucusudur.

Artık iki kez çalışan işleri kapatın. Aynı crontab'ı çalıştıran iki sunucu, aynı dakikada aynı dış sistemlere istek gönderir.

systemctl list-timers --all
sudo crontab -l
sudo ls -l /etc/cron.d /etc/cron.daily

restic örneğini özellikle belirtmek gerekir, çünkü sadece hata vermekle kalmaz, saklama politikanızı da bozar. restic her snapshot'ı host ismiyle etiketler ve restic forget --keep-daily 7 politikayı host bazında uygular. Aynı host ismini bildiren iki makine tek bir host olarak kabul edilir; bu da yedi "günlük" snapshot'ın tamamının klondan gelmesine ve orijinalin snapshot'larının silinmesine neden olabilir. İlk yedekleme çalışmadan önce hostname'i düzeltin veya klon üzerindeki zamanlayıcıyı durdurun. certbot durumu daha basittir: aynı isimleri yenilemeye çalışan iki sunucu, sertifika otoritesinin "aynı isim seti için çok fazla sertifika düzenlendi" şeklindeki hız sınırına takılır. Alan adı hala orijinal sunucuya işaret eden bir klon, HTTP doğrulamasını zaten geçemez; bu yüzden orada yenilemeyi devre dışı bırakın.

İzleme (monitoring) ajanını yönetin. Çoğu ajan kendini hostname veya kurulum sırasında yazılan bir ID dosyası ile tanımlar. Bu yüzden tek bir host gibi rapor veren iki ajan, metriklerini tek bir seride birleştirir. CPU grafikleri hiçbir makinenin tek başına üretmediği değerleri gösterir ve uyarılar (alerts) kararsızlaşır. Klondaki ajanı durdurup kaldırın veya tedarikçinizin belgelendirdiği prosedürü kullanarak yeni hostname ile yeniden kaydedin.

Ağ yapılandırmasını orijinalin adresi için kontrol edin. Eğer imaj netplan içinde statik bir adres taşıyorsa, klon başka bir makineye ait olan bir IP'yi sahiplenir.

ip -br addr
sudo grep -r addresses /etc/netplan/

Bu klon bir şablon haline gelecekse cloud-init durumunu temizleyin.

sudo cloud-init clean --logs

Bu komut, /var/lib/cloud altındaki cloud-init durumunu kaldırır. Böylece bir sonraki açılışta ilk açılış modülleri tekrar çalışır; buna, mevcut değilse SSH host anahtarlarının oluşturulması da dahildir. Bazı sürümler makine kimliğini sıfırlamak için bir flag de sunar. Başka bir kaynaktaki flag listesine güvenmek yerine, kendi imajınızda nelerin desteklendiğini görmek için cloud-init clean --help komutunu çalıştırın.

Hangisinin ne zaman kullanılacağı

Riskli bir yükseltmeyi geri alma: snapshot alın. Değişiklikten dakikalar önce snapshot alın, yükseltmeyi çalıştırın ve işler ters giderse imajı geri yükleyin. Geri yükleme işlemi, snapshot alındıktan sonra yapılan tüm yazma işlemlerini siler; bu nedenle canlı trafik alan bir sunucuda önce veritabanı yedeğini alın ve hangi zaman aralığındaki verileri kaybedeceğinizi tam olarak bilin. On dakika boyunca çevrimdışı tutabileceğiniz bir sunucudaki do-release-upgrade için snapshot tek başına yeterli bir plandır.

Daha büyük bir plana geçiş: clone dağıtın. Snapshot üzerinden daha büyük bir plan üzerinde clone oluşturun, yukarıdaki kimlik listesini uygulayın ve herhangi bir trafik yönlendirmeden önce kendi IP adresi üzerinde test edin. Geçişin hızlı olması için DNS TTL değerini bir gün önceden düşürün ve yeni sunucu gerçek trafiği başarıyla karşılayana kadar orijinal sunucuyu çalışır durumda tutun. Daha fazla vCPU ve daha yoğun donanım her zaman bir yükseltme anlamına gelmediğinden, her iki sunucuda aynı kıyaslama yöntemini kullanarak daha büyük planın iş yükünüz için gerçekten daha hızlı olduğunu önceden doğrulayın.

Şablon oluşturma: temizlenmiş bir makinenin snapshot'ını alın. Bir sunucuyu kurun ve güvenlik sıkılaştırmasını yapın, ardından imajını almadan önce benzersiz olan her şeyi kaldırın. Host anahtarları, makine kimliği, kişisel authorized_keys verileri, kimlik bilgileri ve cloud-init yapılandırmaları temizlenmiş olmalıdır. Bunun snapshot'ını alın. Bu şablondan dağıtılan her örnek, ilk açılışta kendi kimliğini oluşturur; böylece yukarıdaki kontrol listesiyle uğraşmanıza gerek kalmaz. Bunu yeni bir VPS üzerindeki standart ilk on dakika ile birleştirin; böylece şablon, aksi takdirde tekrarlayacağınız tüm işlemleri halihazırda içermiş olur.

FAQ

VPS snapshot'ı bir yedekleme midir?

Hayır, çünkü snapshot, geldiği sunucu ile aynı hata alanını (failure domain) paylaşır. Snapshot, sağlayıcınızın depolama alanında, hesabınızın içinde ve genellikle aynı bölgede tutulur. Bir hesap askıya alma işlemi, çalınan bir API key veya yanlışlıkla yapılan bir instance silme işlemi, sunucuyu ve snapshot'larını tek bir hamlede yok edebilir; birçok sağlayıcıda bir instance silindiğinde snapshot'ları da tasarım gereği silinir. Snapshot, sahip olduğunuz en hızlı geri alma yöntemidir; bu yüzden almaya devam edin, ancak sağlayıcınızın kontrolünde olmayan bir altyapıda ikinci ve şifreli bir kopyasını mutlaka tutun.

Snapshot almadan önce veritabanını durdurmam gerekir mi?

Her zaman değil, ancak elde edeceğiniz sonucun durumunu kabul etmeniz gerekir. Sağlayıcı tarafından alınan bir snapshot "crash-consistent" yani çökme tutarlılığındadır; bu, görüntünün bir elektrik kesintisi sonrasındaki disk durumuyla aynı olduğu anlamına gelir. PostgreSQL ve InnoDB, başlatma sırasında bu durumdan kurtulabilir ve PostgreSQL bu sırada database system was not properly shut down; automatic recovery in progress loglarını tutar. Verileriniz farklı zamanlarda snapshot'ı alınan iki ayrı birim (volume) üzerine yayıldığında veya bir uygulama fsync kullanmadan yazma işlemi yaptığında kurtarma garantisi yoktur. Önce diske bir pg_dumpall veya mysqldump --single-transaction yazın; böylece görüntü, tutarlı olduğunu bildiğiniz tek bir dosya içerir.

Neden iki klon sunucu aynı IP adresi için çakışıyor?

Çünkü /etc/machine-id değerini paylaşıyorlar. DHCP kullanan imajlarda systemd-networkd, DHCP istemci tanımlayıcısını varsayılan olarak machine ID üzerinden oluşturur. Bu nedenle her iki klon da aynı istemci olarak IP adresi talep eder ve DHCP sunucusu her ikisine de aynı adresi atar. /etc/machine-id dosyasını sıfır bayt olacak şekilde boşaltın, /var/lib/dbus/machine-id dosyasını silin, /etc/machine-id dosyasına sembolik bağ (symlink) oluşturun ve systemd'nin yeni bir değer üretmesi için sunucuyu yeniden başlatın. Diğer yaygın neden ise /etc/netplan/ içine yazılmış ve klon tarafından aynen kopyalanmış statik bir adrestir; bunu ip -br addr ile kontrol edin.

Bir klonun üretime alınmasının güvenli olduğunu kontrol etmenin en hızlı yolu nedir?

Dört öğeyi orijinaliyle karşılaştırın. Her ikisinde de ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub çalıştırın ve parmak izlerinin farklı olduğunu doğrulayın. Her ikisinde de cat /etc/machine-id çalıştırın ve değerlerin farklı olduğunu doğrulayın. hostnamectl status çalıştırın ve ismin yeni olduğunu ve çözümlendiğini doğrulayın; böylece sudo uyarı vermez. Ardından systemctl list-timers --all çalıştırın ve yedekleme, sertifika yenileme veya izleme ajanı gibi paylaşılan bir sistemle iletişim kuran tüm zamanlayıcıları, hangi makinenin bu işten sorumlu olduğuna karar verene kadar durdurun.