Re: Backup ... men hvordan

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--279707896-1784926012-1671454098=:16564
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

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=C3=A5 pl=
udselig=20
>>> kunne jeg ikke tilg=C3=A5 de gamle versioner ... og hvorfor ... pga. en=
 eller=20
>>> anden kendt bug som ingen havde gjort noget ved. Jeg ville aldrig turde=
=20
>>> l=C3=A6gge
>> Har du lyst til at fort=C3=A6lle hvilket program, du brugte og hvad bug'=
en var,=20
>> s=C3=A5 vi andre lettere kan checke, om vi m=C3=A5ske ogs=C3=A5 har et p=
roblem?
> Undskyld, det var CVS, og det var dengang git begyndte at blive rigtig=20
> udbredt ... alts=C3=A5 10-15 =C3=A5r siden ... s=C3=A5 det er historie, o=
g jeg husker=20
> overhovedet ikke hvad buggen gik ud p=C3=A5. Blot at den var beskrevet, o=
g at jeg=20
> ikke fandt nogen l=C3=B8sninger p=C3=A5 nettet, men derimod andre som hel=
ler ikke havde=20
> fundet nogen l=C3=B8sninger.

Interessant, is=C3=A6r fordi jeg stadig bruge CVS.

>>> min endelige backup i en krypteret fil som kun et program kan tilg=C3=
=A5, og=20
>>> hvis
>> Det lyder meget som noget hjemmerullet kryptering. Man skal selvf=C3=B8l=
gelig=20
>> bruge en eller anden standard, som nogle kloge mennesker har t=C3=A6nkt =
l=C3=A6nge=20
>> over og som findes i mere end een implementation.
> Hjemmerullet kryptering ... nej, s=C3=A5 selvovervurderende er jeg allige=
vel ikke=20
> ;-) Og, det m=C3=A5 v=C3=A6re rigtigt at hvis man skal have alt liggende =
krypteret s=C3=A5=20
> m=C3=A5 man have mindst 2 uafh=C3=A6ngige implementationer.

Jeg mente ikke n=C3=B8dvendigvis hjemmerullet af dig, men af dem, der har l=
avet=20
det een program, som kan tilg=C3=A5 backup'en.

>>> jeg mistede n=C3=B8glen ... Jeg f=C3=A5r ondt i maven ved tanken. Jeg t=
=C3=A6nker ikke at=20
>>> jeg afskaffer mine to fysiske bakop-harddiske som ikke er koblet p=C3=
=A5 min=20
>>> computer til daglig, og hvor intet er krypteret.
>> Du kunne gemme n=C3=B8glen p=C3=A5 dine to backup harddiske. Medmindre d=
u alts=C3=A5=20
>> regner med at smide alle tre kopier v=C3=A6k samtidig. Men du kan jo ogs=
=C3=A5 skrive=20
>> n=C3=B8glen p=C3=A5 et papir, som kan ligge i din bankboks. Eller 2/3 af=
 din n=C3=B8gle=20
>> til tre af dine venner, s=C3=A5 ingen af dem kan tilg=C3=A5 backup'en al=
ene. Eller...=20
>> Der er mange l=C3=B8sninger for at undg=C3=A5, at man mister sin key.
> Tak, for gode ideer.

Hvis du vil kigge n=C3=A6rmere p=C3=A5 det der med en splittet key, hvor de=
r skal X=20
dele til at lave en hel key, s=C3=A5 tag et kig p=C3=A5 "ssss" pakken.

>> Umiddelbart virker det som om du har t=C3=A6nkt dig, at lave en kopi af=
=20
>> filesystemet, hvor mariadb har sine data liggende. Hvis du g=C3=B8r det =
mens=20
>> mariadb k=C3=B8rer, skal du v=C3=A6re opm=C3=A6rksom p=C3=A5, at du m=C3=
=A5ske ikke kan bruge din=20
>> backup til noget, f.eks. fordi mariadb kan have ting cachet, som endnu i=
kke=20
>> er lagt ud i filerne eller fordi der g=C3=A5r noget tid mens du kopiere =
filerne=20
>> og de f=C3=B8rste filer derfor kan n=C3=A5 at =C3=A6ndre sig, mens du st=
adig er i gang med=20
>> at kopiere de sidste filer.
> Som beskrevet tidligere, havde jeg t=C3=A6nkt at bruge maria-backup som h=
ar alt=20
> muligt indbygget omkring at databsen k=C3=B8rer, osv. Problemet er at man=
 for hver=20
> incrementel backup selv skal lave en ny mappe hvori maria-backup kan l=C3=
=A6gge=20
> diverse filer og linke til den tidligere incrementelle mappe, som linker =
til=20
> forrige mappe, osv., osv., indtil en full-backup. Jeg kunne s=C3=A5 ikke =
finde=20
> nogle bud p=C3=A5 hvordan man p=C3=A5 nettet byggede en klog bakop af mar=
iadb p=C3=A5 det=20
> grundlag. Der er vel en trade-off mellem simpel teknisk bakop og andre he=
nsyn=20
> s=C3=A5som praktisk anvendelighed og s=C3=A5rbarhed, eksemplificeret med =
at jeg ikke=20
> lige forestiller mig at nogen ville lave en k=C3=A6de p=C3=A5 730 mapper =
med=20
> incrementel bakop af mariadb over 2 =C3=A5r. Men der tager jeg m=C3=A5ske=
 fejl?

Jeg bruger, som sagt, ikke mariadb og kender derfor ikke maria-backup, men=
=20
hvis den ikke selv underst=C3=B8tter det, s=C3=A5 lyder det som du "bare" s=
kal=20
diff'e filerne fra dagens backup med filerne fra ig=C3=A5r. De filer, der e=
r=20
ens skal s=C3=A5 bare erstattes af hardlinks til g=C3=A5rdagens backup (som=
 s=C3=A5 igen=20
kan v=C3=A6re hardlinks til dem fra i forg=C3=A5rs osv.)

Derefter kunne

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

v=C3=A6re din ven.

> Problematikken g=C3=A6lder vel generelt. V=C3=A6lger man f.eks. 2 =C3=A5r=
s =3D 730 dages=20
> incrementel bakop med rdiff-bakop? Eller hvordan g=C3=B8r I andre som jo =
er=20
> professionelle?

Ovenst=C3=A5ende rsync kommando plus lidt flere options er en del af nogle =
af=20
mine backup scripts.

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

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

BACKUP_ID=3D$1
shift

SRC_DIR=3D$1
shift

BACKUP_SERVER=3D$1
shift

DEST_DIR=3D$1
shift

BACKUP_LOG_DIR=3D/var/local/log

mkdir -p ${BACKUP_LOG_DIR}

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

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

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

rsync \
 =09-HPSavx \
 =09${LINK_DEST} \
 =09${SRC_DIR}/ \
 =09${BACKUP_SERVER}:${DEST_DIR}/${TIMESTAMP}/ \
 =09>${BACKUP_LOG_DIR}/${BACKUP_ID}.${TIMESTAMP}.log 2>&1

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

Ovenst=C3=A5ende foruds=C3=A6tter at den, der k=C3=B8rer scriptet (root?) h=
ar en ssh-key,=20
der kan logge ind p=C3=A5 ${BACKUP_SERVER} uden password.

Sp=C3=B8rg gerne, hvis der er noget i scriptet, du er i tvivl om.

--=20
Povl Ole
--279707896-1784926012-1671454098=:16564--