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