Skip to content

Hetzner - Backupspace - Borgbackup

Linux
4 1 1.0k
  • Mein Server ist von Hetzner, dort kann man Backupspace dazu buchen, teilweise ist er auch mit drin. Dann wollen wir das mal Testen.

    Die Anleitung

    Ich hatte erst eine andere Anleitung von Hetzner, wo das mit dem Port 23 nicht drin stand. Hat dann was länger gedauert, bis es ohne Passwort ging 😉 Aber, am Ende ging es dann mit

     sftp -P 23 u123456@u123456.your-backup.de
    

    Nun kann man mittels Borgbackup Daten verschlüsselt dort ablegen.

    INIT

     borg init --encryption=repokey ssh://u123456@u123456.your-backup.de:23/./backup
     Enter new passphrase: 
     Enter same passphrase again: 
     Do you want your passphrase to be displayed for verification? [yN]: N
     
     By default repositories initialized with this version will produce security
     errors if written to with an older version (up to and including Borg 1.0.8).
     
     If you want to use these older versions, you can disable the check by running:
     borg upgrade --disable-tam ssh://u123456@u123456.your-backup.de:23/./backup
     
     See https://borgbackup.readthedocs.io/en/stable/changes.html#pre-1-0-9-manifest-spoofing-vulnerability for details about the security implications.
     
     IMPORTANT: you will need both KEY AND PASSPHRASE to access this repo!
     Use "borg key export" to export the key, optionally in printable format.
     Write down the passphrase. Store both at safe place(s).
    

    CREATE

    borg create ssh://u123456@u123456.your-backup.de:23/./backup::initial /backup
       Enter passphrase for key ssh://u123456@u123456.your-backup.de:23/./backup: 
    

    Wenn man sehen will, was passiert kann man das so machen.

    borg create --list ssh://u123456@u123456.your-backup.de:23/./backup::initial /backup
    

    Dann zeigt Borg an was er die ganze Zeit macht.

    LIST

    borg list ssh://u123456@u123456.your-backup.de:23/./backup::initial
    

    Kleine Ergänzung. Das Backup heißt vm1

     borg list ssh://u123456@u123456.your-backup.de:23/./backup/vm1
    

    Das würde jetzt alle Backups auflisten.

    Der Inhalt würde ein Backup mit dem Namen vm1-2019-09-23T09:00:02 enthalten.

    borg list ssh://u123456@u123456.your-backup.de:23/./backup/vm1::vm1-2019-09-23T09:00:02
    

    Dann zeigt Borg den Inhalt des Backups an.

    DELETE

    borg delete ssh://u123456@u123456.your-backup.de:23/./backup::initial
    

    Anleitung

    Der Link zur Anleitung von Borgbackup

    Jetzt das Ganze noch automatisieren, das alle paar Tage die Daten automatisch gesichert werden.

  • Zum Automatisieren, das Script hier nehmen.

    Das ganz anpassen und einen crontab anlegen. Fertig! Sieht dann so aus.

    root@ ~ # ./borg.sh
    
    Sat 07 Sep 2019 04:24:40 PM CEST Starting backup
    
    Creating archive at "ssh://u123456@u123456.your-backup.de:23/./backups/01::01-2019-09-07T16:24:40"
    A /backup/dump/vzdump-qemu-103-2019_09_06-00_00_30.log
    ------------------------------------------------------------------------------
    Archive name: 01-2019-09-07T16:24:40
    Archive fingerprint: f66f5a895cd7xxxxxxxxxxxxxxxxxxx6ad974aec87bd
    Time (start): Sat, 2019-09-07 16:25:22
    Time (end):   Sat, 2019-09-07 16:25:22
    Duration: 0.14 seconds
    Number of files: 72
    Utilization of max. archive size: 0%
    ------------------------------------------------------------------------------
                           Original size      Compressed size    Deduplicated size
    This archive:              109.88 GB            108.55 GB                979 B
    All archives:              616.83 GB            610.37 GB            107.94 GB
    
                           Unique chunks         Total chunks
    Chunk index:                   41509               236521
    ------------------------------------------------------------------------------
    terminating with success status, rc 0
    
    Sat 07 Sep 2019 04:25:34 PM CEST Pruning repository
    
    Keeping archive: 01-2019-09-07T16:24:40           Sat, 2019-09-07 16:25:22 [f66f5a895cd7dc8f0cecxxxxxxxxxxxxxxxxxxxxxx76ad974aec87bd]
    Pruning archive: 01-2019-09-07T16:18:34           Sat, 2019-09-07 16:18:49 [c6803a17a72d5246bxxxxxxxxxxxxxxxxxxxxxxxxxx61d80b5c9210b6a00c11b] (1/1)
    terminating with success status, rc 0
    
  • Heute noch nachgesehen, ob der cron seine Arbeit gemacht hat. War alles erfolgreich 😉 Damit ist das kleine Projekt dann erfolgreich beendet. Die VMs werden jetzt einmal die Woche auf den externen Backup-Space, verschlüsselt abgelegt.

  • Ok, da gibt es doch wohl noch ein kleines Problem 🙂

    Hetzner hat die Dienste migriert und ich war der Meinung, der Borg funktioniert nicht mehr. Ok, das hat er auch gemacht, aber der Grund wurde mir dann vom Support mitgeteilt, Der Backup Space ist voll. Huch, was läuft denn da falsch!?

    Ich konnte den Backup Space noch per SFTP erreichen, Borg gab aber immer eine merkwürdige Fehlermeldung heraus.
    Also aufpassen, wenn ihr mal Probleme habt, schaut mal nach ob ihr noch genug Platz habt 😉

    Und jetzt muss ich das Script mal ein wenig überarbeiten, irgendwas läuft da nicht so, wie ich mir das vorstelle.

  • OpenCloud - Docker Compose local

    Verschoben OpenCloud opencloud linux
    3
    1
    0 Stimmen
    3 Beiträge
    433 Aufrufe
    FrankMF
    Noch was Wichtiges. Die Docker Installation nutzt folgende config. In meinem Beispiel findet man sie unter /home/frank/opencloud/deployments/examples/opencloud_full Darin liegt ein .env ## Basic Settings ## # Define the docker compose log driver used. # Defaults to local LOG_DRIVER= # If you're on an internet facing server, comment out following line. # It skips certificate validation for various parts of OpenCloud and is # needed when self signed certificates are used. INSECURE=true ## Traefik Settings ## # Note: Traefik is always enabled and can't be disabled. # Serve Traefik dashboard. # Defaults to "false". TRAEFIK_DASHBOARD= # Domain of Traefik, where you can find the dashboard. # Defaults to "traefik.opencloud.test" TRAEFIK_DOMAIN= # Basic authentication for the traefik dashboard. # Defaults to user "admin" and password "admin" (written as: "admin:$2y$05$KDHu3xq92SPaO3G8Ybkc7edd51pPLJcG1nWk3lmlrIdANQ/B6r5pq"). # To create user:password pair, it's possible to use this command: # echo $(htpasswd -nB user) | sed -e s/\\$/\\$\\$/g TRAEFIK_BASIC_AUTH_USERS= # Email address for obtaining LetsEncrypt certificates. # Needs only be changed if this is a public facing server. TRAEFIK_ACME_MAIL= # Set to the following for testing to check the certificate process: # "https://acme-staging-v02.api.letsencrypt.org/directory" # With staging configured, there will be an SSL error in the browser. # When certificates are displayed and are emitted by # "Fake LE Intermediate X1", # the process went well and the envvar can be reset to empty to get valid certificates. TRAEFIK_ACME_CASERVER= [....gekürzt....] Man kann dort etwas ändern und mittels docker compose up -d alles aktualisieren. Radicale OpenCloud nutzt im Moment folgendes https://radicale.org/v3.html als Backend Server für Kalender & Kontakte. Jemand hat mir dann erklärt, wie das so funktioniert. Danach hatte es dann klick gemacht. https://fosstodon.org/@h4kamp/114562514701351170 In der config findet man zum Beispiel die Konfiguration für radicale (Kalender- und Kontakte-App) Das ist nur eine rudimentäre Ablage, wird gesteuert über Clienten, z.B. die Thunderbird Kalender Funktion. ### Radicale Setting ### # Radicale is a small open-source CalDAV (calendars, to-do lists) and CardDAV (contacts) server. # When enabled OpenCloud is configured as a reverse proxy for Radicale, providing all authenticated # OpenCloud users access to a Personal Calendar and Addressbook RADICALE=:radicale.yml # Docker image to use for the Radicale Container #RADICALE_DOCKER_IMAGE=opencloudeu/radicale # Docker tag to pull for the Radicale Container #RADICALE_DOCKER_TAG=latest # Define the storage location for the Radicale data. Set the path to a local path. # Ensure that the configuration and data directories are owned by the user and group with ID 1000:1000. # This matches the default user inside the container and avoids permission issues when accessing files. # Leaving it default stores data in docker internal volumes. #RADICALE_DATA_DIR=/your/local/radicale/data In einer Standard Installation ist das auskommentiert. RADICALE=:radicale.yml Danach ein docker compose up -d und Eure Kalendereinträge (extern auf einem Clienten verwaltet) werden in der OpenCloud gesichert.
  • NodeBB - v4.2.0

    NodeBB nodebb linux
    1
    0 Stimmen
    1 Beiträge
    76 Aufrufe
    Niemand hat geantwortet
  • Update 1.30.3 released

    Vaultwarden vaultwarden linux
    1
    0 Stimmen
    1 Beiträge
    146 Aufrufe
    Niemand hat geantwortet
  • Crowdsec - Ein fail2ban Ersatz?

    Linux crowdsec linux fail2ban
    2
    1
    0 Stimmen
    2 Beiträge
    980 Aufrufe
    FrankMF
    Ich kann jetzt hier von meiner ersten Erfahrung berichten und wie CrowdSec mich gebannt hat Was war passiert? Ich war gestern sehr intensiv mit der Konfiguration von Nextcloud <-> Collabora Online beschäftigt. Nachdem ich irgendwie nicht weiterkam habe ich mich der Erstellung eines Dokumentes gewidmet. Nach einiger Zeit war die Nextcloud nicht mehr erreichbar. Ok, hatte ich bei der Konfiguration auch schon mal, den Server einmal neugestartet und fertig. Doch jetzt kam es, Server neugestartet - hilft nicht. Gut, schauen wir mal nach, Der SSH Login ging auch nicht Jetzt war guter Rat gefragt. Zu diesem Zeitpunkt ging ich noch davon aus, das auf diesem Server kein CrowdSec installiert war, sondern fail2ban. Und fail2ban hatte eine sehr kurze Bantime vom 10M. Also blieb wohl nur noch das Rescue System von Hetzner. [image: 1694411392066-488866bc-3dcf-4abc-9e98-6107d65aa4c7-grafik.png] Da hatte ich ja so gut wie gar keine Erfahrung mit. Also mal kurz den Nico angetriggert und es kam folgender Link. https://docs.hetzner.com/de/robot/dedicated-server/troubleshooting/hetzner-rescue-system/ Das Laufwerk war schnell bestimmt und schnell nach /tmp gemountet. Danach musste man sich noch mit chroot in diese Umgebung anmelden. chroot-prepare /mnt chroot /mnt Nachdem das klappte, habe ich eben fail2ban disabled. sysmctl disable fail2ban Danach das Rescue beendet. Der Server startete wieder und ich kam wieder per SSH drauf. Puuh. Bei meiner ersten Kontrolle fiel mir was auf root@:~# pstree systemd─┬─2*[agetty] ├─atd ├─cron ├─crowdsec─┬─journalctl │ └─8*[{crowdsec}] ├─crowdsec-firewa───9*[{crowdsec-firewa}] Wie? Da läuft CrowdSec? Da ich dabei bin die Server auf CrowdSec umzustellen, war das wohl hier schon gemacht, aber leider nicht vernünftig. fail2ban hätte mindestens disabled werden müssen und in meiner Dokumentation war das auch nicht enthalten. 6 setzen! CrowdSec besteht ja aus zwei Diensten, CrowdSec und dem Firewall-Bouncer. Der CrowdSec Dienst lief aber nicht, der war irgendwie failed. Ok, starten wir ihn und schauen was passiert. Nachdem er gestarte war mal die Banliste angeschaut. cscli decisions list ergab diesen Eintrag. 2551501 │ crowdsec │ Ip:5.146.xxx.xxx │ crowdsecurity/http-crawl-non_statics │ ban │ │ │ 53 │ 1h5m55.391864693s │ 1671 Meine IP war gebannt. Dann wissen wir ja , woher die Probleme kamen. cscli decisions delete --id 2551501 Nach Eingabe war der Ban entfernt. Na gut, aber da ich aktuell immer noch an der richtigen Konfiguration von NC <-> CODE bastel, könnte das ja wieder passieren. Was machen? Kurz gegoogelt. Es gibt eine Whitelist. Aha! /etc/crowdsec/parsers/s02-enrich/whitelists.yaml name: crowdsecurity/whitelists description: "Whitelist events from private ipv4 addresses" whitelist: reason: "private ipv4/ipv6 ip/ranges" ip: - "127.0.0.1" - "::1" - "5.146.XXX.XXX" cidr: - "192.168.0.0/16" - "10.0.0.0/8" - "172.16.0.0/12" # expression: # - "'foo.com' in evt.Meta.source_ip.reverse" Danach den Dienst neustarten. Jetzt hoffen wir mal, das es hilft. Zum Schluss noch was, was mir aufgefallen war und was mich auch sehr verwirrt hatte. CrowdSec hatte wegen einem crowdsecurity/http-crawl-non_statics gebannt. Dadurch konnte ich meine subdomain.<DOMAIN> nicht erreichen. Ok, logisch, wenn der Ban von da ausgeht. Ich konnte aber gleichzeitig eine andere subdomain mit derselben <DOMAIN> auch nicht erreichen. Komplett verwirrte es mich dann, als ich eine andere <DOMAIN> auf dem selben Server erreichen konnte. Und zum Schluss ging auch der SSH nicht. Also, wieder viel gelernt..
  • PHP - ChatGPT

    PHP php linux chatgpt
    1
    2
    0 Stimmen
    1 Beiträge
    156 Aufrufe
    Niemand hat geantwortet
  • Debian Buster 10.6 released

    Linux debian linux
    1
    0 Stimmen
    1 Beiträge
    235 Aufrufe
    Niemand hat geantwortet
  • Kopia - APT Repository verfügbar

    Kopia kopia linux
    1
    0 Stimmen
    1 Beiträge
    237 Aufrufe
    Niemand hat geantwortet
  • nginx konfigurieren

    NodeBB nodebb nginx linux
    1
    0 Stimmen
    1 Beiträge
    660 Aufrufe
    Niemand hat geantwortet