Re: Backup ... men hvordan

[Povl Ole Haarlev Olsen <poho@stderr.dk>]

On Mon, 19 Dec 2022, Flemming Bjerke wrote:
> Den 19.12.2022 kl. 05.38 skrev Povl Ole Haarlev Olsen:
> > On Mon, 19 Dec 2022, Flemming Bjerke wrote:
> > > 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.

> > > 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.

> > > 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.

> > 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.

> 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}/ \
	>${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.

--
Povl Ole