• Backup ... men hvordan

    From Flemming Bjerke@21:1/5 to All on Sat Dec 17 08:30:01 2022
    This is a multi-part message in MIME format.
    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.

    <html>
    <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p><font size="4">Kære Alle</font></p>
    <p><font size="4">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.</font></p>
    <p><font size="4">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.</font></p>
    <p><font size="4">Hvad gør I?</font></p>
    <p><font size="4">Flemming</font></p>
    <p><font size="4">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.  <br>
    </font></p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Damgaard@21:1/5 to Flemming Bjerke on Sat Dec 17 14:10:01 2022
    This is a multi-part message in MIME format.
    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



    On 2022-12-17 08:16, Flemming Bjerke wrote:

    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.

    --
    Mvh
    Thomas

    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p>Hej Flemming,</p>
    <p><br>
    </p>
    <p>Jeg bruger restic (<a class="moz-txt-link-freetext" href="https://restic.net/">https://restic.net/</a>)</p>
    <p>Du kan apt install'e det, men du kan også hente den seneste
    statiske binary fra github.</p>
    <p>Restic er backup "gjort rigtigt".</p>
    <p>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).</p>
    <p>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.<br>
    </p>
    <p>Mvh</p>
    <p>Thomas</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2022-12-17 08:16, Flemming Bjerke
    wrote:<br>
    </div>
    <blockquote type="cite"
    cite="mid:4f60e584-842b-de3f-b452-64920bbfd40e@bjerke.dk">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <p><font size="4">Kære Alle</font></p>
    <p><font size="4">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.</font></p>
    <p><font size="4">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.</font></p>
    <p><font size="4">Hvad gør I?</font></p>
    <p><font size="4">Flemming</font></p>
    <p><font size="4">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.  <br>
    </font></p>
    </blockquote>
    <pre class="moz-signature" cols="72">--
    Mvh
    Thomas</pre>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Povl Ole Haarlev Olsen@21:1/5 to Flemming Bjerke on Mon Dec 19 06:10:01 2022
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    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?

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

    --
    Povl Ole

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Flemming Bjerke@21:1/5 to All on Mon Dec 19 11:20:01 2022
    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.



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Povl Ole Haarlev Olsen@21:1/5 to Flemming Bjerke on Mon Dec 19 14:30:01 2022
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Flemming Bjerke@21:1/5 to All on Mon Dec 19 16:40:02 2022
    This is a multi-part message in MIME format.
    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


    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <div class="moz-cite-prefix">Mange tak, for tips som jeg benytter.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Maria-backup er ret simpel at bruge:</div>
    <div class="moz-cite-prefix">
    <p>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:</p>
    <pre class="fixed">$ mariabackup --backup \
    --target-dir=/var/mariadb/inc2/ \
    --incremental-basedir=/var/mariadb/inc1/
    <a class="moz-txt-link-freetext" href="https://mariadb.com/kb/en/incremental-backup-and-restore-with-mariabackup/">https://mariadb.com/kb/en/incremental-backup-and-restore-with-mariabackup/</a>

    </pre>
    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.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">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?<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">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.  </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Flemming <br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <br>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Povl Ole Haarlev Olsen@21:1/5 to Flemming Bjerke on Mon Dec 19 18:00:02 2022
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    On Mon, 19 Dec 2022, Flemming Bjerke wrote:
    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?

    --
    Povl Ole

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)