Řešení 1:
Zkontroloval bych, co zálohujete, a případně použil „vícecestný“ přístup. Můžete například zálohovat úložiště Git tím, že budete neustále spouštět Git pulls na záložních serverech. To by zkopírovalo pouze rozdíl a zůstala by vám druhá kopie všech repozitářů Git. Pravděpodobně byste mohli zjistit nová úložiště pomocí API.
A použijte "vestavěné" zálohovací postupy k zálohování problémů atd. Pochybuji, že 3TB pochází z této části, takže byste byli schopni provádět zálohy velmi často s velmi malými náklady. Můžete také nastavit databázi PostgreSQL s teplým pohotovostním režimem s replikací.
Vaše 3 TB možná pochází z obrazů kontejnerů v registru Docker. Potřebujete je zálohovat? Pokud ano, pak může existovat lepší přístup právě pro to.
V zásadě bych doporučil opravdu se podívat na to, co tvoří vaši zálohu a zálohovat data v různých částech.
Dokonce i zálohovací nástroj od GitLab má možnosti zahrnout/vyloučit určité části systému, jako je Docker Registry.
Řešení 2:
Pro tak krátkou dobu mezi zálohami (1 h) je nejlepší spoléhat se na snímek na úrovni souborového systému a send/recv podporu.
Pokud použití ZoL není ve vašem prostředí problém, důrazně doporučuji jej používat. ZFS je velmi robustní souborový systém a opravdu se vám budou líbit všechny doplňky (např. komprese), které nabízí. Při spojení s sanoid/syncoid , může poskytnout velmi silnou strategii zálohování. Hlavní nevýhodou je, že není součástí hlavního jádra, takže jej musíte nainstalovat/aktualizovat samostatně.
Případně, pokud se opravdu potřebujete omezit na věci obsažené v hlavní řadě, můžete použít BTRFS. Ale ujistěte se, že rozumíte jeho (mnohým) nevýhodám a pita.
Nakonec je alternativním řešením použití lvmthin pravidelně zálohovat (např.:s snapper ), spoléhající na nástroje třetích stran (např.:bdsync , blocksync atd.) pouze pro kopírování/zasílání delt.
Jiný přístup by byl mít dvě replikované počítače (přes DRBD ), kde pořizujete nezávislé snímky pomocí lvmthin .