Gerçekten Geri Yüklenebilen VPS Yedekleri

Bir yedekleme stratejisi hiçbir zaman sunucunun öldüğü gece test edilmez. Haftalar önce, kimsenin yazıya dökmediği üç sessiz kararla test edilir: kopya nereye gidecek, onu silmeye kimin yetkisi olacak ve birinin o kopyayı gerçekten geri okuyup okumadığı.

Kimliğinizi hiç sormayan bir barındırma hizmeti, karşılığında bir şeyden vazgeçer; bunu açıkça söylemenin yeri burası. Aranacak bir hesap yöneticisi, silinmiş bir diski geri getirecek bir destek talebi yoktur ve kendi saklama politikamız nedeni açıkça ortaya koyar: sunucu verileri sonlandırmadan sonraki 24 saat içinde yok edilir, diskler biçimlendirilmek yerine kriptografik olarak silinir ve hiçbir yedek saklanmaz. Bu, platformu satın almaya değer kılan aynı özelliğin madalyonun öbür yüzüdür. Kötü bir geceden sonra geri istediğiniz her şeyin çoktan başka bir yerde olması gerekir ve onu oraya koyan kişi sizsiniz.

Sunucuları gerçekte ne yok eder

Neredeyse hiç kimse sunucusunu hayal ettiği şekilde kaybetmez. Felaket düzeyinde bir donanım arızası gerçektir ama nadirdir ve yetkin bir sağlayıcının zaten önlem aldığı tek durum budur. Gerçekte yaşanan kayıplar daha sıradandır ve her biri farklı türde bir kopyayı etkisiz kılar — bu yüzden "bir yedeğim var" demek, bunlardan hangisine dayandığını söylemeden bir cevap sayılmaz.

Bu tabloyu bir korku listesi değil, bir kontrol listesi olarak okuyun. Aynı makinedeki ikinci bir diske alınan gecelik bir kopya, yalnızca birinci satırı karşılar, başka hiçbirini karşılamaz. Aynı panelde alınan bir snapshot, birinci ve ikinci satırları karşılar. Yalnızca sunucunun erişemeyeceği bir yerde, hâlâ elinizde olan bir anahtarla saklanan bir kopya, beşinin tamamını karşılar.

Snapshot bir yedek değildir, barındırma sağlayıcınız da değildir

Snapshot'lar yaptıkları işte gerçekten iyidir: hiçbir aktarım gerektirmeden, saniyeler içinde başarısız bir güncellemeyi geri alırlar. Yapamadıkları şey, sunucuyu yok eden şeyden kendilerinin de kurtulmasıdır; çünkü aynı sağlayıcı, aynı hesap, aynı ödeme token'ı, aynı ülke, çoğu zaman aynı depolama kümesi dahil olmak üzere sunucuyla tüm arıza alanlarını paylaşırlar. Bir snapshot sizi kendinizden korur. Bir yedek ise geri kalan her şeyden korur.

Bu ayrım, sıradan bir sağlayıcıya kıyasla burada daha fazla önem taşır; çünkü alışılmış güvenlik ağları bilerek kaldırılmıştır. Kimse müşteri sunucularına giriş yapmaz, dolayısıyla yedekleme işinizin Mart'tan beri başarısız olduğunu fark eden de olmaz. Hesaba bağlı bir kimlik olmadığından "kim olduğunuzu kanıtlayın, biz de geri yükleyelim" diyecek bir insan yolu da yoktur. Ve sonlandırma gerçek anlamda nihaidir: süresi dolan bir bakiye, bir faturalama olayı değil, bir veri kaybı olayıdır.

Hiç kimlik göstermemiş kişiler için yeniden yazılmış 3-2-1 kuralı

Klasik kural şunu söyler: üç kopya, iki farklı ortam türünde, bunlardan biri site dışında. Bu kural, teyp ve döner diskin egemen olduğu bir dönem için yazılmıştı ve "ortam" maddesi sessizce anlamsızlaşmış durumda: üretim diskiniz de NVMe'dir, yedek hedefinizin diski de NVMe'dir; buna "iki farklı ortam" demek kendinize anlattığınız bir hikayeden ibarettir. Değerini koruyan madde mesafeyle ilgili olandır ve offshore altyapı için mesafe kilometreyle ölçülmez.

Kuralı şöyle yeniden yazın: üç kopya, iki sağlayıcı, iki yargı alanı. İki kopyayı aynı anda yok eden arızalar neredeyse hiçbir zaman fiziksel değildir — bunlar erişimini kaybettiğiniz bir hesap, kötü bir hafta geçiren bir sağlayıcı ya da bir ülkeye ulaşıp diğerine ulaşamayan bir hukuki işlemdir. Aynı raftaki iki sunucu, fazladan adımlarla tek bir kopyadır; aynı hukuki rejime tabi iki sunucu da bundan pek farklı değildir. Yargı alanı rehberimiz, ilkinin maruziyetini basitçe yansıtmayan bir ikinciyi nasıl seçeceğinizi anlatır.

Pratikte bu ucuzdur. Bir yedek hedefinin çekirdeğe ihtiyacı yoktur, ağa bile pek ihtiyacı yoktur — ihtiyacı olan disk ve bir adrestir. En küçük VPS paketi, yedi lokasyonumuzdan farklı birinde alındığında yeterli bir restic veya Borg uç noktasıdır; terabaytlarla ölçülen arşivler içinse gerçek disklere sahip bir dedicated sunucu, terabayt başına herhangi bir object storage'dan daha ucuza gelir. Verinin gerçekten büyük ve nadiren okunduğu durumlarda ekonomi, açık ara bare metal'den yana işler.

İnsanların üretim sunucusunda doğru yaptığı ama yedek hedefinde yanlış yaptığı bir şey var: onu da aynı şekilde ödeyin. Kendi adınıza bir kartla satın alınan ikinci bir sunucu, ilkinden kaldırmak için emek harcadığınız kimliği sessizce geri yapıştırır ve artık üzerindeki her şeyin eksiksiz bir kopyasını da barındırır. Üretim sunucusu Monero ile ödeniyorsa, yedek sunucu da aynı muameleyi hak eder.

Üçüncü kopya çoğu kişinin atladığı kopyadır ve tüm uzaktan arızalara karşı aynı anda bağışıklığı olan tek kopyadır: fiziksel olarak elinizde tuttuğunuz, ara sıra güncellediğiniz, çevrimdışı tutulan bir disk. Çoğu insan için ayda bir yeterlidir. Bir kahve içimlik dikkate mal olur ve diğer ikisinin paylaştığı senaryolardan sağ çıkan kopya budur.

Gönderme (push), çekme (pull) ve tek bir kötü gecenin iki kopyayı birden yutmasına izin veren hata

Neredeyse herkesin ilk kurduğu düzenlem budur. Üretim sunucusundaki bir iş her gece çalışır, yedek hedefi için bir anahtar veya token tutar, bağlanır ve gönderir. Çalışır, basittir ve yalnızca sunucunun hayatının en kötü gününde ortaya çıkan bir özelliği vardır: üretim sunucusunu kim kontrol ediyorsa yedekleri de o kontrol eder.

Bu bir varsayım değildir. Kendini duyurmadan önce kurbanın yedeklerini silmek veya şifrelemek, bunu ticari olarak yapan herkes için standart bir uygulamadır — kimlik bilgileri bir cron işinde ya da bir ortam dosyasında durur ve onları bulmak yaklaşık bir dakika sürer. Saldırganınızın silebildiği bir kopya, ikinci bir kopya değildir. İlkinin gecikmeli bir yansımasından ibarettir.

Bunun için iki temiz çözüm vardır ve bunlar, zaten yapmış olmanız gereken temel sıkılaştırma önlemleriyle iyi uyum sağlar.

• Append-only hedefler. İki büyük araç da bir istemcinin veri ekleyebildiği ama silemediği bir modu destekler. Borg bunu, hedefteki SSH anahtarını borg serve --append-only ile sınırlayarak yapar; restic ise --append-only ile başlatılan bir REST sunucusuyla yapar. Üretim sunucusu her gece yazar ve yapısal olarak geçmişi yok edemez. Eski snapshot'ların budanması ise üretim sunucusunun başlatamayacağı bir oturumda, hedef tarafında gerçekleşir.
• Push yerine pull. Yönü tersine çevirin: yedek sunucusu üretime bağlanır, okur ve saklar. Üretim tarafı hedef için hiçbir kimlik bilgisi tutmaz, dolayısıyla çalınacak bir şey yoktur. Üretim tarafında kullandığı anahtarı restrict ve zorunlu bir command= ile kısıtlayın, böylece çalınan bir yedek anahtarı bir shell'e dönüşemez.

Pull daha güçlü bir modeldir ve çalıştırması biraz daha fazla emek ister; append-only ise zaten Borg veya restic kullanıyorsanız neredeyse bedavadır. İkisinden biri, "saldırgan yedeklerimi sildi" cümlesini bir sonuçtan bir girişime indirger. Bu rehberden tek bir şey alacaksanız, bu bölümü alın.

Kaynakta şifreleyin, sonra anahtarı kimin tutacağına karar verin

İki ciddi araç da, herhangi bir şey ağ üzerinden geçmeden önce yedeklenen makinede şifreleme yapar. Hedef, yorumlayamadığı blob'ları saklar — sağlayıcılar arası kopyayı güvenli kılan tam olarak budur. İkinci sunucunuzun güvenilir, hatta dost canlısı olmasına gerek yoktur; yalnızca erişilebilir olması ve diski olması gerekir. Bu tek özellik, "hakkında hiçbir şey bilmediğim bir ülkedeki sunucu" ifadesini bir riskten bir altyapıya dönüştürür.

Bu, sunucunun kendi diskini şifrelemekten farklı bir mekanizmadır ve ikisi farklı soruları yanıtlar — VPS'te tam disk şifrelemesi rehberimiz, makine çalışırken disk şifrelemesinin neyi koruyup neyi korumadığını ayrıntısıyla ele alır. Yedek şifrelemesi ikisinin daha kolay ve daha değerli olanıdır; çünkü tehdit modeli dürüsttür: veri, kontrolünüzde olmayan bir donanımda beklemededir ve anahtar oraya hiç gitmez.

Bu da tüm riski anahtar saklama sorumluluğuna taşır. Parola artık tam kayıp için tek bir zayıf noktadır ve insanların sandığından daha kötü bir zayıf noktadır; çünkü onu kaybetmek sessizdir — hiçbir şey bozulmaz, yedekler çalışmaya devam eder ve tam da onlara ihtiyaç duyduğunuz anda gerçeği öğrenirsiniz. Bunu düzelten üç alışkanlık vardır:

• Parolayı sunucuda yalnızca root tarafından okunabilen bir dosya olarak tutun ve --password-file ile referans verin; böylece hiçbir zaman bir process listesinde ya da shell geçmişinde görünmez.
• İşin içindeki her makinenin dışında, insan tarafından okunabilir bir kopya tutun. Bir çekmecedeki kağıt, erişimini kaybedebileceğiniz bir hesapla senkronize olan bir parola yöneticisinden gerçekten daha üstündür.
• Depoya ikinci bir anahtar ekleyin — restic key add ya da dışa aktarılmış bir Borg anahtarı — böylece unutulan tek bir parola, arşivin sonu değil sadece bir sıkıntı olur.

Üçünün de altında yatan kural şudur: anahtarın tek kopyası, yedeğin yerini almak için var olduğu makinede yaşıyorsa, elinizde bir yedek yoktur. Elinizde şifrelenmiş bir blok yığını ve onlar hakkında bir hikaye vardır.

Tek bir tabloda araç seçimi

Araç seçimi, bağlantının yönü ve anahtarınızın durumu kadar önemli değildir; bu yüzden bu konu birinci değil altıncı sırada geliyor. Yine de aradaki farklar gerçektir ve iş için yanlış modeli seçmek ileride ekstra iş çıkarır.

Tek bir sunucu için, ikinci bir VPS'e restic ile yedekleme, doğru bir sonuca giden en kısa yoldur. Bir seedbox, bir medya arşivi ya da birbirine benzeyen çok sayıda büyük dosyanız varsa, Borg'un tekilleştirmesi dolu bir disk ile rahat bir disk arasındaki farktır — seedbox rehberimiz, bu iş yükünün depolama tarafını daha ayrıntılı ele alır.

Çalışmakta olan hiçbir şey bir dosya değildir

Dünyadaki en yaygın bozuk yedek, canlı bir veritabanının doğrudan dosya kopyasıdır. Hatasız tamamlanır, doğru boyuttadır ve geri yüklendiğinde motorun açmayı reddettiği bir tablo ortaya çıkar. Kopya alınırken veritabanı yazma işleminin ortasındaydı; kaydettiğiniz şey, çevrilmekte olan bir sayfanın fotoğrafıdır.

Artan efor sırasına göre üç çıkış yolu var. Dökümünü alın: mysqldump --single-transaction yazıcıları kilitlemeden tutarlı bir InnoDB dökümü verir, pg_dump de PostgreSQL için aynısını yapar. Snapshot alın: dosya sistemini dondurun ya da bir LVM veya ZFS snapshot'ı alın, snapshot'tan kopyalayın, sonra serbest bırakın — her gece dökümü alınamayacak kadar büyük veri kümelerini bu şekilde ele alırsınız. Ya da durdurun: küçük bir servis için, saat 04:00'te iki dakikalık bir kesinti, gayet saygın bir tutarlılık stratejisidir ve uç durumu olmayan tek yöntem budur.

Aynı mantık veritabanlarının ötesine de uzanır. Bir container'ın yazılabilir katmanı sarf malzemesidir ama volume'leri öyle değildir, yanlarındaki docker compose dosyası ve ortam değişkenleri de öyle değildir — verisini geri yükleyen ama tanımını geri yüklemeyen bir yedek, yığını hafızanızdan yeniden kurmanızı gerektirir. Mesaj kuyrukları, kalıcılığı açık Redis ve bir MTA tarafından yazılan bir mail kuyruğu da aynı muameleyi hak eder: durdurun, snapshot alın ya da dökümünü alın, ama asla düz kopyalayıp umut etmeyin.

Neyi yedeklemeli, ve herkesin unuttuğu parçalar

Çoğu kişi bariz olanı yedekler — veritabanı ve uygulama dizinini — geri kalanını ise baskı altında elle yeniden kurar. Saatlerin gittiği yer, bu yeniden kurma işidir. Sizi doğru bir veri yığınına değil, çalışan bir sisteme geri döndüren bir yedek, sıkıcı katmanı da içerir:

• /etc'nin tamamı, yazdığınız systemd unit'leri ve timer'ları, ve onun dışında yaşayan tüm crontab'lar.
• TLS sertifikaları ve özel anahtarları, ya da en azından ACME hesap anahtarı; böylece sertifikalar sıfırdan başlamak yerine yenilenir.
• Güvenlik duvarı kuralları ve paket listesi; ikisi birlikte, makinenin şeklini hafızanızdan daha hızlı yeniden kurar.
• Uygulama sırları ve ortam dosyaları — kod deponuzdan bilerek hariç tuttuklarınız, dolayısıyla başka hiçbir yerde bulunmayanlar.
• Metin olarak dışa aktarılmış DNS kayıtları, sunucuda değil sağlayıcıda yaşayan reverse-DNS ve PTR girdileri dahil.

Test etmediğiniz bir geri yükleme bir söylentiden ibarettir

Yedekleme yazılımı kendisi hakkında rapor verir ve bunu dürüstçe, ama yanlış şey hakkında yapar. "Snapshot tamamlandı" mesajı, verinin bir depoya yazıldığı anlamına gelir. Deponun, bu makine olmayan bir makinede, on bir ay önce ne yapılandırdığını hatırlamayan bir kişi tarafından okunabilir olup olmadığı hakkında hiçbir şey söylemez.

Ucuz bütünlük kontrolleriyle başlayın — belirli bir program üzerinde restic check --read-data-subset=5% ya da borg check --verify-data — ve bunların arşivi doğruladığını, sizin kullanma yeteneğinizi değil, anlayın. Gerçek tatbikat farklıdır ve tek seferlik bir öğleden sonra alır. Başka türlü kullanmadığınız bir lokasyonda, saatlik olarak taze bir sunucu kiralayın. Yalnızca depo adresi, parola ve kendi notlarınızla üzerine geri yükleme yapın. Servisi ayağa kaldırın. Her şeyin süresini tutun. Sonra makineyi yok edin. Toplam maliyet: birkaç dolar, ve güvenebileceğiniz bir sayı üreten tek egzersiz budur.

Güvenilir biçimde ortaya çıkardığı şey asla veri değildir. Kimsenin yazmadığı eksik paket, yedeklenen yolların dışında yaşayan yapılandırma, yalnızca değiştirmeye çalıştığınız sunucunun shell geçmişinde var olmuş parola ve depo formatınızı okuyan araç sürümüdür. Bunların her biri önceden düzeltmek için önemsizdir, bir kesinti sırasında keşfetmekse acı vericidir.

Tatbikatın size verdiği iki sayıyı not edin: bir geri yüklemenin ne kadar sürdüğü ve programınızın ne kadar iş kaybedebileceği. Yedekleme politikanız budur. Yukarıdaki her şey, bu ikisine hizmet eden bir uygulama ayrıntısıdır.

Sürekli gerçekleşmesi için otomatikleştirme

İşi cron yerine bir systemd timer'dan çalıştırın. Tek bir yerde loglar, son çalıştırmanın gerçek bir kaydı ve reboot'lara dayanan bir program elde edersiniz — cron bunların hiçbirini ekstra emek olmadan size vermez. Parolayı unit dosyasının dışında tutun; çünkü shell erişimi olan herkes onu doğrudan systemctl cat çıktısından okuyabilir.

Sonra, insanları gerçekten yakalayan hata durumunu çözün; bu bir hata değil, sessizliktir. Altı hafta önce çalışmayı bırakmış bir yedek, mükemmel çalışmış bir yedekle tıpatıp aynı görünür; çünkü ikisi de hiçbir çıktı üretmez. Hataya değil, yokluğa karşı uyarın. İş başarılı olduğunda bir monitöre ping atsın ve ping ulaşmadığında monitör şikayet etsin — ve bu monitörü izlediği sunucu dışında herhangi bir yere koyun, çünkü çökmüş bir makine çöktüğünü rapor edemez.

Saklama süresini varsayılana bırakmak yerine bilerek belirleyin. --keep-daily 7 --keep-weekly 4 --keep-monthly 6 gibi bir ayar, sonsuza dek büyümeden bu gece fark ettiğiniz hataları ve ilkbaharda fark edeceğiniz bozulmaları kapsar. Append-only'e geçtiyseniz budama işlemini hedef tarafında çalıştırın; zaten append-only'e geçmenin amacı budur. Ağımızda aktarım hacmi nadiren bir kısıtlama oluşturur — her pakette bant genişliği ölçümsüzdür — bu yüzden bir kotaya göre değil, tutarlılığa göre zamanlayın ve zamanlamayı kendi sessiz saatlerinizle karşılaştırın. Bunun etrafındaki daha geniş alışkanlıklar sunucu OpSec rehberimizde ele alınır.

Kısa versiyon

Bu sayfayla başka hiçbir şey yapmayacaksanız, şu altı şeyi kabaca bu sırayla yapın:

• Bir kopyayı ikinci bir sağlayıcıya, ikinci bir yargı alanına, ilkiyle aynı gizli yöntemle ödeyerek koyun.
• O kopyayı append-only yapın ya da hedeften pull ile çekin; böylece ele geçirilmiş bir sunucu onu yok edemesin.
• Aracın kaynakta şifreleme yapmasına izin verin ve anahtarı işin içindeki her iki makinenin de dışında tutun.
• Veritabanlarının dökümünü alın, çalışan her şeyi durdurun ya da snapshot'layın; canlı durumu asla düz kopyalamayın.
• Kimlik anahtarlarını ayrı yedekleyin — onion, WireGuard, DKIM, node seed'leri — çünkü bunlar yeniden üretilemez.
• Bir kerelik, atılabilir bir sunucuya geri yükleme yapın, süresini tutun ve neyin eksik olduğunu not edin.

Bunların hiçbiri egzotik değildir ve hiçbiri bir hafta sonu sürmez. Projeleri bitiren bir kayıp kategorisine karşı bir öğleden sonralık kurulum ve tek bir tatbikattir. Hakkınızda bilerek hiçbir şey tutmayan bir platformda, kendi yaptığınız kopya var olan tek kopyadır — bu, düzenlemenin bedelidir ve adil bir bedeldir. İlkinden farklı bir yargı alanında ikinci bir sunucu açın ve bu geceki yedeğe inecek bir yer verin.