Kendi Yedekleme Sisteminizi Kurmak – Bölüm 1: Betiklerden Önce Strateji

• Yedekleme konusunun önemi çoğu zaman olduğundan az görülür
• Pek çok kişi buluta bağımlı olmaya alışmış durumda ve veriyi koruma sorumluluğunun farkında değil
• Yedekleme planı oluşturmadan yalnızca kopyalamaya güvenmek yüksek risk doğurur
• Tüm diski ya da tek tek dosyaları yedekleme yöntemlerinin her birinin avantajları ve dezavantajları vardır
• Güvenilir bir yedeklemenin temel unsurları snapshot kullanımı ve harici depolama sağlamaktır

---

Yedeklemenin önemi ve gerçekler

• Yedekleme, birçok kişinin yeterince ciddiye almadığı bir alandır
• Yanlış yöntemler veya kavramsal hatalar (ör. RAID bir yedekleme değildir) nedeniyle sayısız veri kaybı yaşanır
• Veri, mutlaka çeşitli yöntemlerle korunması gereken önemli bir varlıktır

Bulut ve yedekleme hakkındaki yanlış algılar

• Pek çok kişi tüm verisini buluta emanet ederken verinin gerçekte nasıl korunduğunu sormaz
• Büyük bulut sağlayıcıları da paylaşımlı sorumluluk modelini uygular
  • Altyapı güvenliğini sağlarlar, ancak veriyi koruma sorumluluğu kullanıcıya aittir
• Bulut, özel sunucu, Kubernetes gibi ortamlarda da yedek eksikliği riski sık görülür

Yazarın veri kurtarma deneyimi

• Veri merkezi yangını, sunucu odasının su basması, deprem, fidye yazılımı, kötü niyetli saldırılar, yönetici hataları gibi pek çok veri kaybı vakası yaşandı
• İnternete bağlı sunucularda (e-ticaret, e-posta vb.) hem veri bütünlüğü hem de hizmet sürekliliği önemlidir
• Yedekleme basit bir kopyalama değildir. Özellikle çalışmakta olan veritabanı dosyalarını kopyalamak, geri yüklemenin imkânsız hale gelme olasılığını artırır

Yedekleme stratejisi oluştururken sorulması gereken temel sorular

• "Ne kadar riski kabul edeceksiniz?", "Hangi veriler korunmalı?", "Veri kaybı durumunda ne kadar kesinti tolere edilebilir?", "Ne kadar depolama alanı var?"
• Yedeği aynı makinede tutmak, makine arızasında işe yaramaz. Harici depolamaya yedek almak daha güvenlidir
• Ağ bant genişliği, geri yükleme hızı, depolama alanı gibi pratik unsurlar da hesaba katılmalıdır

Tüm disk vs dosya bazlı yedekleme

Tüm disk yedekleme

• Avantajlar
  • Tam geri yükleme mümkündür. Sistem önceki durumuna hızla döndürülebilir
  • Sanallaştırma sistemleriyle birlikte kullanıldığında faydalıdır. Proxmox gibi çözümler bu tür tam yedeklemeyi kolayca destekler
  • Bazı çözümler tam yedekten tekil dosya geri yükleme de sunar
• Dezavantajlar
  • Fiziksel sunucularda kesinti süresi gerekir
  • Çok yer kaplar, gereksiz veriler de depolanır
  • Dosya sistemi özelliklerine bağlı olarak yavaş olabilir veya uyumluluk sorunları çıkarabilir

Dosya bazlı yedekleme

• Avantajlar
  • Sistem araçlarıyla (tar, cp, rsync vb.) yapılabilir
  • Yalnızca değişen kısımlar yedeklenerek alan ve aktarım tasarrufu sağlanabilir
  • Tekil geri yükleme, taşıma, sıkıştırma ve tekilleştirme gibi esneklik sağlar
  • Sistemi durdurmadan çalıştırılabilir
• Dezavantajlar
  • Basit kopyalama çok fazla depolama alanı gerektirebilir
  • Snapshot olmadan çalışan bir dosya sistemini yedeklemek tutarsızlık ve hatalara yol açabilir

Snapshot kullanarak yedekleme

• Yedeklenen hedef çalışan bir dosya sistemiyse, yedeklemenin "başlangıcı" ile "bitişi" arasında veri değişebilir ve veri tutarlılığı bozulabilir
• MySQL, tarayıcı geçmişi gibi açık veritabanları, yalnızca dosya kopyalamayla geri yüklenemeyebilir
• Tutarlı bir yedeklemeyi garanti etmek için önce dosya sisteminin snapshot özelliğinden yararlanmak gerekir
• Yaygın yöntemler
  • Yerel dosya sistemi snapshot'ları (BTRFS, ZFS destekli sistemler)
  • LVM snapshot'ları: alan israfına yol açabilir ve snapshot silinirken sistemin durma riski vardır
  • DattoBD: zaman zaman kararlılık sorunları yaşansa da UrBackup gibi araçlarla birlikte kullanılabilir

Yedekleme yöntemi: Push vs Pull

• Push: Yedeklenecek sistem sunucuya bağlanıp veriyi gönderir
• Pull: Merkezi yedek sunucusu her sunucuya bağlanarak yedeklemeyi kendisi alır
• Güvenlik açısından, yedek sunucusunun dış erişime kapalı olması ve yalnızca gerektiğinde istemcilere erişmesi nedeniyle Pull yöntemi daha güvenlidir
  • Saldırı veya fidye yazılımı durumunda yedek verilerin silinmesini önlemek için, yedek sunucusunun kendi snapshot'ları da ayrıca uzun süre saklanır

Önerilen yedekleme sisteminin temel özellikleri

• Anında geri yükleme ve yüksek hız
• Harici depolamada saklama (ancak yerel snapshot'lar anlık geri alma için tutulur)
• Google Drive, Dropbox gibi ticari bulutların kullanılmaması önerilir. Veri kişinin kendi kontrolünde olmalıdır
• Sıkıştırma, tekilleştirme gibi verimli alan yönetimi
• Çalışması için gereken ek bileşenler en aza indirilmelidir

Gelecek yazı planı

• Çeşitli yedekleme senaryoları, fiilen kullanılan sunucular, temel ayarlar, farklı yazılımlar ve teknolojiler tanıtılacak
• Bir sonraki yazıda FreeBSD tabanlı bir yedek sunucusunun nasıl kurulacağı ele alınacak

[GN⁺]

Hacker News görüşü

• Mutlaka "push" yöntemiyle yedek almak zorunda olan makinelerde, erişim yalnızca kendi alanlarıyla sınırlandırılmalı; daha da önemlisi, yedek sunucusu güvenlik için kendi dosya sistemi snapshot'larını belirli bir süre saklamalıdır. Böylece iş yükü bozulup yedek sunucusuna erişilerek fidye amacıyla yedekler silinse bile, sunucuda snapshot'lar kalır. Benim tercih ettiğim yöntem, istemcilerin yalnızca yeni yedek yazabilmesi ve hiç silme yapamamasıdır; silme işlemi ise ayrı bir süreçle (manuel veya cron gibi) yürütülür. Bu yaklaşım rsync/ssh tarafında .ssh/authorized_keys içindeki allowed command özelliğiyle uygulanabilir.

  • Ben ikisini de kullanıyorum. Yedekleri iki yerde tutmak gerekiyor ama bu çift yedek yapısını zaten baştan hedeflemiştim. Yedek kaynakları ara bir konuma push ediyor, ana yedek deposu da oradan pull ediyor. Ara konum küçük kapasiteli olduğu için snapshot saklıyor ama ana depolama ile kaynaklar birbirini hiç doğrulayamıyor; yani her biri yalnızca ara konuma kimlik doğrulayabiliyor ve ters yönde doğrulama yok. Bu üç konumdan bir veya ikisi ele geçirilse bile diğerlerinin güvende kalma ihtimali yüksek. Sertifika yedeklerini tamamen ayrı ele alıyorum ki hepsi internet bağlantılı sunucularda tutulmasın. Gerçekten kritik veriler için ek önlem olarak offline yedek de alıyorum. Yapısal ayrım, gerçek yedek doğrulamasını biraz zahmetli hale getiriyor ama yedek depolama tarafı periyodik olarak checksum doğruluyor, sonuçları ara ana makineye gönderiyor ve kaynak ana makinede üretilen hash'lerle karşılaştırarak bozulma olaylarını yakalıyor. Bu kurulumla, kaynağın yedek snapshot'larının kendisine doğrudan zarar veremediği bir tür "soft offline" yedek elde etmiş oluyorum.

  • Ayrı bir container veya yalnızca yedekleme için ayrılmış bir kullanıcı da bir yöntem olabilir. Örnek olarak systemd-nspawn, hafif bir chroot jail gibi kullanılabilir ve içeride rm çalıştırılması tamamen engellenebilir. Basitçe pacman/pacstrap vb. ile bir chroot oluşturup, systemd-nspawn/machinectl ile yönetirsiniz. Bu yöntem, normal systemd kullanımına benzer biçimde erişim kontrolü, dosya yolu kısıtları, bellek/CPU limitleri, yalnızca belirli IP aralıklarına izin verme, ayrıntılı boot koşulları gibi birçok kontrol sağladığı için esnektir. BTRFS subvolume'leri de kullanılabilir; gerekirse tüm sistemi systemd-vmspawn ile tamamen ayırmak da mümkün. importctl ile çoğaltma otomasyonu da çok rahattır.

  • Ben, "yedek sunucusunun yedeklenen sunucu üzerinde hiçbir yetkisi olmadığı" pull yöntemini tercih ediyorum. Canlı sunucuda root yetkisi ele geçirilse bile yedek sistem etkilenmiyor.

  • Yedekleme için rclone copy kullanıyorum ve yalnızca obje silme yetkisi olmayan bir API anahtarı kullanıyorum. rclone sync gibi senkronizasyon yaparsanız verileri silebilir; bu yüzden bu yöntem daha güvenli.

  • syncoid'de de "istemci sadece snapshot/yedek kopyalasın, silme işini yedek sunucusu yönetsin" seçeneği olmasını isterdim. Şu anda silme yetkisi vermek gerekiyor, bu da can sıkıcı.

• Şaşırtıcı derecede çok insan yedeklemeyi önemsemiyor. Bu hem büyük hem küçük şirketlerde böyle. Danışmanlık verdiğim, yıllık cirosu 1 milyar euro olan bir şirketin bile kendi yedeği yoktu; yalnızca veri merkezi sağlayıcısının düzensiz yaptığı disk kopyalarına güveniyorlardı. Kendi başlarına hiç geri yükleme testi de yapmamışlardı. Kısa süre önce kullanıcı hatası yüzünden production DB tamamen silindi ve en güncel yedek 4 gün öncesine aitti; bu yüzden aradaki tüm transaction'ları yeniden üretmek zorunda kaldılar. Ama böyle bir olay yaşanmasına rağmen kimse şok olmadı, her şey olağanmış gibi devam etti.

  • Görünüşe göre bu, iş için gerçekten ölümcül değilse insanlar sorun etmiyor.

  • Yedek gereksinimlerini gereğinden fazla karmaşık hale getirmek de sık gördüğüm bir durum.

  • Belki hukuki nedenlerle böyledir; dava veya yasal saklama yükümlülükleri yüzünden yedeğin kendisi bile risk unsuru olabilir.

  • Bu, SOC 2 denetiminden geçmiş felaket kurtarma politikalarının bir yan etkisi. Çalıştığım şirkette de tüm ekiplerin felaket kurtarma politikalarını —hepsi SOC 2 onaylıydı— gözden geçirmiştik ve sonuçta gerçekten büyük bir olay yaşanırsa şirketi kapatıp eve gitmenin, normal bir kurtarmadan daha hızlı olacağı sonucuna vardık.

  • Production DB'de gerçekten 4 günlük tam veri kaybı yaşandıysa, müşteriler çok öfkelenmedi mi diye sormak isterim. O ölçekte bir şirkette bunun pratikte muazzam bir darbe olması gerekir gibi geliyor; gerçekte bunu nasıl yönettiklerini merak ediyorum.

• Paylaşım için teşekkürler. 10 yıldır yedekleme ve felaket kurtarma yazılımı geliştiriyorum ve sürekli duyduğum söz şu: "Bir arkadaşıma kendi yedek/felaket kurtarma çözümünü yapmasını tavsiye etmem." BCDR kurmak, gözden kaçırması çok kolay sayısız tuzakla dolu. Birkaç temel noktayı paylaşmak isterim. Yedek, "felaket kurtarma" değildir. Gerçek bir olay yaşandığında iş güvenini korumak için dakikalar ya da saatler içinde geri dönüş sağlanabilmelidir. RTO ve RPO kritik önemdedir. rsync copy tarzı dosya çoğaltma, dosya sistemi sürekli değiştiği için belirli bir anın yedeği değildir. Gerçek bir point-in-time yedek için "crash-consistent" ya da "application-consistent" yedek gerekir; ikincisinde kritik uygulamalar durumlarını diske yazar ve yedekleme sırasında durdurulur. Microsoft VSS gibi özellikler bunu sağlar. rsync copy ya da crash-consistent yedeklere asla körü körüne güvenmemek gerekir. Depolama tarafında Murphy kanunu her zaman işler; bu yüzden birden fazla konumda yedek (3-2-1 stratejisi) şarttır. Kendi deneyimime göre hangi tür disk olursa olsun hepsi bozulur. Dayanıklılık açısından NVMe SSD > SSD > HDD sıralaması doğru olabilir ama istisna yok. Yazacak daha çok şey var ama geç oldu, şimdilik burada bırakıyorum.

  • 3-2-1 benzetmesi eski dünyanın yaklaşımı. Bugün veri saklama konumu sayısı fiilen sınırsız; bu yüzden yerel snapshot'lar, uzak replikasyon ve farklı yöntemlerle ikili, üçlü yedekler çok daha önemli. Ben temel snapshot'lar için zfs kullanıyorum, ayrıca Borg da ekliyorum; bu kombinasyonla neredeyse her felakete karşı yeterli koruma sağlanıyor.

  • Bu söz bana bir Alice in Chains konserinde duyduğum benzer bir ifadeyi hatırlatıyor. BCDR çözümleri şirketler arası güvenin sembolüdür. Bu sistemler onlarca milyar hatta yüzlerce milyar ölçeğinde veriyi korur ve bir CTO'nun şirket yedeklerini açık kaynaklı bir yaklaşıma emanet etmeyeceğini düşünüyorum. Şirketlerin BT harcamaları, varlıklarının değeri ve vendor lock-in karşıtı stratejilerine göre genelde kademeli olarak artar. Profesyonel deneyimime göre fidye yazılımına karşı değiştirilemezlik (immutability) ve WORM yedekler kilit önemdedir; ayrıca mevzuata uyumsuzluk nedeniyle kamu BT projelerinde yaşanan sorunlara da defalarca tanık oldum. BCDR sağlayıcıları fidye yazılımını bir satış argümanı olarak öne çıkarıyor ama gerçek değiştirilemezlik, verinin birden fazla alana çoğaltılmasıyla kanıtlanır. İşte burada 3-2-1 stratejisi gerçek değerini gösterir. Diğer yedekleme ilkeleri hakkında da görüş duymak isterim.

  • NAS kullanıyorsanız, her iki tarafta da aynı üreticinin aynı model disklerini kullanmamak daha iyi olabilir.

  • "Birden fazla konumda yedek şart (3-2-1)" sözüne tamamen katılıyorum. Ama çoğu birey için "1" yani offsite kopya pratikte mümkün değil; sonuçta bir yedekleme hizmeti kullanmıyorsanız bunu kendiniz yapmanız için pek neden kalmıyor. Çevremde benim şehrimin dışında 7/24 bilgisayar çalıştırıp bunu yönetecek kimse yok.

  • "rsync copy veya hatta crash-consistent yedeklere asla güvenmeyin" kısmı, beni şu sonuca götürüyor: Sonuçta tüm sistem ve servisler altyapı araçlarıyla yeniden kurulabiliyorsa, asıl proaktif olarak yedeklenmesi gerekenler DB ile dosya/obje depolarıdır. Tüm VM'leri karmaşık biçimde yedeklemenin gerçekten pek anlamı yok.

• Yazı temiz ama eksik kalan bir nokta var: Gerçekten iyi bir yedek sisteminde geri yükleme hızı ve prosedürü net olmalıdır. Defalarca gördüğüm şey şu: insanlar yedeklerin düzgün alındığını sanıp rahatlıyor ama geri yükleme anında verinin yalnızca bir kısmı dönüyor ya da süreç günler sürüyor ve büyük zarar oluşuyor. restic adlı araç, ZFS gibi snapshot destekli bir dosya sistemi olmadığında dosya düzeyinde yinelenen veriyi ayıklayan snapshot yedekleri alabilmesi açısından çok kullanışlı. Ayrıca yedekleme "push" yöntemiyle yapılıyorsa, fidye yazılımı yedekleri de silebilir; bu yüzden "pull" yaklaşımı daha doğru. Push kullanılacaksa read-only medya (Bluray vb.) tercih edilmeli ya da en azından auto-snapshot/ZFS ile point-in-time geri dönüş mümkün olmalı.

  • Fidye yazılımı push yedekleri silebilse bile, sunucu yetkileri doğru sınırlandırılırsa bu sorun olmayabilir. Borg ve Restic, ssh üzerinden append-only garantisi verebiliyor; yerelde ise son savunma hattı olarak offline yedek disklerini dönüşümlü kullanıyorum. Gerçek yöntem için buraya bakabilirsiniz.

  • restic'in append-only modunda pruning işlemi yalnızca periyodik olarak sunucunun içinde yapılıyorsa, pull yöntemi kullanmadan da bunun yeterli olup olmadığını merak ediyorum. Bildiğim kadarıyla bu, restic'in fidye yazılımına karşı resmi olarak önerdiği yaklaşım.

  • "Geri yükleme hızı" gerçekten gereksinime göre çok değişiyor. Aile fotoğraflarımın yedeğinin geri gelmesi 6 ay sürse bile benim için sorun olmaz.

  • Read-only medya yerine yetkileri kısıtlanmış bir push sunucusu da alternatif olabilir. Örneğin ssh üzerinde sadece scp'ye izin verip chroot ortamıyla sınırlarsanız ve klasörleri günlük döngüyle tutarsanız, fidye yazılımı olsa bile eski verileri silemez. Benim yedek prosedürüm de yalnızca chroot+scp'ye izin veren bir ssh sunucusuyla çalışıyor; ayrıca read-only medya da kullanıyorum.

• Benim için ayrı bir yedek sistemi şart değil; ailedeki 4 kişinin 25 yıllık fotoğraflarını (telefon, kamera, indirilenler, taramalar vb.) verimli şekilde bir araya getirecek standart bir yöntem olsa yeterli olurdu. Henüz gerçekten tatmin edici bir çözüm bulamadım.

  • Ben NAS üzerinde Immich çalıştırıyorum ve medya ile Immich DB dump'ını her gün AWS S3 Deep Archive'a yedekliyorum. Immich, Google Photos benzeri işlevleri fazlasıyla sunuyor; masaüstü fotoğraflarını ve taramaları NAS'a eklerseniz Immich bunları otomatik olarak içeri alıyor. HN kullanıcısıysanız kurulumu zor gelmez.

  • "25 yıllık fotoğraf" ifadesiyle Kuzey Amerika usulü veri birimi şakası yapıp, aslında kesinlikle bir yedek sistemine ihtiyacınız olduğunu söylüyor. Ben syncthing'i gnu/linux/windows/android üzerinde bir mesh olarak çalıştırıyorum, arşivi iki Debian VM üzerinde düzenli snapshot'lıyorum ve borgbackup ile ikinci bir yedek alıyorum. RPO'm 24 saat ama istersem daha da düşürebilirim. Yalnız Apple cihazlarda syncthing arka planda çalışamadığı için bu kurulum uygun değil. Bende fotoğraflar 500GB, diğer belgeler de onlarca ila yüzlerce GB ama diff tabanlı yedek sayesinde verimli çalışıyor.

  • İndirilenler ve taramalar, gerçekten önemli değillerse zaten atılabilecek veriler. Telefon ve kamerayı Nextcloud ile senkronize ediyorum, yedekleme işlemini de sadece kendi ev ağım içinde çalıştırıyorum. Ardından NAS üzerinde günlük yedek ve sağlık kontrolü alıyorum. Son aşama ise güvenilir bir bulut yedeği ya da başka bir evde bulunan bir disk kullanmak; böylece ikinci seviye yedek de tamamlanmış oluyor.

  • PhotoPrism veya Immich gibi self-hosted çözümler, fotoğraflarda deduplikasyon ile arama/etiketleme için faydalı. Bulut yedeği tarafında Backblaze B2 + Cryptomator kombinasyonu ile şifreli depolama ve kendi upload script'inizi kullanabilirsiniz. Maliyeti TB başına ayda yaklaşık 1 dolar.

  • Ben syncthing kullanıyorum; resmi olarak Android desteği olmasa da fork sürüm gayet iyi çalışıyor. Ek olarak fotoğraf yedeği için ente.io veya self-hosted immich öneririm. Belgeleri ise paperless ngx gibi ayrı bir sistemde yönetmek daha iyi.

• Dirvish, hafif bir rsync wrapper'ı olarak kesinlikle denenmeye değer; döndürme, artımlı yedek, saklama, ön/son işleme script'leri gibi çok iyi özellikler sunuyor. 20 yılı aşkın süredir verilerimi kurtardı. Yazıda değinilen noktalarla da çok iyi örtüşüyor. dirvish resmi sitesi, rsync resmi sitesi

  • Dirvish'in rsync'e göre hangi yönleri daha kolay ya da daha iyi, bunu merak ediyorum.

• Ben biraz tembelce bir yöntemle bile donanım arızası ve hırsızlık gibi sorunların hepsine karşı önlem aldım. Kombinasyonum şu: masaüstü içinde geçici depolama, evde bir harici disk ve offsite bir harici disk (hepsi Samsung T7 Shield). robocopy /MIR ile her gün geçici ya da çalışma sonrası kopyalama yapıyorum, haftada bir harici diske yedekliyorum, ayda bir de offsite harici diskleri değiştiriyorum.

  • Harici diskler en azından farklı partilerden, tercihen farklı modellerden olmalı. Aynı model ve aynı lot kullanılırsa genelde aynı anda arızalanma olasılığı daha yüksektir, özellikle de geri yükleme sırasında büyük yük bindiğinde.

• Zamanlama iyi denk gelmişken kendi archlinux yapılandırmamı ve yedekleme stratejimi paylaşıyorum. yapılandırma/yedek otomasyon script'leri, borg otomasyon katmanı da açık durumda.

  • Ben python+borg ile SAN üzerindeki 51 blok cihazı snapshot'ını, 71 dosya sisteminin yedeğini ve S3 senkronizasyonunu otomatikleştiriyorum. Geri yüklemeyi offsite ortamda gerçekten test ettim ve VM'leri boot etmeyi sorunsuz başardım. Otomasyon hâlâ karmaşık ve tamamlanmamış olduğu için geri yükleme hızı yavaş, ama sistemi çok ucuza kurdum. Borg gerçekten çok güçlü. Herkes bunu deneyebilir ve sonuçta oldukça ekonomik bir çözüm olur.

• Benim değerli verilerim 100MiB'den az, bu yüzden seçilmiş yolları tar+compress+encrypt ile haftada iki kez yedekliyorum, birkaç aylık döngüsel saklama yapıyorum. Kopyaları hem evde hem ev dışında tutuyorum; kontrol ve bakım da neredeyse gerekmiyor. Birkaç satırlık bir sh script'iyle sorunsuz otomatikleşen gayet makul bir kurulum.

  • Yarın aniden ölsem, ailemin ve benden sonra geleceklerin gerçekten geri getirmeye değer bulacağı verilerin ne olduğunu düşünmek gerek. Yüz binlerce dosya yerine birkaç temel fotoğraf, video ve metin yeterli olabilir.

  • Bu yorum bana gerçekten değerli verimin ne olduğunu yeniden düşünme fırsatı verdi. Fotoğraflarım sıkıştırılmış halde bile en az birkaç GB, kişi listesi gibi çok önemli olmayan şeyler ise küçük. Genel olarak diğer çoğu şeyi kaybetsem de olur. Recovery key'leri biraz daha güvenli saklamam gerektiğini fark ettim ama en önemli hesaplarımın bazılarında zaten recovery key bile yok. Sadece fotoğraflar bile 2TB'a yaklaşıyor; hobi fotoğrafçısının kaderi.

• Yedeklemede tutarlılığın en zor yanı şu: uygulama verisini, servisi kapatmadan tutarlı biçimde yedeklemek pratikte neredeyse imkânsız. Disk snapshot'ında, o anda bazı servisler yazma işleminin ortasında olmak zorunda; dolayısıyla geri yükleme sonrasında bozulmuş bir durumla başlama olasılığı yüksek. DB dump'ları bu sorunu önemli ölçüde hafifletiyor ama onlar da çoğu zaman servis dışından alınmak zorunda olduğu için bir sorgunun ortasında gerçekleşebilir. Bu konuda deneyimi olan varsa dinlemek isterim.

  • Genel olarak DB'lerin bu konuda dayanıklı olduğunu, istediğiniz anda disk snapshot'ı alsanız bile yedek amacıyla yeterli olduğunu düşünüyorum. Asıl endişe pil destekli olmayan cache gibi özel durumlar olurdu ama günümüz bulut ortamlarında bu mimari pek kalmadığı için büyük bir sorun değil.

  • Strateji, DB dışında yakalanması gereken başka uygulama durumu olup olmamasına göre değişir; örneğin cache'in de yedeklenip yedeklenmeyeceği gibi. pg_dump/mysqldump canlı bir DB'nin snapshot'ını güvenli biçimde almayı gerçekten mümkün kılıyor ama biraz yavaşlar ve dump boyutu büyür gibi bedelleri vardır. Bundan kaçınmak için büyük PostgreSQL DB'lerinde yedekleme öncesi yalnızca-okunur bir replica kullanıp replikasyonu durdurmak, yedeği almak ve sonra replikasyonu yeniden başlatmak yöntemini de kullandım.