Backup met restic

[Kurt DM]

Ik ben aan het experimenteren met restic na op het forum lovende woorden van Vanadium over deze software. Ik probeer nu op een externe ssd de restic repository te initialiseren met restic init en krijg volgende foutboodschap :
Fatal: create repository at /run/media/kurt/INTENSO/Restic failed: Fatal: unable to open repository at /run/media/kurt/INTENSO/Restic: mkdir /run/media/kurt/INTENSO: permission denied.

Nochtans staann de files en directories op deze ssd met mij als eigenaar. Ik heb zonder problemen eerst de /Restic directory op de ssd aangemaakt en ik kan die openen zonder probleem. Ik ben de eigenaar van de files.
Een mount commando   mount | grep /dev/sda1 geeft  /dev/sda1 on /run/media/kurt/INTENSO type ext4 (rw,nosuid,nodev,relatime,errors=remount-ro,emergency_ro,uhelper=udisks2).
Dit ziet er op het eerste zicht goed uit. Bovendien heb ik de ssd jaren gebruikt met rsynch en dat werkt perfect.

Ik wil uiteraard niet met sudo gaan werken want dat maakt root eigenaar.
Ik heb een tijdje met google gezocht (ai) maar de antwoorden zijn niet al te rechtlijnig.

Kan iemand met ervaring in restic me verder helpen?

[Kurt DM]

Ik ga zelf even antwoorden. Na een aantal keer proberen en door bij het init commando expliciet de locatie van de repository te vermelden ipv gebruik te maken van de environment variable RESTIC_REPOSITORY. Werkt het wel. Geen idee wat er gebeurd is maar OK, het werkt. De environment variable was wel degelijk correct want ik kan nu probleemloos een aantal eenvoudige commando's uitvoeren zonder expliciete vermelding van de repo. Dus so far so good.

[vanadium]

Wellicht een fout in het commando dat je hebt gebruikt, maar we kunnen dit niet nagaan. Als je hulp vraagt, is het altijd aangewezen zowel het commando als de uitvoer letterlijk in je bericht op te nemen.

[Kurt DM]

In ieder geval werkt het perfect nu Vanadium. Restic lijkt inderdaad een mooie krachtige en eenvoudig te hanteren software. Ik dacht eerst dat het niet zo goed ging voldoen aan mijn wensen omdat ik bv. graag bij een nieuwe installatie directories bijna stuk per stuk restoreer van een file manager window. Bij rsynch gebaseerde backup is dat vanzelfsprekend. Hier echter ook, je moet enkel een mountpoint creëren, na mounten in restic kan je de files zien in nautilus. Ik heb nu twee backup procedures, één gebaseerd op rsynch en één op restic. Ik ben met restic beginnen experimenteren na het lezen van jouw opmerking over deleten en direct daarna backuppen met een op rsynch gebaseerde procedure.

[vanadium]

Ik heb heel lang met grote tevredenheid gewerkt met rsync, verwerkt in een script waardoor geversioneerde backups werden gemaakt. Deduplicatie gebeurt hierbij doordat rsync voor niet gewijzigde bestanden hardlinks maakt naar bestanden die al in de vorige backup staan. Met een ander script (waar ik heel veel werk aan heb gehad) kon ik dan automatisch periodiek "opruimen": Voor backups ouder dan een week slechts één per week behouden, ouder dan een maand één per maand...

Restic heeft dat allemaal ingebouwd (en is iets sneller dan rsync).

• Geversioneerde backup (vorige backups bewaren): dat moet je echt wel hebben. Vroeger had ik voor grotere collecties zoals foto's, enz. enkel een rsync kopie, zonder oudere versies. Na een verse installatie heb ik ooit eens niet onmiddellijk mijn foto's teruggezet. Toen ik zag dat ze weg waren, waren ze ook al verdwenen in de reservekopie... (gelukkig, gelukkig, had ik nog een recente kopie elders...). Een geversioneerde backup is echt essentieel om fouten die je pas ontdekt nadat je al je backup hebt gemaakt, op te vangen.
• Deduplicatie (dezelfde informatie wordt maar één keer opgeslagen): restic is hierin nog veel krachtiger dan rsync met hard links. Deduplicatie gebeurt op basis van de inhoud van het bestand, niet op basis van de bestandsnaam, bestandsgroote en tijdsstempel. Gedeelten van bestanden die niet veranderd zijn, worden niet opnieuw opgeslagen. In de nieuwe backup wordt gelinkt naar dat stukje data dat al in een vorige backup aanwezig was.
   Voor rsync is een bestand dat werd verplaatst of werd hernoemd een nieuw bestand, zelfs al is de inhoud hetzelfde gebleven. Het wordt dus nog eens in de backup geschreven. Restic herkent daarentegen de inhoud van het verplaatste of hernoemde bestand: het blijft maar één keer in de backup aanwezig.
   Daarom is het aangewezen voor verschillende backups op dezelfde schijf met één restic repository te werken. Zo heb ik backups voor "Documenten", "Foto's", "Archief", ... Die worden aangemaakt met afzonderlijke "restic backup" commando's, die een backup maken naar hetzelfde repository. Met tags (vb. "--tag Documents") onderscheid je die backups gemakkelijk. Als ik zo oude documenten "archiveer" naar Archief, dan nemen ze geen extra plaats in in de backup.
  
• Oude backups wissen: "restic forget" zal oude backups "vergeten", volgens regels die je kan instellen, ondermeer zoals ik het voorheen met mijn script deed. "Vergeten" gaat zeer snel. Op daarna de schijfruimte ook vrij te maken, moet nog "restic prune" volgen: dan worden de niet meer gebruikte datablokken verwijderd.
  
  In restic is een backup "immutable": je kan die niet veranderen, en ook restic zal er nooit meer aankomen bij het maken van toekomstige backups, behalve dan als je "prune" uitvoert. Die actie herorganizeert het repositorie om niet gebruikte datablokken fysiek te verwijderen. Zolang er meer dan voldoende schijfruimte is, volstaat het "forget" uit te voeren. Enkel nu en dan, als "grote schoonmaak", kan je eens een "prune" gaan doen..

Mooi aan restic is ook dat het bestandsysteem er niet veel toe doet. Je zou zelfs op een vfat bestandsysteem kunnen backuppen (ik raad dat zeker niet aan) met behoud van alle eigenschappen van de oorspronkelijke bestanden. Sinds ik restic gebruik heb ik ook een backup naar de cloud: alles staat daar mooi geëncrypteerd. De backup duurt drie minuten in plaats dan 9 seconden (op SD), maar de frictie om eerst je backup schijfje uit te halen en aan te koppelen is er niet.

[Kurt DM]

Ik heb al wat rondgefietst met een aantal commando's, zeer intuïtief.

Dat restic enkel de veranderde inhoud aanpast van een file wist ik niet, en is wel heel sterk (misschien bug gevoeliger?).

Ik werk voorlopig met één repository maar alle dirs gaan in één backup commando naar één snapshot. Jij maakt dus per directory  een snapshot, duidelijk te herkennen met tags. Is het verschil tussen jouw werkwijze en alles in één snapshot dan niet enkel het vermijden van  extra hard links bij het toevoegen van een file naar bv. "Archief", of mis ik iets? Jouw werkwijze lijkt me in ieder geval overzichtelijker.

In ieder geval werk ik in de toekomst zeker met restic (zelfs deja dup doet het blijkbaar ook).

 

[erik1984]

Ja mooie software!

Zelf heb ik Restic nu een tijdje in gebruik voor backup naar cloudopslag. Voor een lokale backup naar een externe schijf gebruik ik nog Back In Time. Volgens mij doet Back In Time ongeveer hetzelfde als wat vanadium beschrijft met rsync en hardlinks.

Een tip voor Restic zijn include en exclude files. Wat ik wil backuppen staat niet binnen een map dus primair is er een selectie van mappen die ik wel wil hebben in een include file. Daarnaast heb ik in de exclude file dan een aantal mappen daarbinnen die ik niet wil dat in de backup komen. Dat kunnen ook patronen zijn. Bijvoorbeeld:

Code: [Selecteer]

node_modules
__pycache__

Ik wil wel code backuppen van mijn programmeerprojectjes (ook al is daar natuurlijk .git voor) maar niet de cachemappen daarbinnen. Mappen met deze namen binnen elke andere map in de backup worden dus niet meegenomen.

[Kurt DM]

Erik, ik gebruik inderdaad include files. Die staan in een tekstfile en worden meegenomen met restic backup --files-from="tekstfile". De repository zit in een environment variable.

[vanadium]

Ik gebruik die tags omdat ik op verschillende media van verschillende folders een backup maak. Mijn documenten en archief staan op mijn laptop, die gaan dus naar de backup op het schijfje dat ik continu meedraag, en die ik (in principe  ) dagelijks bijwerk. Op dat schijfje staat naast de backup het origineel van mijn Pictures, Music en Video. Dan heb ik nog twee schijven, één thuis en één op het werk waar alle backups naar toegaan, en onlangs heb ik daar ook de cloud aan toegevoegd.

In mijn script is gedefinieerd welke folders op welk medium moeten gebackupped worden. Het script checkt of de bestemming aanwezig is, en, indien ja, voert alle backups voor die bestemming waarvan ook de bron beschikbaar is, uit.

Wat er dus precies gebeurt als ik "bk" ingeef in de terminal, hangt af van welke harde schijven aan de laptop hangen (en de cloud is er (doorgaans) altijd).

Ik werk niet met include, maar wel gebruik ik excludes om alle Imap folders van thunderbird en alles wat *cache* is niet mee te nemen.