För arkivering i en (ibland uppdelad) stor fil
Lagra i okomprimerad TAR-format (sk TAR-ball) och filerna i denna är valfritt okomprimerade eller komprimerade. Vill man ha integritetskontroll så komprimerar man filerna med tex gzip eller bzip2 innan de packas i TAR-filen då komprimeringsprogrammen har CRC mm. kontroll på filerna.
TAR arkivformat är en av de få arkivformaten som inte går helt trasig och hela arkivet blir oläsbar vid minsta fel som tex. plågar (PK)ZIP och RAR, som har en direktory-struktur i början och sedan bara pekar på data packad i kant i kant i filkroppen utan möjlighet att skilja ut datadelarna i efterhand. Skadas början eller slutet av de flesta typers arkivfiler så är arkivet totalkörd!!
TAR har distrubierad direktory vilket ungefär kan sammanfattas med magick number ("USTAR" i det här fallet), fil-path med rättigheter, filnamn och sedan filkroppen, därefter börja det med "USTAR" igen, filpath och filnamn sedan filkropp i en lång remsa efter varandra. Det innebär om bitar av TAR-bollen saknas så kan resterande hela filer ändå återskapas genom att man synkar emot att hitta "USTAR" och därefter vet man hur många byte före man behöver klippa med tex 'dd' för att sedan få en fil som är läsbar med TAR igen för att packas upp.
---
Arkivering i Repositorie:
https://www.borgbackup.org/
(somliga utnämner denna till arkiveringens heliga graal om man kan med att jobba i CLI-miljö)
Borg-backup om man kan göra jobbet i Unix-miljö (går med en viss tuggmotstånd att göra även i windows10-miljö och nyttja deras subsystem med linux-stöd alternativt via cygwin (tror dock inte att det uppdateras längre där iom. att det går att kompilera upp tillfredsställande under windows linux-subsystem idag) )
Det är en deduplicerande och komprimerande archiver med inbyggd kryptering (för tex. lagring i molnlagringsstjänst) och också designad för att klara en del felsituationer inom repositoriet och har olika skadebegränsande och reparationsstrategier vid inträffade fel.
Programmet delar upp filer i småbitar - kalkyleras en hash-summa och sedan lagras biten som en strimla i en chunk och hur den delas upp bokförs i en med datat distrubierad databas (det är detta som gör den reparerbar). Alla filer efter detta som har likadana bitar som redan finns i repositoriet så bokförs det bara i databasen utan att det lagras igen medans unika nya bitar så fyller det på repositoriet allt eftersom.
Alla filer som lagras där så lagras innehållet i bara en enda gång - oavsett hur många backup-sessioner man än gör, oavsett hur många lika filer inom filträdet eller att filer har flyttats runt mellan filträden eller bytt namn mellan sessionerna. Även partiellt lika filer som diskimages dedupliceras så långt det går både inom filen och mellan resten av alla tidigare lagrade filbitar i filrepositoriet för att det skall lagras så få unika filbitar som möjligt.
Detta gör att man kan ha obegränsat antal sessioner i arkivet, och kan raderas oberoende av varandra och utan någon beroende av backupordning och det är bara sessionens unika data som försvinner vid en sessions-radering medan mellan sessioner likadan data hålls kvar till sista referensen försvinner (och då frigör diskutrymme)
de flesta arkiv-formaten är väldigt dåliga på att kunna filtera/radera bort oönskade filer i efterhand och över flera sessioner - men i borg-backup finns möjligheten ändock utan att behöva packa upp alla sessioner igen och manuellt rensa även om det är kostsamt och tar tid.
---
har man en massa DVD/BR-skivor redan liggande så är det bra att göra ISO-image av dessa samt köra dvdistaster för att göra ecc-filer på varje ISO-image - med sådan ecc-fil tidigare gjort och lagrad på annan media så kan man reparera även partiellt skadade och oläsbara delar på optoskivorna, default upp till ca 14% av skivans innehåll oavsett ställe - då främst DVD+R och BR-R(E) då läsarna kan läsa ut läsbara sektorer även om tex. centerdelen av skivan är oläsbar och dess TOC är borta för alltid - med ecc-filen så kan den skadade ISO-imagen som läst ut den skadade optoskivan lappas upp till helt felfrihet.
åldring av optoskivor är nästan alltid utgående från centrum och/eller utifrån yttre kanterna och dessvärre har optoskivorna heller ingen backup på någon av sina TOC eller directory-träd (bluray har numera en kopia i slutet av sessionen om man kan få till just detta vid bränningen) och dessa ligger förstås precis i början från centrum och bland det första som ryker vid en åldring eller annan skada på optiska skivan även om resten av skivan är helt läsbar...
---
en annan lösning som arbetar liknande som borgbackup med deduplicering är Duplikati med många interface mot olika monlagringstjänster och är multiplattform - dock mer tänkt som backupprogram och inte som arkiv-program även om det är med viss omsorg kan användas som arkiv ändå.
dock tycker jag denna ännu är lite för ostabil för att ha det som enda backuparkiv.
