Söker bra backup-lösning, specifik.

Borgbackup men osäker om de fungerar med Windows eller WebDAV.

Är det egen driven webdav eller kommersiell tjänst? - om det är egen - alternativ protokoll som S3 eller rentav klassisk ssh ??

Borgbackup ('borg' som kommando) finns för windows men klarar inte webdav eller andra molntjänstprotokoll. Stöd för att köra via 'ssh' finns dock

Sedan finns Duplicati, Duplicacy, och Restic som alla kan hantera mer eller mindre stora uppsättning olika molntjänst-protokoll

Och kan inte backupprogrammet köra direkt mot molntjänst så kan man prova 'rclone' som mellanprogram i kontakt mot molntjänst då den kan göra en mapp eller en drive-enhet som backupprogrammet (tex borgbackup) sedan lägger sina filer i och rclone synkar mot molntjänstens lagringsformat i nära realtid. rclone i sig kan också synka filer mot molntjänst på samma sätt som rsync men den har ingen historia-hantering, lika lite som rsync.

Modern backupprogram hanterar inte fullbackup med efterföljande diff/incrementkopia som du tänker dig - det är gammal tänk från TAR-tiden.

Moderna backupprogram hanterar data på liknande sett som molnlagring med chunk och bucket och nästan alla dessa är av deduplicerande typ vilket innebär att filer hackas upp i småbitar och bitarna packas in i chunk, samtidigt kalkyleras och får en hashvärde med vidhängande adresslapp i vilken chunk biten finns i, var den börja inom chunken och hur stor, filbitar som kommer senare med samma hash lagras inte alls utan endast databasen uppdateras. Man har databas som håller reda på hashvärden för småbitar som bygger varje fil och i högre lager också varje backupsession.

I programmen ingår kryptering innan det lämnar datorn och givetvis massor av olika kontroller och checksummor/hashvärden som håller ihop backuppsessionerna och märker om något modifierats utifrån.

tex. borgbackup ändrar aldrig gamla 'chunk' i efterhand utan gör hela tiden nya löpande och det gäller också vid radering av backuppsessioner och 'nästan tomma' chunk (dvs. det mesta av datat inte länge har någon referens mot databasen med hashvärdena) packas om till nya fyllda och den tomma chunken med invalid data tas sedan bort för att återvinna diskplats.

Det innebär också att databitar som har samma hashvärde senare - inom fil eller återkommande lika filer i ett filträd och mellan sessioner - sparas bara en enda gång - aldrig dubbla kopior eller multipla kopior i repositoriet. - det gör att det inte exploderar i backuppvolym om man flyttar sin enorma stora mapp med bilder till annan plats i filsystemet, eller bara byter namn - medans det smäller med full uppladdning av alla bilder igen och lika mycket plats till tas upp i backupmediat med en klassisk tar-orienterad backupprogram - det blir en jättestor inkrementfil...

En sak till som är fördel med modern deduplicerande backup är att du kan radera sessioner i vilken ordning du vill - klassisk TAR-orienterade backupper som de flesta backupprogram anammade i olika grad till bara för ett antal år sedan har nackdelen med tex. huvudbackup och sedan 30 inkrementella backup efter varandra så tar återställningen oerhört lång tid då huvudbackuppen och samtliga sessioner skall tuggas igenom för att nå den senaste sessionen - sedan blir det ömtåligt då det räcker med en enda fel på en av inkrementfilerna så kan man kasta alla sessionerna efter denna punkt. Dessutom är uppäcktsgraden för fel inte alltid så högt då på den tiden när konceptet med tarlika-backupprogram skapades så var beräkning av hash jobbig och man hade få kontrollpunkter att datat var korrekt - om ens några alls. - konceptet som används zip-arkiv med en enda checksumma för hela volymen är heller inte bra då ett enda fel ofta fick resultatet att hela arkivet blev odugligt.

Och om man skall ha tex. 3 månader backup med klassisk tar-koncept (som tex duplicati första generationen använde sig av) blir det då 3 stycken huvudbackupper med sina inkrementella filer @ 30 dagar + den sessionen man jobbar på - och det tar diskplats med 4 uppsättningar huvudbackupper... ...och att gå förbi 30 dagar med inkrement är också mycket riskfullt...

Med borgbackup, Duplicati, Duplicacy, Restic så tar man huvudbackup en enda gång och sedan kör man på med session efter session och när (valfri) sessioner tas bort så försvinner de filbitar i repositoriets filer som inte längre har någon referens i databasen och då återvinns diskplats (i restic måste man dock köra manuell körning för att städa upp invalida chunk och packa om halvtomma dito tex. efter man tagit bort backupsessioner och man gör det helst inte efter varje borttagen backupsession och är något man lär sig snabbt att inte göra i onödan...)

Skall man ha filer i filträd i tex. NAS direktåtkommligt och även backupgenerationerna bakåt åtkomliga så säger jag snapshot på BTRFS eller ZFS fillsystem i en NAS/Server.

snapshot kostar ingen plats men å andra sidan få man inte tillbaka någon diskplats innan sista backupsessionen med tex. stor fil har försvunnit.

En backuppsession i tex borgbackup https://borgbackup.readthedocs.io/en/stable/ , Duplicati https://www.duplicati.com/ eller duplicacy https://duplicacy.com/ gör precis detta - det finns några få till med tekniken men dräller inte av det då det anses som 'nytt'

Du väljer en backupsession för en viss datum och under denna finns alla filer och mappar som du en gång i tiden sa att den skulle göra backup på för just den dagen.

Nästa session tagen dagen efter kan vara exakt samma filer utom de 3 du modifierade under dagen och så vidare.

Det är en databasmotor som håller reda på sessioner och i dessa ingående filer och dess versioner och hur de skall sättas ihop igen från småbitar lagrade i olika chunk för en viss backupsession till en komplett fil när du skall hämta ut filer igen

Att du inte hittar dem är förmodligen att de flesta är open source utan marknadsföringsresurser eller hör till den dyrare halvan av kommersiella backupprogram och inte finns i de fria editionerna eller entry-level av programmet.

Detta med blockmässig lagring är rätt nytt och det är många gamla företag med backupprogram som helst inte vill låtsas om utan sälja sitt gamla junk utvecklades för 10 år sedan med möjligen uppsnoffsing av GUI:t med jämna mellanrum.

Duplicati-gänget insåg att de var i en återvändsgränd för sin program med tar-liknande lagringsfilosofi med huvudbackup och inkrementell enligt klassiskt sätt - scrappade det och lämnade det 'as is' för dem som ville fortsätta att köra (den var mycket driftsäker backup och backup-scheduler i sig - men tex. krav på minst 3 månader retension-tid var en pina med 4 st huvudbackupper varav 3 med var och en 30 dagars inkrementfil-kedja medans man byggde på den fjärde och måste vara komplett innan man kunde radera den äldsta huvudbackuppen med sina inkrement) och började på nytt med helt annan tänk på lagringen med ideer enligt hur molntjänstlagringens backbone jobbar, kika på borgbackup och attic och restic mfl. - implementera stöd för flertalet stora molntjänster etc. - det kräver mod och de företag som lever på gamla meriter gör helst inte sådant och vill fortsätta tjäna pengar på något som gjordes för 10 år sedan och en dag upptäcker när intäkterna sinar att de inte längre är med i spelet...)

Är man inte rädd för terminal i Linux och CLI-program så skulle jag titta på borg-backup för att förstå konceptet - min sista körning var på 43TB (i arkiverings-roll) - också en viktig aspekt, att det inte kraschar när det råka på jättefiler som hela diskimages eller mappar med miljoner av filer, hårda länkar, symboliska länkar etc.

Borgbackup kan du montera repositoriet till en mapp och sedan i mappen har du alla sessioner som är gjorda och sedan kan dyka in i valfri sessionsmapp (kan dock ta lite till när den bygger upp virtuella filstrukturen för sessionen då det är databasmotorn som bygger den och emulerar en hel filsystem - filsystemet du gjorde backup på! - och sedan kan klättra runt med i valfri filhanterare, kopiera ut enskilda filer eller hela mappträd.

Detta med återställning beror mycket på programmakarnas filosofi och jag håller med dig att man är ofta ivrig att återställa backup på exakt samma ställe som backuppen togs och inte alltid helt logiskt hur man lägger återställning av mappträdet/file på annan mapp eller lagringsdisk istället - i Duplicati vet jag att man kan göra återställning från en backupsession av enskilda filer eller hela filträd på annan plats än orginalplatsen - men noterade även där att man har återställning på plats som default och kan göra ont om man inte är uppmärksam och pekar till annan plats/lagring.

Servern är bara för fillagring och kan inte titta i filerna - tänk på att moderna deduplicerade program är ofta avsedda för molnlagring med begränsat upp och nedladdningstakt (och trafiken kan också kosta pengar) och det gäller att minimera trafiken - men också för att filerna som sänds upp är värdelösa för program som scannar igenom och letar efter innehåll som sedan kan säljas utan din vetskap...

Kryptering är en transportlager som appliceras på redan färdiggjorda filer innan de skickas till repositoriet - kan du passordet/passfrasen så kan repositoriet öppnas för användning och återställning - kan du inte passordet/passfrasen så är det bara en bunt filer med helt obegripliga slumpliknande innehåll.