1) Jak je btrfs send/receive odolné proti chybám, co na souborovém systému můžou vzniknout (chyby způsobené non-ECC RAM, chyby softwarové v ovladači…)? Tj. jsou přenesené diffy nějak hodně oddělené, aby se nakopírováním rozbitého FS nerozbila i tato „záloha“? (chápu, že na toto může být složité odpovědět, protože nevíme, jaké všechny chyby mohou vzniknout)
2) Jak je odolné proti úmyslnému poškození? Tj. pokud mám plnou kontrolu nad tím, co se natlačí do "receive", mohu cílový souborový systém zničit? (a např. takto zničit zálohu, zašifrovat originál a požadovat výkupné)
Osobně z tohoto důvodu sice preferuji na zálohování btrfs snapshoty, ale přenáším je s rsync --inplace, což je o trochu méně efektivní, ale uvedené problémy nemohou nastat (vyžadovalo by to RCE v rsyncu).
Odpověď na obě otázky je "nijak", řešení integrity a bezpečnosti proudu je mimo záběr nástroje. Já si ten stream ženu skrz openssl, který bezpečnost zajistí.
btrfs send/receive posílá stream příkazů podobný libc použití, tj. fopen, fseek, fwrite, fclose, a podobně. Je tedy velmi snadné, máte-li k němu přístup, injektovat velmi destruktivní příkazy. Je ale dobré zmínit, že btrfs receive vytváří nový read-only snapshot, nikdy neupravuje už existující, takže o zálohu přijít nemůžete. Nejhorší, co se může stát je, že se aktuálně prováděná záloha nepodaří. Že se to nepodařilo ale musíte ověřit sám (např. kontrolou manifestu s hashi).
> Já si ten stream ženu skrz openssl, který bezpečnost zajistí.
Nezajistí, protože při zálohování je potřeba předpokládat, že přímo zdroj zálohy je kompromitovaný. OKD a Benešovská nemocnice by mohli vyprávět.
> Je ale dobré zmínit, že btrfs receive vytváří nový read-only snapshot, nikdy neupravuje už existující, takže o zálohu přijít nemůžete.
OK, pokud je to takto, tak potom je to v pořádku.