Jag håller med om att inte lita på automatiska backupper även om de oftast fungerar (Duplicati för min del) - man skall också ha en manuell 'hands on' backup som görs ibland så att man vet att man har en bra backup utan för många program mellan.
För min del är det rsync mot externa USB-diskar på BTRFS filsystem och gör en snapshot med i Read Only inför varje ny synkning med rsync. snapshot tar ingen extra plats bara data som skrivs senare allokerar ny diskutrymme.
Varje snapshot är helt oberoende av varandra och det finns ingen ordningsföljd mellan dem att ta hänsyn till när man vill ta bort snapshot senare. Har man lust och packa extra med blockdeduplikation så kan man köra 'bees' och jag kan säga att det ger mer i diskbesparing än att hålla på med kompression på filsystemnivå men det är inget som hindrar att man kör båda ändå då filsystemskompression trots allt packar diskimages från SSD väldigt mycket (SSD 'lediga utrymme' är nollad av användning med TRIM av använda OS (som win10) medans snurrdiskars 'lediga utrymme' innehåller gammal data och det packas inte lika väl)
Har provat lösningar som du med tar, med hårda länkar som timemachine gör men tycker BTRFS med oberoende snapshot hittills är den bästa lösningen. och med 'bees' snurrande i bakgrunden kan squeeza ihop filerna ännu mera och tex helt ta bort komprimeringen av '0' i diskimages (som ändå tar lite plats för headern för sitt block) och ersättas med 'hole' som inte tar någon alls diskutrymme
Slutligen har jag aldrig råkat på att en extern USB-disk med BTRFS (med dubbel metadata) inte skulle vara monterbar, och jag har provat mycket med glappande sladdar under full skrivande, strömavbrott etc. både avsiktliga och oavsiktliga och det monteras alltid ändå med filerna kvar även om det kan ta lite tid när filsystemet inte är snyggt stängt - Jag kan inte säga samma sak om externa USB-diskar med NTFS som filsystem... (dubbelsuck i hur mycket data jag förlorade den gången trots alla försök med R-studio etc. för att försöka rädda filer trots att det var bara 2 sektorer som förstördes - första sektorn på $mft och $mft_mirr och att det kunde bli så total mess av det...)
---
@SanyaIV
Du får köra dina backupper mot blackblaze B2 (numera även över S3-protokoll) där kan du själv bestämma hur lång retensiontid dina 'raderade' filer får ligga kvar i det dolda till de når sista 'förbrukningsdagen' och försvinner permanent (30 dagar default) - haken, du får betala för volymen för alla dina filer - synliga som dolda, det är ingen gratisplats här inte.
backuprogram som Duplicati hanterar B2 liksom S3-protokoll och många fler.
Att titta på är också Duplicacy (observera de väldigt lika namnen) som är av prenumerationsmodell (men underliggande kod som gör jobbet för i alla fall uppackning från repository är Opensource) och deduplicerande och det man betalar för är automatiken och webgränssnittet typ.
Duplicacy kan till skillnad från Duplicati använda samma repositorie för flera datorer och deduplicerar lika filer även mellan olika datorer för att spara plats. - båda nämnda krypterar filerna innan de skickas över på lagringsplatserna
För kommandoradsknuttarna finns borgbackup och restic (ja de finns numera också för att köras i windows powershell) - deduplicerande mot sina egna repositorier och båda med sina för och nackdelar och givetvis källkrypterande innan filerna skickas till lagringen.
Restic kan hantera molntjänster medans borgbackup är rätt fattig när det gäller protokoll mot lagringsplatser, dock fungerar via ssh om lagringen på andra sidan också har en fungerande borgbackup-daemon snurrande)
Man skall heller inte glömma bort att "rclone" (finns också för win10) kan kommunicera med många molntjänstprotokoll och skapa en 'diskdrive' eller mapp i windows som backupprogram oavsett typ kan skicka sina filer till.
vill man göra sin egna S3-kompatibla 'molntjänst' så kan man titta på 'minio'
