Backup ... men hvordan

[Flemming Bjerke]

KÊre Alle

Hvordan bakker i op? Tidligere har jeg bakket op med rsync skripts. Men
nu har jeg tÊnkt mig at bruge rdiff-backup og mariabackup. Det er sådan
set nemt nok. Bortset fra at mariabackup får en til at tÊnke over hvad
man skal med f.eks. 2 års backup bestående af 730 mapper der alle linker
tilbage til den forrige incrementelle backup og til sidst til den
oprindelige full backup - og det forkommer også at vÊre en ret sårbar
backup. Et lignende problem er der vel også med rdiff-backup.

Nu er jeg nok ikke den fÞrste der har tÊnkt på dette ;-) Alligevel har
jeg ledt forgÊves efter relevante skrifts o. lign. på nettet.

Hvad gÞr I?

Flemming

PS: Jeg er indtil videre tilfreds med contabo.com: 60 kr/md for 300 MB
debian 11 VPS med ganske meget ram og cpu. Supporten er ret hjÊlpsom, og
jeg har ikke noget at udsÊtte på den. Jeg havde dog et seriÞst problem.
Jeg havde lÞbende lavet bakop af /etc, og da noget var gået galt, ville
jeg lige gå et par dage tilbage, og så purgede jeg relevante
programpakker. Og så slettede jeg lige (med hovedet under armen) /etc og
erstattede den med en 2 dage gammel /etc. Det skulle jeg ikke have
gjort, for så kunne jeg ikke genstarte. Det var noget med at
boot-processen ikke kunne finde min virtuelle harddisk. Jeg (gennem VNC)
og supporten prÞvede at forklare fstab at den skulle bare bruge min
virtuelle harddisk, men det ville den ikke hÞre tale om. Det syntes
hurtigt lettere at starte forfra og resette debian. Og jeg vidste jo
faktisk godt at jeg netop ikke kunne regne med at bare kunne kopiere
hele en gammel version af /etc.

[Thomas Damgaard]

Hej Flemming,


Jeg bruger restic (https://restic.net/)

Du kan apt install'e det, men du kan også hente den seneste statiske
binary fra github.

Restic er backup "gjort rigtigt".

Selve backuppen er krypteret, repository'et sÞrger for deduplication,
det understÞtter et hav af protokoller (sÊrligt hvis du kombinerer det
med rclone).

Ift. selve storage-delen, så bruger jeg selv en fysisk server jeg har
co-located i et datacenter. Men du kan leje forholdsvist billige storage
boxe, hvis du har brug for meget plads. F.eks. hos Hetzner. Jeg har også
en enkelt maskine som faktisk bruger Mega som storage backend til
restic. Det fungerer også fint nok.

Mvh

Thomas

Post by Flemming Bjerke
KÊre Alle
Hvordan bakker i op? Tidligere har jeg bakket op med rsync skripts.
Men nu har jeg tÊnkt mig at bruge rdiff-backup og mariabackup. Det er
sådan set nemt nok. Bortset fra at mariabackup får en til at tÊnke
over hvad man skal med f.eks. 2 års backup bestående af 730 mapper der
alle linker tilbage til den forrige incrementelle backup og til sidst
til den oprindelige full backup - og det forkommer også at vÊre en ret
sårbar backup. Et lignende problem er der vel også med rdiff-backup.
Nu er jeg nok ikke den fÞrste der har tÊnkt på dette ;-) Alligevel har
jeg ledt forgÊves efter relevante skrifts o. lign. på nettet.
Hvad gÞr I?
Flemming
PS: Jeg er indtil videre tilfreds med contabo.com: 60 kr/md for 300 MB
debian 11 VPS med ganske meget ram og cpu. Supporten er ret hjÊlpsom,
og jeg har ikke noget at udsÊtte på den. Jeg havde dog et seriÞst
problem. Jeg havde lÞbende lavet bakop af /etc, og da noget var gået
galt, ville jeg lige gå et par dage tilbage, og så purgede jeg
relevante programpakker. Og så slettede jeg lige (med hovedet under
armen) /etc og erstattede den med en 2 dage gammel /etc. Det skulle
jeg ikke have gjort, for så kunne jeg ikke genstarte. Det var noget
med at boot-processen ikke kunne finde min virtuelle harddisk. Jeg
(gennem VNC) og supporten prÞvede at forklare fstab at den skulle bare
bruge min virtuelle harddisk, men det ville den ikke hÞre tale om. Det
syntes hurtigt lettere at starte forfra og resette debian. Og jeg
vidste jo faktisk godt at jeg netop ikke kunne regne med at bare kunne
kopiere hele en gammel version af /etc.

[Povl Ole Haarlev Olsen]

Men jeg glemmer aldrig da jeg havde brugt srv til backup, og så pludselig
kunne jeg ikke tilgå de gamle versioner ... og hvorfor ... pga. en eller
anden kendt bug som ingen havde gjort noget ved. Jeg ville aldrig turde lÊgge

Har du lyst til at fortÊlle hvilket program, du brugte og hvad bug'en var,
så vi andre lettere kan checke, om vi måske også har et problem?

min endelige backup i en krypteret fil som kun et program kan tilgå, og hvis

Det lyder meget som noget hjemmerullet kryptering. Man skal selvfÞlgelig
bruge en eller anden standard, som nogle kloge mennesker har tÊnkt lÊnge
over og som findes i mere end een implementation.

jeg mistede nÞglen ... Jeg får ondt i maven ved tanken. Jeg tÊnker ikke at
jeg afskaffer mine to fysiske bakop-harddiske som ikke er koblet på min
computer til daglig, og hvor intet er krypteret.

Du kunne gemme nÞglen på dine to backup harddiske. Medmindre du altså
regner med at smide alle tre kopier vÊk samtidig. Men du kan jo også
skrive nÞglen på et papir, som kan ligge i din bankboks. Eller 2/3 af din
nÞgle til tre af dine venner, så ingen af dem kan tilgå backup'en alene.
Eller... Der er mange lÞsninger for at undgå, at man mister sin key.

Men det lÞser ikke mit problem med hvordan man bakker mariadb op. Hvad synes
I om fÞlgende lÞsning?
1. Hvert kvartal full backup. Slettes efter 5/4 år.
2. Hver måned incrementel bakop ift. seneste kvartals full backup. Slettes
efter et år.
3. Hver uge incrementel bakop ift. seneste kvartals full backup, slettes
efter 1œ måned.
4. Daglig incrementel bakup i forhold til seneste kvartals full backup.
Slettes efter 10 dage.
Grundlaget skulle vÊre et lille simpelt skript i stil med vedhÊftede.

Umiddelbart virker det som om du har tÊnkt dig, at lave en kopi af
filesystemet, hvor mariadb har sine data liggende. Hvis du gÞr det mens
mariadb kÞrer, skal du vÊre opmÊrksom på, at du måske ikke kan bruge din
backup til noget, f.eks. fordi mariadb kan have ting cachet, som endnu
ikke er lagt ud i filerne eller fordi der går noget tid mens du kopiere
filerne og de fÞrste filer derfor kan nå at Êndre sig, mens du stadig er i
gang med at kopiere de sidste filer.

Jeg bruger ikke selv mariadb, men i f.eks. postgresql er der et tool til
at lave backups af en database, der er i aktiv brug. Jeg regner med, at
mariadb har et tool i samme stil. Det tool vil dog lave en full backup af
din database, ikke incremental.

TL;DR: Enten stopper du databasen hverken du laver en backup eller du
laver en fuld backup hver gang. Eller du har en måske ubrugelig backup...

[Flemming Bjerke]

Men jeg glemmer aldrig da jeg havde brugt srv til backup, og så
pludselig kunne jeg ikke tilgå de gamle versioner ... og hvorfor ...
pga. en eller anden kendt bug som ingen havde gjort noget ved. Jeg
ville aldrig turde lægge

Har du lyst til at fortælle hvilket program, du brugte og hvad bug'en
var, så vi andre lettere kan checke, om vi måske også har et problem?

Undskyld, det var CVS, og det var dengang git begyndte at blive rigtig
udbredt ... altså 10-15 år siden ... så det er historie, og jeg husker
overhovedet ikke hvad buggen gik ud på. Blot at den var beskrevet, og at
jeg ikke fandt nogen løsninger på nettet, men derimod andre som heller
ikke havde fundet nogen løsninger.

min endelige backup i en krypteret fil som kun et program kan tilgå,
og hvis

Det lyder meget som noget hjemmerullet kryptering. Man skal
selvfølgelig bruge en eller anden standard, som nogle kloge mennesker
har tænkt længe over og som findes i mere end een implementation.

Hjemmerullet kryptering ... nej, så selvovervurderende er jeg alligevel
ikke ;-) Og, det må være rigtigt at hvis man skal have alt liggende
krypteret så må man have mindst 2 uafhængige implementationer.

jeg mistede nøglen ... Jeg får ondt i maven ved tanken. Jeg tænker
ikke at jeg afskaffer mine to fysiske bakop-harddiske som ikke er
koblet på min computer til daglig, og hvor intet er krypteret.

Du kunne gemme nøglen på dine to backup harddiske. Medmindre du altså
regner med at smide alle tre kopier væk samtidig. Men du kan jo også
skrive nøglen på et papir, som kan ligge i din bankboks. Eller 2/3 af
din nøgle til tre af dine venner, så ingen af dem kan tilgå backup'en
alene. Eller... Der er mange løsninger for at undgå, at man mister sin
key.

Tak, for gode ideer.

Men det løser ikke mit problem med hvordan man bakker mariadb op.
Hvad synes I om følgende løsning?
1. Hvert kvartal full backup. Slettes efter 5/4 år.
2. Hver måned incrementel bakop ift. seneste kvartals full backup.
Slettes efter et år.
3. Hver uge incrementel bakop ift. seneste kvartals full backup,
slettes efter 1½ måned.
4. Daglig incrementel bakup i forhold til seneste kvartals full
backup. Slettes efter 10 dage.
Grundlaget skulle være et lille simpelt skript i stil med vedhæftede.

Umiddelbart virker det som om du har tænkt dig, at lave en kopi af
filesystemet, hvor mariadb har sine data liggende. Hvis du gør det
mens mariadb kører, skal du være opmærksom på, at du måske ikke kan
bruge din backup til noget, f.eks. fordi mariadb kan have ting cachet,
som endnu ikke er lagt ud i filerne eller fordi der går noget tid mens
du kopiere filerne og de første filer derfor kan nå at ændre sig, mens
du stadig er i gang med at kopiere de sidste filer.

Som beskrevet tidligere, havde jeg tænkt at bruge maria-backup som har
alt muligt indbygget omkring at databsen kører, osv. Problemet er at man
for hver incrementel backup selv skal lave en ny mappe hvori
maria-backup kan lægge diverse filer og linke til den tidligere
incrementelle mappe, som linker til forrige mappe, osv., osv., indtil en
full-backup. Jeg kunne så ikke finde nogle bud på hvordan man på nettet
byggede en klog bakop af mariadb på det grundlag. Der er vel en
trade-off mellem simpel teknisk bakop og andre hensyn såsom praktisk
anvendelighed og sårbarhed, eksemplificeret med at jeg ikke lige
forestiller mig at nogen ville lave en kæde på 730 mapper med
incrementel bakop af mariadb over 2 år. Men der tager jeg måske fejl?

Problematikken har jo helt konkret relevans. Jeg lavede en gang en
wordpress-hjemmeside sammen med nogle andre. Men siden blev cracket, og
det havde den faktisk været i mere end 14 dage før vi opdagede det.
Webhotellet (som en af de andre insisterede på var supergode til at
bakke op) havde desværre kun 14 dages bakop liggende. (Jeg undrede mig
over hvorfor der ikke en månedlig bakop, f.eks. bare 3 måneder tilbage.)
Nu var det nogle fjolser der havde cracket siden, så jeg løste problemet
uden det helt store bøvl ... men det var jo bare heldigt. Så vidt jeg
har bemærket, er det ikke ualmindeligt at webhoteludbydere tilbyder
bakop som i virkeligheden kun er få dages bakop.

Problematikken gælder vel generelt. Vælger man f.eks. 2 års = 730 dages
incrementel bakop med rdiff-bakop? Eller hvordan gør I andre som jo er
professionelle?

Flemming

[Povl Ole Haarlev Olsen]

Post by Flemming Bjerke

Post by Povl Ole Haarlev Olsen

Men jeg glemmer aldrig da jeg havde brugt srv til backup, og så pludselig
kunne jeg ikke tilgå de gamle versioner ... og hvorfor ... pga. en eller
anden kendt bug som ingen havde gjort noget ved. Jeg ville aldrig turde lÊgge

Har du lyst til at fortÊlle hvilket program, du brugte og hvad bug'en var,
så vi andre lettere kan checke, om vi måske også har et problem?

Undskyld, det var CVS, og det var dengang git begyndte at blive rigtig
udbredt ... altså 10-15 år siden ... så det er historie, og jeg husker
overhovedet ikke hvad buggen gik ud på. Blot at den var beskrevet, og at jeg
ikke fandt nogen lÞsninger på nettet, men derimod andre som heller ikke havde
fundet nogen lÞsninger.

Interessant, isÊr fordi jeg stadig bruge CVS.

Post by Flemming Bjerke

Post by Povl Ole Haarlev Olsen

min endelige backup i en krypteret fil som kun et program kan tilgå, og hvis

Det lyder meget som noget hjemmerullet kryptering. Man skal selvfÞlgelig
bruge en eller anden standard, som nogle kloge mennesker har tÊnkt lÊnge
over og som findes i mere end een implementation.

Hjemmerullet kryptering ... nej, så selvovervurderende er jeg alligevel ikke
;-) Og, det må vÊre rigtigt at hvis man skal have alt liggende krypteret så
må man have mindst 2 uafhÊngige implementationer.

Jeg mente ikke nÞdvendigvis hjemmerullet af dig, men af dem, der har lavet
det een program, som kan tilgå backup'en.

Post by Flemming Bjerke

Post by Povl Ole Haarlev Olsen

jeg mistede nÞglen ... Jeg får ondt i maven ved tanken. Jeg tÊnker ikke at
jeg afskaffer mine to fysiske bakop-harddiske som ikke er koblet på min
computer til daglig, og hvor intet er krypteret.

Du kunne gemme nÞglen på dine to backup harddiske. Medmindre du altså
regner med at smide alle tre kopier vÊk samtidig. Men du kan jo også skrive
nÞglen på et papir, som kan ligge i din bankboks. Eller 2/3 af din nÞgle
til tre af dine venner, så ingen af dem kan tilgå backup'en alene. Eller...
Der er mange lÞsninger for at undgå, at man mister sin key.

Tak, for gode ideer.

Hvis du vil kigge nÊrmere på det der med en splittet key, hvor der skal X
dele til at lave en hel key, så tag et kig på "ssss" pakken.

Post by Flemming Bjerke

Post by Povl Ole Haarlev Olsen
Umiddelbart virker det som om du har tÊnkt dig, at lave en kopi af
filesystemet, hvor mariadb har sine data liggende. Hvis du gÞr det mens
mariadb kÞrer, skal du vÊre opmÊrksom på, at du måske ikke kan bruge din
backup til noget, f.eks. fordi mariadb kan have ting cachet, som endnu ikke
er lagt ud i filerne eller fordi der går noget tid mens du kopiere filerne
og de fÞrste filer derfor kan nå at Êndre sig, mens du stadig er i gang med
at kopiere de sidste filer.

Som beskrevet tidligere, havde jeg tÊnkt at bruge maria-backup som har alt
muligt indbygget omkring at databsen kÞrer, osv. Problemet er at man for hver
incrementel backup selv skal lave en ny mappe hvori maria-backup kan lÊgge
diverse filer og linke til den tidligere incrementelle mappe, som linker til
forrige mappe, osv., osv., indtil en full-backup. Jeg kunne så ikke finde
nogle bud på hvordan man på nettet byggede en klog bakop af mariadb på det
grundlag. Der er vel en trade-off mellem simpel teknisk bakop og andre hensyn
såsom praktisk anvendelighed og sårbarhed, eksemplificeret med at jeg ikke
lige forestiller mig at nogen ville lave en kÊde på 730 mapper med
incrementel bakop af mariadb over 2 år. Men der tager jeg måske fejl?

Jeg bruger, som sagt, ikke mariadb og kender derfor ikke maria-backup, men
hvis den ikke selv understÞtter det, så lyder det som du "bare" skal
diff'e filerne fra dagens backup med filerne fra igår. De filer, der er
ens skal så bare erstattes af hardlinks til gårdagens backup (som så igen
kan vÊre hardlinks til dem fra i forgårs osv.)

Derefter kunne

rsync -H --link-dest ${LAST_TIMESTAMP} ...

vÊre din ven.

Post by Flemming Bjerke
Problematikken gÊlder vel generelt. VÊlger man f.eks. 2 års = 730 dages
incrementel bakop med rdiff-bakop? Eller hvordan gÞr I andre som jo er
professionelle?

Ovenstående rsync kommando plus lidt flere options er en del af nogle af
mine backup scripts.

Den korte version af de scripts er noget a'la:

[- Quote -]
TIMESTAMP=$(date -u +%Y-%m-%d-T-%H-%M)

BACKUP_ID=$1
shift

SRC_DIR=$1
shift

BACKUP_SERVER=$1
shift

DEST_DIR=$1
shift

BACKUP_LOG_DIR=/var/local/log

mkdir -p ${BACKUP_LOG_DIR}

LAST_TIMESTAMP_FILE=${BACKUP_LOG_DIR}/${BACKUP_ID}.timestamp

if [ -e ${LAST_TIMESTAMP_FILE} ]
then
LAST_TIMESTAMP=$(cat ${LAST_TIMESTAMP_FILE})

LINK_DEST="--link-dest ${DEST_DIR}/${LAST_TIMESTAMP}"
fi

rsync \
-HPSavx \
${LINK_DEST} \
${SRC_DIR}/ \
${BACKUP_SERVER}:${DEST_DIR}/${TIMESTAMP}/ \

Post by Flemming Bjerke
${BACKUP_LOG_DIR}/${BACKUP_ID}.${TIMESTAMP}.log 2>&1

echo ${TIMESTAMP} > ${LAST_TIMESTAMP_FILE}
[- End quote -]

Ovenstående forudsÊtter at den, der kÞrer scriptet (root?) har en ssh-key,
der kan logge ind på ${BACKUP_SERVER} uden password.

SpÞrg gerne, hvis der er noget i scriptet, du er i tvivl om.

[Flemming Bjerke]

Mange tak, for tips som jeg benytter.

Maria-backup er ret simpel at bruge:

To perform additional incremental backups, you can then use the target
directory of the previous incremental backup as the incremental base
directory of the next incremental backup. For example:

$ mariabackup --backup \
--target-dir=/var/mariadb/inc2/ \
--incremental-basedir=/var/mariadb/inc1/
https://mariadb.com/kb/en/incremental-backup-and-restore-with-mariabackup/

Man skal bare have lavet mappen 'inc2' fÞrst, og det jo ikke
raketvidenskab med cronjob at lave sådan en incrementel kÊde af mapper
som maria-backup lÞbende hÊlder filer i.

Mit spÞrgsmål var i virkeligheden: Hvor lÊnge gemmer I backups, efter
hvilket skema? Og hvor tit laver I full backup, og hvor tit incrementel?

Jeg kan iÞvrigt ikke forestille mig at CVS-problemet ville opstå i
dag(?) Jeg mindes det vist var forholdsvis sjÊldent problemet opstod,
men det var til gengÊld ÞdelÊggende - og jeg opgav derfor CVS.

Flemming

[Povl Ole Haarlev Olsen]

Mit spÞrgsmål var i virkeligheden: Hvor lÊnge gemmer I backups, efter hvilket
skema? Og hvor tit laver I full backup, og hvor tit incrementel?

Det kommer nok helt an på hvad det er for nogle data og hvilke regler, man
er underlagt.

Er der ikke noget med, at firmaer skal gemme nogle regneskabsdata 5 eller
10 år tilbage?

Af nogle filesystems på nogle af mine maskiner, laver jeg en daglig backup
med mit backup script. Af /home på nogle af mine maskiner, laver jeg en
backup hver time. Jeg bruger rsync --link-dest, så jeg ved ikke helt om du
vil kalde det en full backup eller incremental. Hver backup dir har alle
data fra det givne tidspunkt, men pladsen per backup dir (undtagen den
fÞrste backup) svarer til en incremental backup.

Det er forskelligt hvor lÊnge jeg gemmer data. Filesystemer, der nÊsten
ikke Êndrer sig, koster ikke ret meget mere plads, når hver backup er med
--link-dest til forrige backup, så der kan jeg uden store problemer have
backups liggende i et år eller mere. Mere aktive filesystemer, hvor filer
tit Êndrer sig eller bliver flyttet, koster lidt mere plads, så det er
svÊrere at retfÊrdigÞre pladsforbruget.

Som et par modspÞrgsmål til dit spÞrgsmål er:

Hvilken type data?

Er der sÊrlig regler for de data, som du skal overholde?

Hvor tit er der nye/Êndrede data?

Hvor meget/lidt plads vil du bruge?