Administrace komentářů

Asi jsem se nevyjádřil přesně: Mám 4 fyzické oddíly, sda1,sdb1,sdc1,sdd1 (samozřejmě označované UUID), nad každým je samostatný LUKS otvíraný klíčem, který je někde na root oddílu (také šifrovaném). LUKSy vytváří 4 šifrované zařízení /dev/mapper/backup1 až backup4. Nad těmito zařízením je btrfs raid10. A ten je mountlý do /var/lib/backuppc

Původní sestava byla: 4 fyzické disky, nad nimi mdraid 10. Což vytvořilo blokové zařízení /dev/md126, nad ním byl LUKS vytvořil /dev/mapper/backup, a nad ním byl btrfs single disk.

Původní idea byla: výhoda bude v méně šifrování - datový blok se zašifruje jednou a pak se rozdělí do raidu již stejná data. Ale současné pozorování je, že i když se každá kopie musí zašifrovat zvlášť do každého disku (dvakrát vetší množství dat zašifrovat), tak celkový průtok dat je vyšší.

BackupPC, jak jsem již psal, provádí deduplikaci záloh tím, že každý zálohovaný soubor je kompresovaně uložen pod názvem, kterým je hash hodnota souboru (zapsaná hexa), a je umístěn v adresářové struktuře, která má první a druhou úroveň adresářů odpovídající první a druhý byte toho názvu (např ./04/ac/04ac02024c52...) v druhé větvi jsou počítače, podtím jejich konkrétní zálohy a podtím jejich adresářové stromy, které obsahují jen odkazy na tu primární datovou zálohu. Tedy jeden konkrétní soubor je v záloze umístěn jen jednou, i když je na mnoha počítačích a mnohokrát z jednoho počítače zálohován. Navíc pro zálohu BackupPC používá standardní rsync na zálohovaném systému, ale na serveru používá upravený rsync server (rsync_bpc). Nezkoumal jsem zdroják, ale podle chování a zátěže serveru jsem si jist, že rsync_bpc si uchovává (čte ze stromu) hashe místo toho, aby četl a porovnával soubor, protože v případě zálohování dat, které se nezměnili od poslední zálohy, je klient silně zatížen a server nedělá téměř nic.