Det är en av osäkerheterna med externa molntjänster - villkor och snabbhet (samt pris) kan ändras, klienter gör plötsligt inte sitt jobb eller tar för lång tid på detta etc. etc. - och när man väl behöver backuppen så kanske det går väldigt långsamt att tanka tillbaka och en del tjänster har typ 4-dubbla GB-kostnaden när man återhämtar datat (tex. blackblaze B2 och Amazon S3 har asymmetrisk prissättning beroende om data skickas upp eller hämtas tillbaka)
man bör se till att molntjänsten inte är den enda backupstället, utan man har också en nära sig i form av extern USB-disk och/eller egen NAS.
Backup på molntjänster är en 'last resort' när det skitit sig rejält hemma som stöld, brand, översvämning eller åsknedslag.
---
Duplicati är ganska rättfram när man sätter upp en backupsession och default-värdena fungerar ganska bra. - möjligen kan momentet att man sätter passorword på sina arkiv och delen var man sänder sin backupdata till som upplevs lite komplicerat eftersom det finns allt större urval även till kommersiella molntjänster (men det är också dess styrka i många fall).
Skall man sända data via en ssh-konto till en NAS så brukar det vara lite bök innan allt fungerar - men det är också en av de säkrare sätten att 'gömma undan' sina backup-filer så att de inte är åtkomliga av oönskad programvara som ransomware - ja under förutsättning att filerna inte dyker upp i skrivbar form i någon nätverksvolym på använda NAS förstås.
Duplicati kör diffar mellan backupgenerationer (använder liknande teknik som rsync och lagrar bara över de binärstycken som skiljer sig sedan förra backuppen) - dock gör den en full backup 1 gång i månaden (eller vilken tidsmellanrum man nu sätter) då det beror på att återställningstiden kan bli för lång (och allt ökad risk för att fel i någon diff-fil kan ge omfattande kedjefel vid återställande senare om det är många generationer) om man på sista dagen innan ny fullbackup vill hämta gårdagens version - då relevant del av fullbackuppen måste hämtas och sedan applicera alla diff-filer dag för dag tills man får den generationen som man tänkt hämta hem. Det gör också att man inte kan ta bort enskilda dagar eller glesa ut backuppen i efterhand (typ daglig backup 1' veckan, vecka 2-4 är veckobackup, och därefter månadsbackup) då alla sessioner inom månadsbackuppen är hårt inflätade i varandra i en råtta på repet-kedja, utan det är hela månades backup med alla ingående dagar som ryker på en gång när fullbackuppen väl tas bort.
Det är den delen med flera fullbackupper i Duplicati som man faktiskt blir lite irriterad på (om man är på sidan som skall göra backup på NAS:en där dessa filer är lagrade...) om man skall ha daglig backup med 3 månaders historia - man har då 4 fulla uppsättningar (3 sparade och en pågående) + tillhörande dagliga diff-filer på sin backupmedia hela tiden och man tycker att det borde bara räcka med 1 fullbackup + diff-filer...
...men försöker man med detta i snålhetens namn med att bara göra fullbackup var 3 månad och ha diff-filer för 3 månader (och ändå måste ha 2 uppsättningar eftersom man inte kan ta bort den gamla backuppen innan den nya är gjord och rymmer 3 månader med data - om man skall ha 3 månaders retension-tid i alla lägen) så är det större sannolikhet att man biter sig i tummen den dagen man vill ha tillbaka filer igen...
Nu skall dock sägas till Duplicati:s fördel att den har alltid fungerat när det behövs - har en dator på jobbet där duplicati installerades 2012 och sedan snurrat på - två tillfällen varav en helt nyligen så behövde man hämta tillbaka filer och då har det alltid fungerat fläckfritt, installationen har haft noll och intet i underhåll och ingen har tänkt på det eller ens verifiera funktionen efter månaderna efter installationen - det är precis så backupprogram skall jobba, stabilt och osynlig tills den dagen när den behövs.
Ur stabilitets-synpunkt så är det troligen det stabilaste backuplösningen jag har sett när det gäller backupprogram.
---
Nu är jag rätt förtjust i tankegången i 'Borg-backup' med "key - value storage" av datablock med en nyckel som pekar på ett stycke binärdata i någon 'bucket' i repositoriet och sedan databas som håller reda på vilka stycken som hör till vilka filer, vilket gör det enkelt att deduplicera, ta bort och lägga till stycken samt accessen till dessa 'stycken' är samma oavsett backup-session. Backupsessionerna i sig har då ingen beroende av varandra utan kan tas bort i valfri ordning och för sessionen unik data tas bort samtidigt från repositoriet för att återskapa lagringsutrymme igen (man kan även filtrera ut oönskade filer i hela repositoriet gällande samtliga backupper om man fått med tex. icke deduplicerbara, komprimerbara och krypterade cache-filer från spotify och andra streamade-tjänster, oönskade duplicatisessioner, eller sängkammarbilder... etc.)
- Borg-backup har också support på klientsidan där man hashar igenom klientdatorns ändrade filer snabbt och hittar skillnader och kopierar bara över de binärstycke som inte redan finns i repositoriet och uppdaterar databasen. Har man mycket bilder, kopior av dessa på flera ställen samt flyttar runt hela filträn med bilder så är borg-backup oslagbar då den förstår att filen i fråga bara bytt position i filträdet och uppdaterar bara databasen lite - De flesta andra backupsystem ser inte sammanhanget att en fil eller filträd-flyttat på sig utan ser bara att filerna försvann på ett ställe och dök upp på annat ställe mellan backupsessionen vilket gör att det lagras dubbelt i backupprogrammets diff-filer och det sväller iväg i storlek.
Nu är borg-backup tyvärr inte särskilt väl-stött i windows (finns cygwin-client eller under 'linux' i windows) eller har snygga(re) GUI:n på samma sätt som Duplicati - hade gärna sett en ihopslagning av teknikerna på lagringssidan just för att inte behöva mer än 1 fullbackup och effektiv lagring, återställning och borttagning av enskilda backupsessioner och därmed inaktuell data av skillnader mellan backupsessionerna.
---
I stort sett alla moderna stora lagringssystem jobbar med 'key - value' filosofi i olika former (även det tänket finns mer eller mindre uttalat i moderna filsystem som BTRFS och ZFS - och definitivt i hyrda lagringsutrymmen hos Blackblaze B2 och Amazons S3 mfl.) då att köra linjär ström som med 'tar' och dess efterföljare (inklusive duplicity, duplicati med samma grundfilosofi med huvudbackup och därefter diff-filer som modifierar huvudbackupen som om datat ligger sekventiellt på band) har visat sig vara riktigt jobbiga och tidsödande vid en återställning.
