Beiträge zu “restic”
Freenas: restic Repositories mit FUSE mounten
Ich möchte auf FreeNAS 12 ein restic Backup Repository mounten.
Dazu musste ich auf meinem System zuerst die Einstellungen des Packetsystem wie hier beschrieben anpassen:
more /usr/local/etc/pkg/repos/local.conf
local: {
url: "file:///usr/ports/packages",
enabled: no
}
more /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: {
enabled: yes
}
Dann konnte Ich FUSE installieren und laden
pkg update
pkg install fuse
kldload fuse
(Es kann sein das dies wegen des schreibgeschützten Bootmediums nach einem Neustart wieder gemacht werden muss. Da dies aber eine Aktion ist die ich nicht so häufig brauche kann ich damit leben)
Jetzt kann man wie hier dokumentiert das Backup mounten. Da ich bei mir die notwendigen Paramenter für restic in einer Umgebungsvariable speichere geht das dann einfach
mkdir /mnt/restic
$RESTIC_CMD unlock
$RESTIC_CMD mount /mnt/restic/
$RESTIC_CMD mount /mnt/restic
repository 9a7af58f opened successfully, password is correct
Now serving the repository at /mnt/restic
und man kann schön durch das Verzeichnis laufen und die gewünschten Dateien kopieren.
Restic @CERN
Ich bin weiterhin zufrieden restic als Backupsystem.
Für alle die sich fragen ob das Werkzeug auch für einen grösseren Datenbestand verwendet werden könnte hier ein Testbericht aus dem CERN
Tomorrow at Ceph Day at CERN I will do a short re-cap of the current status of this project, which is still very promising and growing (14,5k users now, 35M files processed per day, 270T of combined backup repositories). I have a slide only for restic and i will try to spread the word about all its beautifulness!
Crontab Fehler unter FreeBSD/NAS4Free
Mein restic Backup Script besteht aus zwei Hauptkomponenten. Zum einen natürlich restic und zum anderen aus einem Reporting über healthchecks.io/ Das Script läuft mehr oder weniger gleich auf meinen Debian/MAC und NAS4Free (FreeBSD) Plattformen.
Auf der letztgenannten Plattform gab es allerdings ein Problem. Wenn ich das Script manuell aufgerufen hatte lief es wunderbar. Wenn es über Cron gestartet wurde gab es kein erfolgreiches Reporting auf Healthcheck.io. Und das obwohl das Script lief wie man unter htop schön sehen konnte.
Durch diesen Beitrag bin ich auf die Idee gekommen das es vielleicht am Pfad liegen könnte der unter Cron wohl etwas restriktiver ist als bei einem manuellen Aufruf. Also habe ich in dem Script den Pfad eingetragen den das Script bei einem Aufruf unter Cron bekommt
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
und siehe da
/mnt/FirstPool/backups/restic-backup.sh: line 41: curl: command not found
curl wurde auf meiner NAS4Free Box nachinstalliert. Wenn ich dann den direkten Pfad auf Curl eingetragen hatte lief das Script auch unter Cron
Restic: Is there a repository at the following location?
Ich wollte in einem Restic Repository die vorhandenen Snapshots prüfen und habe die genannte Fehlermeldung bekommen
/usr/bin/restic -r $RESTIC_REPOSITORY -p $RESTIC_PASSWORD_FILE snapshots
unable to open config file: Stat: Get http://169.254.169.254/latest/meta-data/iam/security-credentials: dial tcp 169.254.169.254:80: i/o timeout
Is there a repository at the following location?
s3:https://s3.amazonaws.com/xxxx
Ja, das ist ein Repository. Das Problem war nicht das fehlende Repository sondern die Tatsache das die S3 Account Informationen nicht als Umgebungsvariable gesetzt wurden wie ich das normaler weise in meinem Backup Script mache.
Eine einzelne Datei aus Restic Snapshot restaurieren
Damit ich später nicht lange suchen muss wenn ich es mal dringend brauchen. Die Umgebungsvariablen von hier setzen und
mkdir tmp_restore
/usr/bin/restic restore -r $RESTIC_REPOSITORY -p $RESTIC_PASSWORD_FILE --include /home/hbauer/jekyll-export.zip --target /root/restic/tmp_restore latest
Rest der Doku ist hier
Backups mit Restic gegen den lokalen S3 Server Minio
Seit einiger Zeit ist restic mein Backupwerkzeug der Wahl. Jede Nacht “wacht” der Backup Server auf und zieht ein Backup von den relevante Servern. Das funktioniert auch gut nur leider kann ich damit nicht das gelegentliche manuelle Backup von Workstations implementieren. Hier ist eher ein Backup nach dem Push Prinzip auf “Abruf” notwendig. Durch diesen exzellenten Beitrag motiviert habe ich mir minio genauer angeschaut und werde damit erst einmal weiter machen. Hier die Dokumentation meiner Schritte
1. Installation Go und minio
mkdir golang
cd golang/
wget https://dl.google.com/go/go1.10.linux-386.tar.gz
tar -C /usr/local -xzf go1.10.linux-386.tar.gz
export PATH=$PATH:/usr/local/go/bin
go get -u github.com/minio/minio
mv /root/go/bin/minio /usr/local/bin/
2. Start des Dienstes auf dem Server
minio server /backup3/minio-hbauer/
Created minio configuration file successfully at /root/.minio
Drive Capacity: 1.3 TiB Free, 1.7 TiB Total
Endpoint: http://192.xxx.yyy.zz:9000 http://127.0.0.1:9000
AccessKey: 7QWExxxxxxxxxxxxxxxxI
SecretKey: /LOnyyyyyyyyyyyyyyyyyyyyyyyyyyy8tcccc
Browser Access:
http://192.xxx.yyy.zzz:9000 http://127.0.0.1:9000
Command-line Access: https://docs.minio.io/docs/minio-client-quickstart-guide
$ mc config host add myminio http://192.xxx.yyyy.zzz:9000 77QWExxxxxxxxxxxxxxxxI /LOnyyyyyyyyyyyyyyyyyyyyyyyyyyy8tcccc
Object API (Amazon S3 compatible):
Go: https://docs.minio.io/docs/golang-client-quickstart-guide
Java: https://docs.minio.io/docs/java-client-quickstart-guide
Python: https://docs.minio.io/docs/python-client-quickstart-guide
JavaScript: https://docs.minio.io/docs/javascript-client-quickstart-guide
.NET: https://docs.minio.io/docs/dotnet-client-quickstart-guide
Mit dem Browser kann man sich jetzt anmelden.
3. Einrichten des Repositories.
Ich verwende dieses von JP Mens empfohlen Tool auf dem Client.
wget https://raw.githubusercontent.com/binarybucks/restic-tools/master/bin/backup
mv backup restic-minio-backup.sh
chmod +x restic-minio-backup.sh
das noch konfiguriert werden muss
sudo mkdir /etc/backup
cd /etc/backup
vi local.config
BACKUP_HOSTNAME="myclient"
BACKUP_DIR="/home/hbauer/Dokumente/"
BACKUP_ARGS="--tag filesystem"
# HEALTHCHECK_URL="<URL from https://healthchecks.io/checks/ to notify>
vi /etc/backup/firsttest.repo
RESTIC_REPOSITORY="s3:http://192.xxx.yyy.zzz:9000/first-test"
AWS_ACCESS_KEY_ID="77QWExxxxxxxxxxxxxxxxI "
AWS_SECRET_ACCESS_KEY="/LOnyyyyyyyyyyyyyyyyyyyyyyyyyyy8tcccc"
RESTIC_PASSWORD='verygeheim'
Und nun der erste Start. Erstelle ein neues restic Repository
./restic-minio-backup.sh firsttest init
created restic backend 4271f8a2f7 at s3:http://192.xxx.yyy.zzz:9000/first-test
....
....
Erstelle ein Backup der in local.config definierten Daten
./restic-minio-backup.sh firsttest local
scan [/home/hbauer/Dokumente]
scanned 21 directories, 160 files in 0:00
[0:08] 100.00% 10.816 MiB/s 86.528 MiB / 86.528 MiB 181 / 181 items 0 errors ETA 0:00
duration: 0:08, 10.25MiB/s
snapshot 3a38485c saved
Soweit so gut. Jetzt mal einen kompletten Durchlauf.
Erstelle ein Dokument im Datenpfad, Sicherung durchführen, Dokument löschen und Daten wieder herstellen
echo first-test > /home/hbauer/Dokumente/minio-restic-test
./restic-minio-backup.sh firsttest local
using parent snapshot 3a38485c
scan [/home/hbauer/Dokumente]
scanned 21 directories, 161 files in 0:00
[0:01] 100.00% 86.528 MiB/s 86.528 MiB / 86.528 MiB 182 / 182 items 0 errors ......
snapshot a868b7d5 saved
rm /home/hbauer/Dokumente/minio-restic-test
./restic-minio-backup.sh firsttest restore a868b7d5 --target restic-restore/
password is correct
restoring <Snapshot a868b7d5 of [/home/hbauer/Dokumente] at 2018-03-04 07:21:16.86621425 +0100 CET by root@pedro> to restic-restore/
more restic-restore/Dokumente/minio-restic-test
first-test
So, die ersten Test scheinen gut gelaufen zu sein. Jetzt das ganze produktiv nehmen.
4. Autostart des minio Servers
gemäß dieser Beschreibung
vi /etc/default/minio
more /etc/default/minio
# Local export path.
MINIO_VOLUMES="/backup3/minio-hbauer/"
# Use if you want to run Minio on a custom port.
#MINIO_OPTS="--address :9199"
Service beim Start hochfahren
cd /etc/systemd/system/
curl -O https://raw.githubusercontent.com/minio/minio-service/master/linux-systemd/minio.service
systemctl enable minio.service
systemctl daemon-reload
systemctl start minio.service
5. Next Steps
Einiges ist noch offen:
- ein Setup für verschiedene Benutzer
- NGinx Proxy mit TLS
aber die ersten Backups können von meiner Workstation in einem separaten VLAN schon mal laufen
AWS S3 Buckets auf IP Adressen einschränken
Die ersten Gehversuche mit Restic Backups sind recht erfolgversprechend. Bisher ist der lokale Server oder ein Hetzner FTP Server das Ziel.
Für einige kleinere Server nutze ich das hier beschriebene Verfahren mit Amazon S3 Storage.
Um neben der Einschränkung über ID/Password eine zusätzliche Barriere einzurichten habe ich die dort beschriebene Policy noch um den Parameter IP Adresse erweitert. Damit es es nur noch möglich vom zu sichernden Rechner auf das Backup Medium zuzugreifen.
Da man dies über die Webverwaltung ändern kann könnten man im Fall der Fälle dies auch abschalten und dann von einem anderen Rechner auf das Backup zugreifen.
"Condition": {
"IpAddress": {
"aws:SourceIp": "wwww.xxx.yyy.zz"
}
}
Backups mit restic
Ich habe in der letzten Zeit viel gutes über das Backup Verfahren restic gelesen (z.B. hier. Meine bisherigen Verfahren waren etwas unterschiedlich und restic scheint hier alle Anforderungen abzudecken.
Hier meine Notizen für die Installation auf einem Debian 9 Backup Server
Installation von Go und restic
Zuerst die Installation von Go in der Version 1.8 auf meinem Debian 9 Server
sudo apt-get install git golang-1.8-go
export GOROOT=/usr/lib/go-1.8
export PATH=$GOROOT/bin:$PATH
go version go1.8.1 linux/386
Das restic Programm aus dem Github Repo ziehen und kompilieren
mkdir tmp
cd tmp
git clone https://github.com/restic/restic
cd restic
go run build.go
cp restic /usr/bin
restic version
restic 0.7.3 (v0.7.3-79-gac92e2dd)
compiled with go1.8.1 on linux/386
Backup Routine
Mein Ziel ist es, verschiedene Server mit verschiedenen Verzeichnissen zu sichern. Damit das ganze übersichtlich bleibt lege ich eine Datei mit den “zu ignorierenden” Verzeichnissen an und für jeden Server eine eigne Datei mit “zu sichernden” Dateien. Hier ist darauf zu achten das es bei den Verzeichnissen oder Dateien kein Leerzeichen am Ende gibt.
Das Kennwort halte ich in einer eigenen Datei. Zuerst diese Datei erstellen und das Repository erstellen
echo supersecretpassword > /root/restic/repopassword.txt
chmod 400 /root/restic/repopassword.txt
restic -r /backup/restic init
enter password for new backend:
enter password again:
created restic backend c828c80164 at /backup/restic
Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.
Auf Basis dieses Beitrags habe ich für den Aufruf das folgende Script erstellt.
#!/bin/bash
RESTIC_PASSWORD_FILE=/root/restic/repopassword.txt
RESTIC_REPOSITORY=/backup/restic
RESTIC_EXCLUDELIST=/root/restic/excludelist.txt
RESTIC_BACKUP_SERVER1=/root/restic/backup-list-server-1.txt
/usr/bin/restic -r $RESTIC_REPOSITORY -p $RESTIC_PASSWORD_FILE backup --files-from $RESTIC_BACKUP_SERVER1 --exclude-file $RESTIC_EXCLUDELIST
/usr/bin/restic -r $RESTIC_REPOSITORY -p $RESTIC_PASSWORD_FILE forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 10
