Snapshot nedir ve neden yedekten farklıdır?

Sunucu diskini değiştirdiniz, sistem açılıyor, her şey yerli yerinde, ama orders tablosu boş. Son snapshot da üç gün öncesine ait. İşte burada, düne kadar "yedek" dediğiniz şeyin aslında snapshot olduğunu ve snapshot'ın hiçbir zaman yedeğin yerini almak için tasarlanmadığını anlıyorsunuz.

Snapshot, disk bloklarının belirli bir andaki durumunun anlık görüntüsüdür. LVM, ZFS, Ceph ve bugün neredeyse tüm bulut platformlarında bu işlem copy-on-write ile yapılır: veriyi kopyalamak yerine yalnızca metadata kaydedilir ve eski bloklar dokunulmadığı sürece yerlerinde kalır. Bu yüzden oluşturulması birkaç saniye sürer, 500 GB'lık bir disk için bile. İşte bu hız yanıltıcıdır.

Snapshot aynı depolama üzerinde oturur

Bir volume'ün snapshot'ı, volume'ün kendisinin bulunduğu pool üzerinde alınırsa, her ikisi de aynı donanıma bağımlı olan iki veri kopyanız olur. RAID denetleyicisi yanar, pool corruption'a uğrar ya da biri yanlışlıkla zpool destroy çalıştırır ve ikisi birlikte gider. Snapshot insan hatasına ve mantıksal bozulmaya karşı iyidir, fiziksel arızaya karşı işe yaramaz.

Bunu pratikte çok gördüm: her gece snapshot alan, panosu yeşil olan bir ekip, fiziksel disk öldüğü gün o snapshot'ların hiçbirinin kurtarılamadığını anlar. Snapshot bir rollback aracıdır, felaketten kurtarma stratejisi değil.

İşte burada hata yapıyorlar

En yaygın hata, snapshot'ın koruması gereken sunucunun kendisinde alınması ve sonra birinin o sunucuyu yeniden kurmasıdır. İşareti de açıktır: yeniden kurulumdan sonra snapshot listesi boştur ve destek "snapshot'lar volume ile birlikte silindi" der. Snapshot volume'e bağlıdır; volume giderse snapshot da gider. Snapshot'ı ayrı bir storage üzerinde tutmuyorsanız, aslında yedeğiniz yoktur.

Gerçek yedekte ne olmalı

Yedek, ayrı bir ortamda, başka bir ortamda kurtarılabilme yeteneğine sahip, bağımsız bir kopya anlamına gelir. Snapshot'ta olmayan üç özellik:

• Mekânsal bağımsızlık: Kopya başka bir storage veya veri merkezinde olmalıdır. Aynı rack'teyse, aynı yangın ikisini de götürür.
• Mantıksal bağımsızlık: Tüm diski değil, tek bir tabloyu veya tek bir dosyayı ayrı ayrı kurtarabilmelisiniz.
• Test edilebilirlik: Şimdiye kadar restore edilmemiş bir yedek, yedek değildir; bir varsayımdır.

Aracın da önemi yok. Sıkıştırılmış ve tablo seçilebilir çıktı veren -Fc bayraklı pg_dump ya da InnoDB için tabloları kilitlemeden mysqldump --single-transaction, ikisi de işe yarar. Önemli olan çıktıyı ana sunucuyla fiziksel ilişkisi olmayan bir yere göndermektir; nesne depolama alanı tam da bunun için yapılmıştır ve sürümleme de sunar.

Doğru birleşim: hız için snapshot, hayatta kalmak için yedek

Bu ikisi rakip değildir. Snapshot'ı kısa pencereler için tutun: bir migration öncesinde, veritabanı sürüm güncellemesi öncesinde, schema değişikliği öncesinde. Upgrade bozulursa, birkaç saniye içinde geri dönersiniz. Bu, yedeğin veremeyeceği bir şeydir, çünkü 200 GB'lık bir veritabanını object storage'dan restore etmek genellikle dakikalar değil saatler sürer.

Yedeği uzun ufuk için tutun: günlük, haftalık, aylık, sunucu dışında saklamayla. Kendi kullandığım pratik bir model: 48 saatlik saklamayla her altı saatte bir snapshot, 30 günlük saklamayla günlük mantıksal dump ve ayrı bir storage'a giden ve bir yıl kalan aylık bir kopya.

Kabul etmeniz gereken maliyet de budur: gerçek yedek alan ve bant genişliği tüketir ve restore süresi vardır. Veri hacminiz birkaç terabaytsa, 30 günlük kopya tutmak, storage maliyetinin sunucunun kendisinin birkaç katı olması anlamına gelir. İşte burada sezgisel karar vermek yerine RPO ve RTO'yu sayıya dökmeniz gerekir.

Uygulamayla uyumlu snapshot

Crash-consistent bir snapshot ile application-consistent bir snapshot farklıdır. Veritabanı yazma işleminin ortasında snapshot alırsanız, crash durumunda olan ve kurtarma için crash recovery gerektiren bir kopyanız olabilir. MySQL için snapshot'tan önce FLUSH TABLES WITH READ LOCK çalıştırın, snapshot'ı alın, sonra UNLOCK TABLES. PostgreSQL için pg_start_backup() durumunda olmanız ya da pg_basebackup kullanmanız yeterlidir. Bu ayrıntılar, "kurtarıldı" ile "kurtarıldı ama iki saatlik veri kayboldu" arasındaki farkı yaratan şeydir.

Snapshot'ın doğru cevap olduğu yer

Yalnızca bir staging ortamınız varsa ve bir değişikliği test etmeden önce bir geri dönüş noktası istiyorsanız, snapshot doğru seçimdir ve tam yedek oluşturmak zaman kaybıdır. Ayrıca yalnızca config ve binary içeren sistem diskleri için snapshot yeterlidir; gerçek veri başka bir yerdedir.

Ama aynı sunucuda müşteri veritabanınız varsa, snapshot üç katmanın yalnızca biridir. İkinci katman ayrı storage üzerindeki mantıksal dump, üçüncü katman o veri merkezinin dışındaki bir kopyadır. Bulut altyapısında bu, ayrı bir volume ya da başka bir bölgedeki bir bucket ile yapılır ve karmaşık bir mimari kurmanıza gerek yoktur. Hâlâ yerel diskli özel sunucuda çalışıyorsanız, bulut altyapısı (IaaS) bu storage ile compute ayrımını kolaylaştırır.

Yedek testi değil, kurtarma testi

"Yedek başarılı" diyen bir panonun hiçbir değeri yoktur. Değerli olan, ayda bir bir kopyayı geçici bir sunucuda restore edip uygulamanın açıldığını görmenizdir. Ben bunu basit bir script ile yapıyorum: son dump'ı alır, geçici bir instance üzerinde restore eder, bir sayım sorgusu çalıştırır ve sonucu ekip sohbetine gönderir. O mesaj gelmezse, yedeğiniz yok demektir.

Altyapınızın hangi bölümünün gerçekten kapsandığını anlamak için, akıllı izleme ve uyarı kurulumu pratik rehberi iyi bir başlangıç noktasıdır; disk izleme için kullandığınız aynı araç, yedekleme job'ının başarısızlığını da bildirebilir. Ve sunucu sayısı arttıysa, kod olarak altyapı, yedek ve snapshot tanımının da diğer kaynaklar gibi sürümlenmesine yardımcı olur, birinin kafasında kalması yerine.

Sık sorulan sorular

Snapshot yedeğin yerini alır mı?

Hayır. Snapshot, ana verinin bulunduğu aynı storage üzerinde oturur, dolayısıyla disk arızası ya da volume silinmesi ikisini birlikte yok eder. Snapshot birkaç dakika içinde hızlı geri dönüş için tasarlanmıştır, felaket sonrası kurtarma için değil.

Snapshot ile yedek arasındaki fark nedir?

Snapshot, saniyeler içinde oluşturulan ve volume'e bağımlı kalan copy-on-write anlık görüntüsüdür. Yedek ise ayrı bir ortamdaki bağımsız bir kopyadır ve tek dosya ya da tek tablo kurtarabilir, ancak oluşturulması ve geri yüklenmesi zaman ve alan alır.

Ne sıklıkla snapshot almalıyım?

Alışkanlığa değil, RPO'ya bağlıdır. Altı saatlik veri kaybını tolere edebiliyorsanız, her altı saat yeterlidir. Yüksek işlemli veritabanları için, kesin kurtarma noktasına sahip olmak adına saatlik snapshot ile birlikte WAL archiving ya da mantıksal binlog daha mantıklıdır.

Yedeğimin gerçekten çalıştığını nasıl anlarım?

Yalnızca restore ederek. Bir kopyayı geçici bir sunucuya geri yükleyin, uygulamayı açın ve gerçek bir sorgu çalıştırın. Bunu yapmadıysanız, elinizde olan bir yedek değil, bir varsayımdır.

Bugün bir snapshot alın ve sonra sorun: bu disk bir saat içinde kaybolsa, verinizin son bağımsız kopyası nerede ve kaç saat eski? O sorunun cevabı, kötü bir iş günü ile bir felaket arasındaki farktır.