SSDs gegen HDDs tauschen und Backup wiederherstellen

Hallo zusammen!

Ich betreibe das Ugreen 4800 und ein 2-Bay-Ugreen. Die Daten werden vom großen NAS auf das 2-Bay live synchronisiert. In einem Anfall von "ich versuche es mal" habe ich im Ugreen SSDs eingebaut. Das funktionierte bisher ganz gut, jedoch fällt im RAID5-Verbund immer wieder eine der SSDs sporadisch aus, sodass der Verbund auseinanderfällt.

Kurz gesagt: Ich möchte gerne "back to the roots" und die SSDs gegen Seagate NAS HDDs austauschen. Ich habe bereits eine SSD aus dem Verbund entfernt und dachte, ich könnte einfach nach und nach die HDDs einfügen und jeweils einen Rebuild durchführen. Das klappt jedoch nicht – offenbar kann ich nicht einfach SSDs gegen HDDs austauschen. Ugreen erkennt diese Festplatte dann nicht als verwendbares Speichermedium, das ich in den degradierten Verbund wieder einfügen kann.

Also werde ich alle Daten auf eine externe SSD packen, alle SSDs aus dem Verbund entfernen, die 4 HDDs einbauen und dann das RAID5 "Speicherpool1" wiederherstellen. Problematisch ist jedoch Folgendes: Ich habe Docker-Container installiert, die ich nutze. Hat jemand eine Idee, wie ich diese migrieren kann? Werden die Docker-Einstellungen / YAML-Konfigurationen im Cloud-Backup des NAS gesichert – ebenso wie die Benutzereinstellungen? Ehrlich gesagt habe ich keine Lust, alles neu einrichten zu müssen. Mit den Ordnerfreigaben kann ich noch leben, da es nicht so viele sind. Aber was ist mit den Docker-Containern?

Oh, und – verliere ich dann alle Einstellungen, wenn ich den alten Speicherpool "zerpflücke", oder bleiben diese bestehen?

Entschuldigung, ich kann mir vorstellen, dass das eine ziemliche Ansammlung blöder Fragen ist. Aber vielleicht hat ja schon mal jemand einen ähnlichen Schritt durchgeführt (was ich fast bezweifeln will) und kann mir sagen, ob es bei ihm funktioniert hat.

Viele Grüße, Daniel

Ich habe inzwischen mit dem Support gesprochen: Ein Mischen von SSD und HDD ist nicht möglich. Daher habe ich ein Rsync-Skript erstellt, das meine Verzeichnisse auf eine ext4-formatierte USB-SSD kopiert. Sobald das abgeschlossen ist, löse ich den Verbund und tausche die SSDs gegen HDDs aus. Anschließend kopiere ich die Verzeichnisstruktur zurück. Das ist der Plan, und ich werde darüber berichten.

Hier ist das Rsync-Skript, das vielleicht nützlich sein könnte. Es wurde so konzipiert, dass es auf der externen SSD eine Logdatei erstellt, die maximal 20 MB groß wird. Danach wird eine neue Logdatei erstellt. Es gibt maximal sechs Logs, die dann wieder überschrieben werden. Das Skript führt einen Rsync-Befehl aus, der auch nach dem Verlassen der SSH-Konsole weiterläuft. Die Übertragungsrate auf die externe SSD ist nicht besonders hoch, daher dauert es bei 3 TB schon eine ganze Weile.

Vorgehensweise: Per SSH auf das NAS zugreifen. Das Skript auf dem externen Datenträger mit "touch" und/oder "nano" erstellen, die Zeilen mit den Quell- und Zielverzeichnissen anpassen und dann ausführen. Vorher noch mit "chmod +x [scriptname]" das Skript ausführbar machen.

Sollte die SSH Verbindung zur Console auf dem NAS einen Timeout haben oder abbrechen, kann man sich neu verbinden und den Log des sync Prozesses mit:

tail -f /mnt/@usb/sde1/rsync-log.txt

weiter anschauen und verfolgen.

Will man den Prozess abbrechen, kann man sich in der Console der SSH Verbindung mittels:

pgrep rsync

Die laufenden Rsync Prozesse anschauen und mittels

kill 238928 (<- Prozessnummer)

den Prozess stoppen.

Ja, ich gebe zu, es ist etwas holprig und wirkt ein wenig ungeschickt, aber für mich ist es momentan die einfachste Lösung, bevor ich alles im Web-Backend des NAS hin und her kopiere. Sicherlich hätte das auch funktioniert. Gibt es eine einfachere Lösung, die mir einfach nicht eingefallen ist? Dann gerne her damit! Ich hoffe, das kann dem einen oder anderen hier weiterhelfen!

#!/bin/sh
LOG_DIR="/mnt/@usb/sde1"
LOG_FILE="$LOG_DIR/rsync-log.txt"
MAX_SIZE=20971520  # 20 MB in Bytes
ROTATIONS=5

# Hinweis zu Root-Rechten
if [ "$(id -u)" -ne 0 ]; then
 echo "[WARNUNG] Dieses Skript sollte als root gestartet werden, da rsync -aAX sonst fehlschlägt."
 echo "Beende Skript."
 exit 1
fi

# Prüfen, ob rsync bereits läuft
if pgrep rsync >/dev/null; then
 echo "[INFO] Es läuft bereits ein rsync-Prozess. Vorgang wird nicht erneut gestartet."
 exit 1
fi

# Log-Rotation prüfen
if [ -f "$LOG_FILE" ]; then
 FILE_SIZE=$(stat -c%s "$LOG_FILE")
 if [ "$FILE_SIZE" -ge "$MAX_SIZE" ]; then
   NOW=$(date +"%Y-%m-%d_%H-%M-%S")
   mv "$LOG_FILE" "$LOG_FILE.$NOW.txt"
   gzip "$LOG_FILE.$NOW.txt"
 fi
fi

# Alte Logs bereinigen, falls mehr als ROTATIONS existieren
LOG_COUNT=$(ls "$LOG_DIR"/rsync-log.*.txt.gz 2>/dev/null | wc -l)
if [ "$LOG_COUNT" -gt "$ROTATIONS" ]; then
 TO_DELETE=$(ls -t "$LOG_DIR"/rsync-log.*.txt.gz 2>/dev/null | tail -n +$(($ROTATIONS + 1)))
 echo "$TO_DELETE" | xargs rm -f
fi

# Rsync starten – vollständig vom Terminal entkoppelt per setsid
echo "[INFO] Starte rsync: $(date)" >> "$LOG_FILE"
setsid sh -c 'rsync -aAXvh --progress --partial --inplace --append "/volume1/[SOURCE VERZEICHNIS]/" "/mnt/@usb/sde1/[ZIELVERZEICHNIS]/" >> "/mnt/@usb/sde1/rsync-log.txt>" 2>&1' &

# Live-Status anzeigen
sleep 2
echo "[INFO] Zeige Live-Status (STRG + C zum Abbrechen – rsync läuft weiter)..."
tail -f "$LOG_FILE"

Update: In diesem Experiment werde ich nicht herausfinden, ob ich die SSDs mit HDDs tauschen kann Ich habe kurzerhand noch ein Ugreen 4800 plus bestellt, das ich dann mit HDDs ausstatten und als "Produktionsserver" nutzen werde. Das andere NAS, das momentan noch mit SSDs ausgestattet ist, erhält neue HDDs und wird als zweites Sync-Device ausgelagert. So habe ich meine Backup- und Sync-Stationen auch außerhalb des Büros verteilt. Vielleicht ein bisschen übertrieben, aber alles ist besser als Datenverlust, wenn man auf die Daten angewiesen ist...