Re: Backup ... men hvordan

This is a multi-part message in MIME format.
--------------000pAhWBw9uni7UdmR1y2t3B
Content-Type: multipart/alternative;
 boundary="------------z4a5wGvMmPnc8P44G0ZOYZXO"

--------------z4a5wGvMmPnc8P44G0ZOYZXO
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Jeg synes at restic ser godt ud.

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 min endelige backup i en krypteret fil som kun et 
program kan tilgå, og hvis 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.

Men jeg synes restic ser ud til at være det rigtige til at cron-job 
bakke op i skyen. En Hetzner-storage-box på 1 TB til 3,81€ /md med 
restic-bakop, er da et meget interessant alternativ til alle mulige 
internationale tjenester som næppe fortjener så lige megen tillid som 
restic-udviklerne (og som NSA har adgang til pga. DMCA). Mange tak, for 
den løsning! Og hvad jeg rigtig godt kan lide: Bakop hos Hetzner og 
web/mail-server hos Contabo. Og mail-webserveren smides også lige hjem 
til min raspberry pie! Mine egentlige arbejdsdata kan så med cron-job 
ryge til Hetzner krypteret - og ukrypteret til mine to harddisk.

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.

Bedste hilsener

Flemming



Den 17.12.2022 kl. 14.05 skrev 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
>
>
>
> 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


--------------z4a5wGvMmPnc8P44G0ZOYZXO
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Jeg synes at restic ser godt ud. <br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">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 min
      endelige backup i en krypteret fil som kun et program kan tilgå,
      og hvis 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. <br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Men jeg synes restic ser ud til at være
      det rigtige til at cron-job bakke op i skyen. En
      Hetzner-storage-box på 1 TB til 3,81€ /md med restic-bakop, er da
      et meget interessant alternativ til alle mulige internationale
      tjenester som næppe fortjener så lige megen tillid som
      restic-udviklerne (og som NSA har adgang til pga. DMCA). Mange
      tak, for den løsning! Og hvad jeg rigtig godt kan lide: Bakop hos
      Hetzner og web/mail-server hos Contabo. Og mail-webserveren smides
      også lige hjem til min raspberry pie! Mine egentlige arbejdsdata
      kan så med cron-job ryge til Hetzner krypteret - og ukrypteret til
      mine to harddisk.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Men det løser ikke mit problem med
      hvordan man bakker mariadb op. Hvad synes I om følgende løsning?</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">1. Hvert kvartal full backup. Slettes
      efter 5/4 år.</div>
    <div class="moz-cite-prefix">2. Hver måned incrementel bakop ift.
      seneste kvartals full backup. Slettes efter et år.<br>
    </div>
    <div class="moz-cite-prefix">3. Hver uge incrementel bakop ift.
      seneste kvartals full backup, slettes efter 1½ måned.</div>
    <div class="moz-cite-prefix">4. Daglig incrementel bakup i forhold
      til seneste kvartals full backup. Slettes efter 10 dage.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Grundlaget skulle være et lille simpelt
      skript i stil med vedhæftede.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Bedste hilsener</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Flemming<br>
    </div>
    <div class="moz-cite-prefix"> <br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Den 17.12.2022 kl. 14.05 skrev Thomas
      Damgaard:<br>
    </div>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Hej Flemming,</p>
      <p><br>
      </p>
      <p>Jeg bruger restic (<a class="moz-txt-link-freetext"
          href="https://restic.net/" moz-do-not-send="true">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:[email protected]">
        <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>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>

--------------z4a5wGvMmPnc8P44G0ZOYZXO--
--------------000pAhWBw9uni7UdmR1y2t3B
Content-Type: application/x-shellscript; name="bakop-map.sh"
Content-Disposition: attachment; filename="bakop-map.sh"
Content-Transfer-Encoding: base64

IyEvYmluL2Jhc2gKI3BhdGggdG8gYmFja2RpciB3aXRoIHRyYWlsaW5nIC8KaWYgWyAteiAi
JDEiIF07CnRoZW4KICBlY2hvICJTeW50YXggaXMgbGlrZTogYmFrb3AtbWFwIC92YXIvYmFj
a3VwL215c3FsLyBlbmNyIDYiCiAgZWNobyAtZSAiVGhlIGFyZ3VtZW50cyBhcmU6IFxuIDEu
IHBhdGggdG8gYmFja3VwIGRpciB3aXRoIHRyYWlsaW5nIC9cbiAyLiBuYW1lIG9mIGJhY2t1
cCBkaXIgXG4gMy4gSG93IG1hbnkgc3RlcHMgYmVmb3JlIHNob3VsZCBhIGRpciBiZSByZW1v
dmVkIgogIGV4aXQKZmkKcGQ9JDEKI2dlbmVyaWMgbmFtZSBvZiBiYWNrdXAtZGlyCmJkPSQy
CiNob3cgbWFueSBzdGVwcyBiZWZvcmUgc2hvdWxkIGEgZGlyIGJlIHJlbW92ZWQKcm1vbGRk
PSQzCnBkPSRwZCRiZApjbnQ9YGNhdCAkMWNudC50eHRgCmdsZGlyPSRwZC0kY250CmVjaG8g
IlRoaXMgaXMgbGFzdCBkaXI6ICRnbGRpciIKbmNudD0kKChjbnQrMSkpCmVjaG8gJG5jbnQg
PiAkMWNudC50eHQKbmRpcj0kcGQtJG5jbnQKZWNobyAiVGhpcyBpcyB0aGUgbmV3IGRpcmV0
b3J5OiAkbmRpciIKcm0gLWZyICRuZGlyCm1rZGlyICRuZGlyCnJtb2xkPSQoKGNudC1ybW9s
ZGQpKQpyZGlyPSRwZC0kcm1vbGQKZWNobyAiVGhpcyBkaXIgaXMgcmVtb3ZlZDogJHJkaXIi
CnJtIC1mciAkcmRpcgoK

--------------000pAhWBw9uni7UdmR1y2t3B--