Ja das ist korrekt. Und eine SSD backupen kann man in Proxmoxx leider nicht
Ja und dazu habe ich auch eine klare, vielleicht unpopuläre Meinung: Wenn der Hauptgrund für das selber hosten Kosteneinsparungen sind, dann sollte man es warscheinlich nicht machen. Denn wenn man es “richtig” macht, ist es in der Regel nicht günstiger, als Google Workspace oder M365.
Das gilt natürlich vorallem für KMUs, wo häufig “shortcuts” genommen werden, und dann die Gesichter lang sind, wenn auch der Spezialist die Daten nicht mehr herzaubern kann von der defekten Disk, oder dem nicht vorhandenen Backup und/oder man tagelang nicht mehr richtig arbeiten kann, bis der Server repariert, neu aufgesetzt und die Daten zurückgespielt sind. 
Bei Privatpersonen, kommt es halt darauf an. Wenn die Daten an drei Orten gespeichert sind und man im schlimmsten Fall mit ein paar Tagen Ausfall und einem Backup leben kann, das schon ein oder zwei Tage alt ist (angenommen man macht tägliche Backups auf das NAS und in die Storage Box), dann ist deine Lösung völlig in Ordnung.
Es gibt den Proxmox Backup Client, den man auf beliebigen Debian basierten Hosts, und somit auch auf dem Proxmox Server selbst installieren kann, und damit kann man dann beliebige Ordner und Files auf einen Proxmox Backup Server backupen: Backup Client Usage — Proxmox Backup 3.2.7-1 documentation https://ostechnix.com/use-proxmox-backup-client-to-backup-files/
Benutzt habe ich den selbst aber noch nie, und das wäre wohl auch eher eine Frage für das Proxmox Forum.
1 Like
Moin,
Ich habe die Backup App von Nextcloud gelöscht und Borg backup eingerichtet. Vorbild war folgende Anleitung:
https://www.c-rieger.de/nextcloud-borg-backup-zur-hetzner-storage-box/
Also prinzippiel scheint das Backup zu funktionieren. Zumindest von den Datenvolumen kommt das echt gut hin. Jedoch habe immer Warnmeldungen, welche ich nicht so ganz zuordnen kann. Einmal klappt das mit php 8.2 nicht. Ich habe in der Datei einfach mal das mit php 8.2.22 ergänzt, da dies meine php Version ist. Aber mit php 8.2 kommt dieselbe Meldung.
root@Nextcloud:~# /root/backup.sh
Maintenance mode enabled
###### Backup gestartet: Sat Aug 10 08:52:59 UTC 2024 ######
Dienste werden gestoppt ...
Failed to stop php8.2.22-fpm.service: Unit php8.2.22-fpm.service not loaded.
Datenbanksicherung wird erstellt ...
Datenbankgröße ermitteln ...
DB Size (MB)
nextcloud 22.03
Übertrage Dateien ...
Remote: Warning: Identity file /home/uxxxx/.ssh/id_ed25519 not accessible: No such file or directory.
Creating archive at "ssh://uxxxxx@uxxxxx.your-storagebox.de:23/./backup/cloud::240810-0852"
/daten/lost+found: dir_open: [Errno 13] Permission denied: 'lost+found'
------------------------------------------------------------------------------
Repository: ssh://uxxxxxx@uxxxxxx.your-storagebox.de:23/./backup/cloud
Archive name: 240810-0852
Archive fingerprint: bcdbefdcbb539be4790fcb0f29e88cf0653b30bd8c8c2a3b346c2ee08c43e3a6
Time (start): Sat, 2024-08-10 08:53:00
Time (end): Sat, 2024-08-10 08:53:05
Duration: 4.47 seconds
Number of files: 28548
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
Original size Compressed size Deduplicated size
This archive: 14.39 GB 13.96 GB 2.10 MB
All archives: 57.55 GB 55.83 GB 13.68 GB
Unique chunks Total chunks
Chunk index: 31958 134223
------------------------------------------------------------------------------
Remote: Warning: Identity file /home/uxxxxxx/.ssh/id_ed25519 not accessible: No such file or directory.
------------------------------------------------------------------------------
Original size Compressed size Deduplicated size
Deleted data: 0 B 0 B 0 B
All archives: 57.55 GB 55.83 GB 13.68 GB
Unique chunks Total chunks
Chunk index: 31958 134223
------------------------------------------------------------------------------
Dienste werden gestartet ...
Failed to restart php8.2.22-fpm.service: Unit php8.2.22-fpm.service not found.
Aufräumen ...
Maintenance mode disabled
###### Backup beendet: Sat Aug 10 08:53:08 UTC 2024 ######
/root/backup.sh: line 95: mail: command not found
root@Nextcloud:~#
Nicht wundern, ich habe heute schon mehrere backups manuell ausgeführt.
Mein Skript sieht folgendermaßen aus:
#!/usr/bin/env bash
#
# Nextcloud Sicherung: Hetzner-Storagebox
# Datenbanktyp: MariaDB
#
###################################################################################################
export BORG_RSH='ssh -i /home/uxxxxxx/.ssh/id_ed25519'
# /home/<user>/.ssh/id_ed25519: Pfad zum privaten Schl ssel
export BORG_PASSPHRASE="xxx"
# SECRET-PASSPHRASE: Passphrase, mit dem das Repo erstellt wurde
VORNAME="x"
# Vorname: Ihr Vorname
NACHNAME="x"
# Nachname: Ihr Nachname
EMAIL="xxx"
# mail@domain.de: Ihre Emailadresse
NPATH="/var/www/nextcloud"
# NPATH: Pfad zur Nextlcoud-Software
WEBSERVER="apache2"
# WEBSERVER: "nginx" oder "apache2"
PHPVERSION="8.2.22"
# PHPVERSION: "8.3" oder "8.2" oder "8.1"
BACKUP_USER="uxxxxxx"
# BACKUP_USER: Ihr Benutzer der Hetzner Storage Box
REPOSITORY_DIR="cloud"
# REPOSITORY_DIR: Der Name des BORG-Repositories
# Ab hier bitte keine ^dnderungen mehr vornehmen
NEXTCLOUDDATEN=$(sudo -u www-data php $NPATH/occ config:system:get datadirectory)
NEXTCLOUDDB=$(sudo -u www-data php $NPATH/occ config:system:get dbname)
NEXTCLOUDDBUSER=$(sudo -u www-data php $NPATH/occ config:system:get dbuser)
NEXTCLOUDDBPASSWORD=$(sudo -u www-data php $NPATH/occ config:system:get dbpassword)
sudo -u www-data php $NPATH/occ maintenance:mode --on
if [ ! -d "/var/log/borg" ]; then
mkdir -p /var/log/borg
fi
if [ ! -d "/sicherung/sql" ]; then
mkdir -p /sicherung/sql
fi
LOG="/var/log/borg/$(date +%y%m%d-%H%M)-backup.log"
REPOSITORY="ssh://${BACKUP_USER}@${BACKUP_USER}.your-storagebox.de:23/./backup/${REPOSITORY_DIR}"
errorecho() { cat <<< "$@" 1>&2; }
exec > >(tee -i "${LOG}")
exec 2>&1
echo "###### Backup gestartet: $(date) ######"
echo ""
echo "Dienste werden gestoppt ..."
systemctl stop $WEBSERVER.service php$PHPVERSION-fpm.service redis-server.service
echo ""
Was sagen die folgenden Befehle?
systemctl --type=service | grep "php"
und
apt list php*fpm --installed
Bei systemctl kommt nichts und bei apt list kommt “Listing…Done”
Dann hast du php-fpm gar nicht installiert, so wie es aussieht.
Um die Fehlermeldung zu vermeiden, kannst du es einfach aus dem Skript entfernen. Die entsprechende Zeile würde dann folgendermassen aussehen:
systemctl stop $WEBSERVER.service redis-server.service
1 Like
…und dann das selbe nochmal am Ende des Skripts, wo die Services wieder gestartet werden:
echo "Dienste werden gestartet ..."
systemctl restart mariadb.service redis-server.service php$PHPVERSION-fpm.service $WEBSERVER.service
ändern auf:
echo "Dienste werden gestartet ..."
systemctl restart mariadb.service redis-server.service $WEBSERVER.service
1 Like
Perfekt, danke dir. Die Meldung ist weg.
Aber ich habe noch folgende Meldung übrig:
Remote: Warning: Identity file /home/uxxxxxx/.ssh/id_ed25519 not accessible: No such file or direct ory.
Creating archive at "ssh://uxxxxxxx@uxxxxxx.your-storagebox.de:23/./backup/cloud::240810-1406"
/daten/lost+found: dir_open: [Errno 13] Permission denied: 'lost+found'
Ist das kritisch oder kann ich das ignorieren? Eigentlich sollte der Pfad bestehen.
Lost+ Found ist ein Ordner, der von Linux Dateissystemen wie ext4 im Root Verzeichnis jeder Partition erstellt wird, und wo dann Dateien oder Verzeichnisfragmente gespeichert werden, die nicht mehr einem Verzeichnis zugeordnet sind, z.B. wenn das Dateisystem beschädigt wurde, k.A. durch einen Stromausfall oder ein unerwartetes Herunterfahren des Systems.
Der Grund warum Borg diesen Ordner sieht, ist, dass du warscheinlich anstatt einen Ordner auf der zusätzlichen SSD zu erstellen für deine Daten, offenbar die komplette SSD nach /daten gemountet hast, und darum befindet sich in deinem Datenverzeichnis nun halt dieser Lost+Found Ordner, und nein, der muss nicht gesichert werden, und daher sollte das Ignorieren der Meldung ok sein.
Um die Meldung weg zu kriegen, müsstest du Borg irgendwie dazu bringen den Ordner zu ignorieren. Ohne Gewähr könntest du mal folgendes versuchen:
Am Ende des folgenden Abschnitts eine weitere Zeile mit --exclude /daten/lost+found hinzufügen, sprich folgendes…
borg create -v --stats \
$REPOSITORY::$(date +%y%m%d-%H%M) \
/root \
/etc \
/var/www \
/home \
$NEXTCLOUDDATEN \
/sicherung/sql \
--exclude /backup \
--exclude /dev \
--exclude /proc \
--exclude /sys \
--exclude /var/run \
--exclude /run \
--exclude /lost+found \
--exclude /mnt \
--exclude /var/lib/lxcfs
…auf folgendes abändern:
borg create -v --stats \
$REPOSITORY::$(date +%y%m%d-%H%M) \
/root \
/etc \
/var/www \
/home \
$NEXTCLOUDDATEN \
/sicherung/sql \
--exclude /backup \
--exclude /dev \
--exclude /proc \
--exclude /sys \
--exclude /var/run \
--exclude /run \
--exclude /lost+found \
--exclude /mnt \
--exclude /var/lib/lxcfs \
--exclude /daten/lost+found
1 Like
Die Meldung mit dem SSH Key bringst du weg, in dem du am Anfang des Skripts den Pfad zum korrekten SSH Key angbibst, mit dem du dich dann an der Storage Box anmeldest, oder in dem du die Zeile entfernst/auskommentierst. Ich würde ersteres empfehlen, da ein Passwort eingeben nicht wirklich praktikabel ist, wenn du die Backups automatisieren willst.
1 Like
Um die Meldung weg zu kriegen, müsstest du Borg irgendwie dazu bringen den Ordner zu ignorieren. Ohne Gewähr könntest du mal folgendes versuchen:
Am Ende des folgenden Abschnitts eine weitere Zeile mit --exclude /daten/lost+found hinzufügen, sprich folgendes…
Danke damit habe ich das wegbekommen 
Die Meldung mit dem SSH Key bringst du weg, in dem du am Anfang des Skripts den Pfad zum korrekten SSH Key angbibst, mit dem du dich dann an der Storage Box anmeldest, oder in dem du die Zeile entfernst/auskommentierst. Ich würde ersteres empfehlen, da ein Passwort eingeben nicht wirklich praktikabel ist, wenn du die Backups automatisieren willst.
Da hatte ich schon mehrere Pfade probiert oder ich kenne meinen eigenen Pfad nicht . Da letzte das Backup automatisch durchgelaufen, werde ich das erstmal lieber nicht anfassen. Ich habe jetzt eine funktionierende inkrementelle Backup Lösung und damit mein Ziel hoffentlich erreicht. Und das ohne ein neues Nextcloud aufzusetzen
1 Like
Standardmässig werden SSH Keys unter ~/.ssh bzw. /home/username/.ssh abgelegt.
Joa, normalerweise probiert der SSH client einfach alle Keys durch unter .ssh, was warscheinlich der Grund ist, warum es trotzdem funktioniert.
Wenn man aber verschiedene Keys nutzt, für verschiedene Verbindungen, macht es zumindest ab einer gewissen Anzahl schon Sinn den richtigen Key für die jeweilgen Verbuindungen zu spezifizieren, ansonsten bruteforcest du ja quasi die SSH Server mit denen du dich verbinden willst.
diesen /home/uxxxxxx/.ssh habe ich ja sogar bei mir drinnen.
Mit ~/.ssh sagt er sofort das es nicht geht.
uxxxxxxx schaut wie der Username der Storage Box aus, ich nehme jetzt einfach mal an diesen User gibt es auf deinem System nicht, und folglich auch kein entsprechendes Home Directory, oder doch?
Ja das ist der User der Storeage von Hetzner.
Ist hatte zwischenzeitlich auch mal nextcloud, admin und root als User versucht. Auf der Hetzner Storage habe ich nichts angelegt. Gemietet, in Proxmoxx eingebunden und fertig.
Die Keys werden standardmässig im .ssh Ordner des Users gespeichert, mit dem man den ssh-keygen Befehl ausführt (siehe Kapitel 1 in der verlinkten Anleitung), ausser man definiert explizit einen anderen Pfad.
Und du hast auch nicht den öffentlichen Key auf die Storage Box übertragen, wie es ebenfalls in Kapitel 1 der Anleitung, beschrieben ist? Falls nicht, dann weiss ich ehrlich gesagt nicht, warum es überhaupt funktioniert…
Hmm, vielleicht funktioniert es ja deshalb, falls du mit “in Proxmox eingebunden”, die SFTP Verbindung von hier meinst. Vielleicht benutzt das Skript bzw. der SSH Client einfach diese bestehende Verbindung, bzw, die Credentials von dieser…?
habe ich gemacht. Aber es sieht nicht so aus wie in der Anleitung. Warum weiß ich nicht.
root@Nextcloud:~# ssh-keygen -t ed25519 -C "BORG-StorageBox"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519):
/root/.ssh/id_ed25519 already exists.
Overwrite (y/n)?
ok, sieht so aus als wäre der Pfad zum Key:
/root/.ssh/id_ed25519
Der home folder des root users ist /root, und nicht wie bei normalen Usern /home/username
Anmerkung:
In der Anleitung scheint ein normaler User verwendet zu werden, was die unterschiedlichen Pfade erklären würde.
und bestätigen auch die weiteren Dialoge mittels der -Taste, also ohne eine Passphrase für den Key zu vergeben. Der gesamte Dialog sieht wie folgt aus:
rieger@server:~$ ssh-keygen -t ed25519 -C "BORG-StorageBox"
1 Like
Nun ist die Meldung weg und alles läuft perfekt durch. Ich meinte ich hätte das gestern mit root probiert, hatte mich da aber wohl vertippt
Besten Dank für deinen Support
1 Like