Cílem bylo zajistit, aby data byla někde k mání v případě odchodu SSD a zároveň to řešení (potenciálně možná s výjimkou nějaké klidové doby) nebylo samo sebou bržděné. Zároveň si skutečně dokážu představit situaci, že mohu přijít o den dat, přičemž historická data netřeba uchovávat. A zároveň - SSD má třeba 4 TB a to už je docela dost dat na to, aby se to jednou za čas zazálohovalo jako celek.
Proto jsem jako výstřel sondoval možnost, kterou jsem uvedl, protože mi připadala principielně elegantní.
Ano, ten základ jsem pochopil včetně toho, že nechcete, aby to bylo permanentně bržděné tím pomalejším diskem (nebo nějakým image souborem) při synchronních zápisech.
Jen prostě pokud to má být ochrana proti selhání toho primárního zařízení, tak by to mělo zaručit, že částečná provedená synchronizace nebude znamenat také nepoužitelnou zálohu.
Kvůli těm snapshotům jsem se ptal, co tam teď máte za filesystém a distribuci. Možná už je to na nějakém domácím serveru, kde máte třeba Proxmox, který má rovnou ZFS modul, takže by to případně nebyl problém rozběhnout tenhle filesystém. A i v ZFS se dá pracovat s image soubory místo disků, pokud byste to chtěl otestovat nebo takhle nastavit cílovém zařízení, kde už je jiný existující filesystém a další data. ZFS snapshoty, send a receive, jsou vcelku přímočaré operace včetně toho inkermentálního posílání.
Viz např.
https://docs.oracle.com/cd/E18752_01/html/819-5461/gbchx.htmlJen kdybyste pak používal ty image, tak to má nějaké konsekvence podle toho, jestli byste pak chtěl, aby se to připojovalo automaticky po startu systému (a bude třeba říct systemd nějaké pořadí, aby se nejdřív připojil ten filesystém pod tím), nebo jen pomocí třeba nějakého zálohovacího skriptu.. kdyžtak rozepíšu víc, co nastavit za optiony, když byste importoval pool s image souborem.
U Btrfs je to pak analogické.
Co je tam typově za data jsem zas sondoval i kvůli případnému souborovému zálohování.. např. pokud byste nemohl, nechtěl používat Btrfs ani ZFS.
Souborové zálohování může být bezpečnější volba než ta bloková synchronizace, protože např. klasický rsync nebo rclone (rychlejší porovnávání souborů k přenesní, paralelní operace) pracují ve výchozím nastavení tak, že to do cílového umístění přenesou nejdřív jako dočasný soubor a pak následně atomicky přejmenují.
Což je třeba v pohodě pro drtivou většinu typů užvatelských souborů, co se moc nemění, nějaký sync task na noc nemusí být prakticky problematický (funkčně, časově).
Na stranu druhou právě třeba u image disků virtuálů nebo databází tohle problematické je.. ať už kvůli konzistenci přenášeného souboru nebo neefektivnímu přenášení všech dat (ve virtuálu se změní 100 MB, v cíli se zapisuje celá 100 GB image).
Pokud se tam vyskytují oba typy dat, je samozřjemě lepší to nějak zkombinovat v rámci zálohovacího skritpu (úlohy). Používat standardní synchronizaci, ale vyloučit pár kritických adresářů, na které je pak vhodné aplikovat speciální zálohovací nástroje, co umí pracovat a přenáší jen přírůstky a také pořeší konzistenci.
Ale to už jsem se možná rozkecal o tom, na co jste se neptal (původní idea za mě není dobře realizovatelná) a odpovídal jsem spíš na to jak obecně pořešit zálohu dat z toho SSD..
Poslední příspěvky