Seite wählen

NETWAYS Blog

Why you shouldn't miss OSBConf 2018 – #2

Information is eternal, computers are ephemeral, backup is the savior. — T.E. Ronneberg
Where is OSBConf? Cologne, a 2000 year old city with Gothic architecture in a reconstructed historical center, is the fourth largest city in Germany. Everyone is invited to the Dorint Hotel An der Messe Köln, which is easily reachable by public transportation, only few minutes from the city center.
Take the opportunity to meet the Bareos community in Cologne, join interesting talks and do not miss the presentation of the next Bareos release 18.2.
2017 Maik Außendorf from the dass IT and Philipp Storz co-founder of dass IT talked about Bareos version 17.2.
Check out their talk!
 

YouTube player

Why you shouldn't miss OSBConf 2018 – #1

„If it is worth keeping, it is worth backing up.“ — T.E Ronneberg
What is OSBConf? The Open Source Backup Conference allows all backup solution researchers, practitioners and backup lovers to come together to discuss latest developments, convey strategic knowledge and present new studies.
#OSBConf 2017 – Last year Didac Oliveira from Brain updaters, talked about smart GNU/Linux Disaster Recovery management with DRLM & ReaR.
Check out his talk!

YouTube player

 

ReaR mal anders

Bereits vor ein paar Jahren habe ich einen Blogpost zur Disaster Recovery Lösung Relax-and-Recover (kurz: ReaR) geschrieben. Vor Kurzem hatte ich ein Anwendungsbeispiel, in dem ich ebenfalls auf die in vielen Fällen bewährte Lösung zugreifen wollte: Ziel war es, unsere Schulungsnotebooks auch außerhalb des Headquarters nach erfolgtem Training möglichst automatisch auch für nichttechnische Anwender auf den Auslieferungszustand zurück zu setzen. Bisher werden die Notebooks mittels Foreman jedes Mal neu provisoniert, was v.a. einiges an unnötiger Zeit frisst.
Demzufolge lag der Ansatz nahe, das mit ReaR zu lösen. Da ich auf zusätzliche Medien wie USB-Sticks verzichten wollte und das Ganze auch offline funktionieren soll, bleibt nur die lokal verbaute Platte als Speicherort für Rescueimage und Backupdateien übrig. Zudem sollte noch ein Booteintrag für die Rücksetzung erstellt werden. Die ReaR-Konfiguration in „/etc/rear/local.conf“ dazu sieht so aus:
OUTPUT=ISO
OUTPUT_URL=file:///backupshare
BACKUP=NETFS
BACKUP_URL=file:///backupshare
GRUB_RESCUE=1

Problem dabei ist, dass die Backupdateien als Archiv (backup.tar.gz) in einer der Partitionen auf der Festplatte (/dev/sdaX) liegen. Beim Wiederherstellungsvorgang löscht ReaR leider standardmäßig alle Laufwerksinformationen und erstellt diese neu, sodass die Backupdateien in dem Fall verloren gehen. Mit dem Parameter PRE_RECOVERY_SCRIPT kann man den Backupshare zumindest mounten und das Backuparchiv in das Filesystem des Rescueimages kopieren.
Ein anderer Ansatz ist die Backupdateien direkt im IOS-Image des Rescuesystems abzulegen, das geht mit folgender Konfiguration:
OUTPUT=ISO
OUTPUT_URL=file:///backupshare
BACKUP=NETFS
BACKUP_URL=iso://backup
GRUB_RESCUE=1

Auch hier zeigen sich allerdings in der Praxis Probleme. Je nach Größe der Backupdateien wächst das ISO-Image dadurch natürlich entsprechend an. Außerdem verwendet das von uns auf den Schulungsnotebooks eingesetzte Betriebssystem, CentOS 7, zum Erstellen des ISO’s in der Standardinstallation genisoimage. Hier besteht eine feste Grenze von 4GB pro Image. Diese lässt sich zwar mit ISO_MAX_SIZE bei ReaR fix konfigurieren, führt aber dazu, dass die Backupdateien im Rescueimage aufgrund des Abbruchs eben nicht vollständig enthalten sind. Indem man genisoimage gegen das nachzuinstallierende xorriso austauscht und den symbolischen Link für mkisofs anpasst, lässt sich die Begrenzung jedoch umgehen. Je nach Größe der Backupdateien macht das allerdings oft nur bedingt Sinn.
In unserem Fall hat sich gezeigt, dass ReaR für das spezielle Anwendungsszenario der lokalen Wiederherstellung von Notebooks leider nicht die ideale Wahl ist, da die Software ursprünglich für andere Anwendungszwecke konzipiert wurde. Die Suche nach der optimalen Lösung dauert daher aktuell noch an…

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

OSBConf program is online


Open Source Backup Conference | Cologne | September 26, 2018
Be part of one inspiring day full of Backup!
OSBConf provides you with all you need to know about Open Source software solutions for data backup: Best practices, success stories, technical know-how and top-level discussions. This year again we have received excellent papers from experts and researchers.  After a thorough review the program is fixed. Our selection for OSBConf 2018 includes high-level speakers such as:
Gratien D’haese (IT3 Consultants): „Relax-and-Recover Automated Testing with Bareos“
Daniel Neuberger (NETWAYS): „Restore and Backup Elasticsearch Indices“
Maik Außendorf & Philipp Storz (Bareos): „What’s new in Bareos 18“
Toshaan Bharvani (VanTosh): „Schroedingers Backup“
To see the whole conference program visit: osbconf.org/schedule
After each talk a Q&A session is scheduled. OSBConf provides an ideal opportunity for backup specialists to meet, exchange thoughts and establish new connections with fellow community members.
Register now!
Backup your seat!

osbconf.org/tickets

Einfaches verschlüsseltes Backup

Seit In­kraft­tre­ten der DSVGO  ist Datenschutz in aller Munde. Da wird es einmal Zeit auch den Datenschutz des Monitoring-Servers zu überdenken. Dabei denke ich in diesem Fall nicht an die diversen Härtungsmaßnamen wie SSL für Webserver und Datenbank. Auch Icinga2 erzwingt bei seinen API Verbindungen immer verschlüsselte Verbindungen.
Wo bleiben aber die Backup Dateien? Einmal erzeugt, verlassen sie den Server und liegen dann ‚woanders‘. Zum Glück ist es nicht unbedingt nötig, dass man dem File Server voll vertraut. Eventuell ist es günstig die Backup in irgendeine Cloud zu schieben, oder auf den semi public File Server der Unternehmens. Mit Hilfe von GPG kann man seine Daten einfach verschlüsseln und sicherstellen, dass alle Berechtigten sie auch wieder entschlüsseln können. Im folgenden wird erklärt wie man GPG benutzt um ein icinga2 Backup für eine Gruppe von Berechtigten zu verschlüsseln ohne das der private key einer Person den Monitoring Server oder den Backup Server berührt.

1.) gpg Schlüsselpaar erstellen

Am einfachsten benutzt man das CLI tool gpg um den key zu erzeugen. Das sollte man aber auf einem sicheren System machen, z.B. dem eigenen Laptop oder Arbeitsplatz PC. Anschließend wird der öffentliche Teil an einen Keyserver gesendet um den Schlüsselaustausch zu vereinfachen.

$ gpg --full-gen-key
[...]
Ihr Name ("Vorname Nachname"): Max Mustermann
Email-Adresse: max.mustermann@example.org
pub rsa2048 2018-05-31 [SC] [verfällt: 2023-05-30]
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0BA2D8D6
Max Mustermann <max.mustermann@example.org>
$ gpg --keyserver pool.sks-keyservers.net --send-key 0BA2D8D6

2.) Monitoring Server mit Schlüsseln versorgen

Auf dem Server kann man mit Hilfe der gpg group Funktion die Daten mit den public keys einer ganzen Gruppe verschlüsseln. Hierfür muss man diese Gruppe in der ~/.gnupg/gpg.conf anlegen.

$ vim .gnupg/gpg.conf +80
group icingabackup = max.mustermann@example.org john.doe@example.org

Anschließend kann man die public keys vom keyserver laden und ihnen das Vertrauen aussprechen. Nur wenn man allen Schlüsseln „absolutes Vertrauen“ ausspricht läuft der encryption Prozess ohne weitere Rückmeldungen ab.

$ gpg --keyserver pool.sks-keyservers.net --search-keys max.mustermann@example.org
gpg: suche nach "max.mustermann@example.org" auf hkp-Server pool.sks-keyservers.net
(1)  Max Mustermann (Test) <mustermann@example.org>
      4096 bit RSA key 0BA2D8D6, erzeugt: 2013-11-18
$ gpg --keyserver pool.sks-keyservers.net --recv-keys 0BA2D8D6
$ gpg --edit 0BA2D8D6 trust
  5 = Ich vertraue ihm absolut
$ gpg --keyserver pool.sks-keyservers.net --search-keys johndoe@example.org
gpg: suche nach "johndoe@example.org" auf hkp-Server pool.sks-keyservers.net
(1)  John Doe (Work email) johndoe@example.org
      4096 bit RSA key 732D8994, erzeugt: 2018-04-20, verfällt: 2020-04-19
$ gpg --keyserver pool.sks-keyservers.net --recv-keys 732D8994
$ gpg --edit 732D8994 trust
  5 = Ich vertraue ihm absolut

3.) Backup erzeugen und verschlüssen

Das kurze bash Script sammelt Dateien von icinga2 und icingaweb, erzeugt einen mysqldump, packt alles zusammen und verschlüsselt es zum Schluss. Alle Schritte sind im Script kommentiert. Bitte lesen sie unbedingt auch die Hinweise in der icinga2 Dokumentation zu diesem Thema.

#!/bin/bash
DATE=`date +%Y%m%d%H%M`
# Backup script for icinga2 and icingaweb2
# Choose which parts will be backed up.
BACKUP_ICINGA2=true
BACKUP_ICINGAWEB2=true
BACKUP_MYSQL=true
ENABLE_ENCRYPTION=true
DELETE_OLD_FILES=true
# Backup target dir
BACKUPDIR=/data/icinga2_backup
# Backup retention time. Files will be deleted after 14 days
RETENTION_TIME=14
# Icinga2 settings
ICINGA2FILES="/etc/icinga2 /var/lib/icinga2 /etc/default/icinga2"
# Icingaweb2 settings
ICINGAWEB2FILES="/etc/icingaweb2 /usr/share/icingaweb2"
HTTPD_ETCDIR="/etc/apache2"
# mysql settings
MYSQL_DATABASES="mysql icinga icingaweb director"
MYSQL_ETCDIR="/etc/mysql"
MYSQL_DUMP="$BACKUPDIR/tmp/icingaMysqlDump.sql.gz"
# encryption settings
GPG_RECIPIENT=icingabackup
# Ensure Backupdir exists
[ ! -d $BACKUPDIR ] && mkdir -p $BACKUPDIR/tmp
# Add icinga2 folders
if [ $BACKUP_ICINGA2 = true ]; then
  BACKUPFILES+=" $ICINGA2FILES"
fi
# Add icingaweb2 folders
if [ $BACKUP_ICINGAWEB2 = true ]; then
  BACKUPFILES+=" $ICINGAWEB2FILES"
  BACKUPFILES+=" $HTTPD_ETCDIR"
fi
# Add my folders and mysqldump
if [ $BACKUP_MYSQL = true ]; then
  BACKUPFILES+=" $MYSQL_ETCDIR"
  if [ ! -z "$MYSQL_DATABASES" ]; then
    mysqldump --create-options --databases ${MYSQL_DATABASES} | gzip > $MYSQL_DUMP
    BACKUPFILES+=" $MYSQL_DUMP"
  fi
fi
# make archive
TAR=$BACKUPDIR/icingaBackup_${DATE}.tar.gz
if [ ! -z "$BACKUPFILES" ]; then
  # Archive all files and delete mysqldump
  tar -czf $TAR $BACKUPFILES 2> /dev/null && [ -e $MYSQL_DUMP ] && rm $MYSQL_DUMP
fi
# encrypt archive
if [ $ENABLE_ENCRYPTION = true ]; then
  gpg --encrypt --recipient icingabackup $TAR && rm $TAR
fi
# delete everything older than 14 days
if [ $DELETE_OLD_FILES = true ]; then
  find $BACKUPDIR -mtime +$RETENTION_TIME -exec rm \{\} \;
fi

4.) Cron

Um das Backupscript jeden Tag auszuführen kopiert man es auf den Server und trägt es im crontab ein:

root@icingaMaster# crontab -e
  @daily /root/backup_icinga2.sh

5.) Decrypt

Da beim verschlüsseln alle User der Gruppe icingabackup berechtigt wurden kann jeder aus dieser Gruppe die Dateien wieder entschlüsseln.
gpg –output icinga2Backup.tar.gz –decrypt icinga2Backup.tar.gz.gpg
 

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.