Aus der bliebten Reihe: "wie werde ich zum Volltrottel und kann mir Stunden meines Lebens versauen" zeige ich heute, wie man sich retten kann, wenn man etwas zu voreilig seinen ZFS Pool optimiert und dann auch noch das Wiki von Proxmox dazu nutzt.
Dort steht zwar in einer Warnung
Warning: Do not set dnodesize on rpool because GRUB is not able to handle a different size. see Bug entry https://savannah.gnu.org/bugs/?func=detailitem&item_id=48885
wer aber ein echter Mann ist überliest das und activiert das Feature in dem er
zfs set xattr=sa dnodesize=auto rpool/$IRGENDEINDATASETausführt. Ausschlaggebend ist dnodesize mit einem anderen Wert als legacy. Das steht auch so in der ZFS manpage.
Nun ist das Kind in den Brunnen gefallen und ein
``bash zpool get all rpool | grep -i node rpool feature@large_dnode active local
bestätigt uns, das wir uns bis auf weiteres nichts mehr vornehmen sollen. Wenn hier nämlich **active** steht, dann ist das doof für uns und unser rpool wird mit hilfe von Grub nicht mehr booten.
Vorausgesetzt wir haben genug Platz auf unserem Server, so können wir aber alle Container herunterfahren und die Volumes/Datasets migrieren in ein Dataset, welches dnodesize=legacy gesetzt hat. Das will man natürlich so schnell und einfach wie möglich haben. Daher hab ich den Vorgang für mich wie folgt automatisiert:
```bash
zfs create rpool/$IRGENDEINDATASET-FUER-NEUE DATEN
zfs snapshot -r rpool/BISHERIGESDATASET@migrate
zfs send -Rv rpool/BISHERIGESDATASET@migrate | zfs receive -F rpool/$IRGENDEINDATASET-FUER-NEUE DATEN
zfs destroy -r rpool/BISHERIGESDATASET
zfs rename rpool/$IRGENDEINDATASET-FUER-NEUE DATEN rpool/BISHERIGESDATASETAnschließend sollte unsere Kontrolle statt
zpool get all rpool | grep -i node
rpool feature@large_dnode **active** localzpool get all rpool | grep -i node
rpool feature@large_dnode **enabled** localauswerfen. Jetzt heisst es nur noch Container starten.
Leider habe ich feststellen müsse, das die obige Anleitung nicht immer (genauere Hintergründe unbekannt) funktioniert. Auch tut sich der eine oder andere Schwer mit der CLI. Dann kann man sich behelfen indem man ein weiteres Dataset anlegt und dieses in der Proxmox UI einbindet. Nun kann man einfach über die UI LXC Server stoppen, das Dataset migrieren und wieder starten. Geht soweit ganz gut... hätte man auch früher haben können :)
Ein einfaches Skript um Dateien/Ordner zu sichern und diese in begrenzter Anzahl vorzuhalten ist etwas, das ich immer brauche. Es gibt diverse Tools - manchmal braucht man es aber nicht so umfangreich.
Ich nutze gern das nachfolgende Skript unter Bash dazu. Die Kommandos zur Sicherung tausche ich immer wieder aus und natürlich gibt es einen Timestamp- am Ende wird ein wenig aufgeräumt.
Quick and Dirty - ich mag es.
#!/bin/bash
DATE=`date +%Y%m%d-%H%M%S`
DST=/Pfad/zum/BackupOrdner
SRC=/Pfad/zu/den/Daten
tar czvf $DST/Backup-$DATE.tgz
if [ $? -ne 0 ]; then
echo "Da hat was nicht geklappt"
exit 1
fi
find $DST -type f -mtime +60 -name "*.tgz" -exec rm -f {} \;
if [ $? -ne 0 ]; then
echo "Da hat was nicht geklappt"
exit 1
fi
exit 0Memo an mich selbst: Sollte es vorkommen, das ceph health detail der Meinung ist, das inkonsistente Placementgroups vorhanden sind: cool bleiben!
Wenn man es nicht auf die lange Bank schiebt und sich die Doku dazu gut angesehen hat, dann wird man recht schnell fündig wie man der Sache Herr werden kann.
Zunächst einmal findet man heraus, welche PGs kaputt sind:
ceph health detail
HEALTH_ERR 2 scrub errors; Possible data damage: 2 pgs inconsistent
OSD_SCRUB_ERRORS 2 scrub errors
PG_DAMAGED Possible data damage: 2 pgs inconsistent
pg 9.9d is active+clean+inconsistent, acting [2,12,23]
pg 9.fe is active+clean+inconsistent, acting [15,23,2]Man sieht hier, das die PGs mit den IDs 9.9d und 9.fe einen weg haben.
Anschließend startet man die Heilung:
ceph pg repair 9.9d
ceph pg repair 9.feGar nicht so schwer, oder?