02/2022
So, ich hab hier noch eine olle Qnap NAS (TS-669L von 2013) rumstehen, die auch jahrelang problemlos lief. Allerdings hat sich Qnap in letzter Zeit nicht gerade mit Ruhm bekleckert und für das Ding stellt Qnap auch seit über ZWEI Jahren keine Sicherheitsupdates mehr zur Verfügung (Kernel 3.x, ugh). Stellt sich also die Frage: Weiterlaufen lassen, ausmustern oder gibt's noch andere Möglichkeiten?
Das Gerät hat eine Intel Atom-CPU (ist also x86-kompatibel) und hinten einen VGA- und HDMI-Anschluß. Könnte es sein, daß...?
Hab kurzerhand Monitor und Tastatur angeschlossen, beim Booten wie wild F2 und DEL gedrückt und siehe da: Es meldet sich ein BIOS. Danach einen boot-fähigen USB-Stick eingesteckt und tatsächlich bootet die Qnap von diesem. Der Plan war geboren.
Der Plan
Da's keine Security-Updates mehr von Qnap für dieses Modell gibt, ich aber ungern Dinge wegwerfe, die noch funktionieren, muss ein aktuelles Betriebssystem auf das Teil um noch ein paar weitere Dienstjahre rauszuquetschen. Außerdem mag ich den Formfaktor der Consumer NAS (NASes, NÄSSE? Wie ist die Mehrzahl von NAS? :D) von Qnap, Synology etc.
1) Beschaffung einer ausreichend großen externen HDD für eine Komplettsicherung der NAS
2) Sichern aller Daten auf die externe HDD
3) Installieren/Einrichtung des neuen OS
4) Zurückspielen des Backups von externer HDD
Die Umsetzung
1) Zwar mache ich Backups auf zwei andere Server, aber das Wiederherstellen der Daten über 1 Gbit LAN dauert TAGE. (Ich hab erst vor einigen Monaten eine der HDDs durch eine SSD ersetzt und musste alles neu einrichten und zurückspielen, daher weiß ich das.) Zum Glück gab's bei Alternate gerade eine 14TB Exos für schmale 250,- Euro, also her damit. (Hut ab an Alternate.de für die Lieferzeit von einem Tag!)
Die 14TB Platte hab ich in ein Icybox-Case reingeschraubt und mit NTFS formatiert, dann kann ich sie auch an meinem Windows Dedup-Server verwenden.
2) Die externe HDD im Icybox-Case wird über eSata an die Qnap NAS angeschlossen. Ich hatte davor schon andere Festplatten in diesem Case und das funktioniert mit der Qnap einwandfrei. In der Backupstation vom QTS noch schnell einen Replikationsjob einrichten und schon wird der gesamte Inhalt der NAS auf die externe HDD synchronisiert (Dauert trotzdem noch fast einen Tag.)
3a) Welches Betriebssystem soll auf die NAS? Windows kommt aus ideologischen und lizenztechnischen Gründen nicht in Frage, außerdem hat dieses Qnap Modell nur 1 GB RAM und wäre damit dafür ungeeignet.
Also ein GNU/Linux. Nur welches? Ich verwende in meinem Hardware Zoo (über ein dutzend Gerätschaften) u.a. Ubuntu MATE, Manjaro, BunsenLabs, Ubuntu Server etc. Aber, wie gesagt, die NAS hat nur 1 GB RAM und soll ein reiner Fileserver werden, d.h. ich brauche keine GUI.
Zwischen-Schimpftirade: Wer als Sysadmin eine Maus braucht, ist für mich kein Admin!
Weiterhin möchte ich eine deb/apt-basierte Distro. Das heisst entweder Debian (bissle blank) oder Ubuntu Server (bissle zuviel "live"-Gedöns). Meine Wahl fiel auf Ubuntu Legacy-Server 20.04 LTS, weil ich den cloud_init Mist nicht will/brauche und der noch den Debian-Installer anstatt dem halbgaren Subquity-Installer der Live-Server Variante hat. Also, ISO runtergeladen und mit Rufus auf einen USB-Stick "gebrannt".
3b) Bevor wir loslegen sollten wir aber noch überlegen wie die Platten genutzt werden sollen: Früher™ hatte ich sechs 3TB WD_RED als RAID5 in der Qnap. Vor einigen Monaten hab ich eine der HDDs durch eine 1TB SSD ersetzt. Mein Plan war: die SSD ist für "heiße Daten", die HDDs sind das "Datengrab" (auf diese Weise wird der Spin-Up/Down der mechanischen HDDs verringert). Das hat sich im Realbetrieb auch bewährt.
Zuerst hatte ich überlegt, ob ich die Boot-SSD partitioniere (z.b. 50GB für System, den Rest für den Fileshare). Bringt mir aber nicht viel, da ich den Fileshare eh alle paar Tage auf andere Rechner sichere und bei einer Neuinstallation der Zeitgewinn nicht besonders groß ist. Also, alles auf eine Partition. Für die HDDs nehme ich ZFS, ein absolut überlegenes Dateisystem mit kinderleichter Einrichtung.
Aber für die Installation bleiben die HDDs erstmal abgekoppelt, nur die SSD bleibt eingesteckt.
3c) Die Qnap NAS wird vom USB-Stick gebootet, die Installation von Ubuntu Server verläuft ereignisarm.
Nur bei der Partitionierung muss man etwas aufpassen: Die Qnaps haben ein internes USB Modul, DOM aka Disk-On-Module (so ähnlich wie ein auf dem Mainboard verlöteter USB-Stick), dadurch können sie auch ohne Festplatten booten. Also legen wir "/boot" auf dieses DOM (ist bei meiner zwar nur 512 MB groß, aber für das boot Verzeichnis reicht das locker) und löschen alle vorhandenen Partitionen auf der SSD und legen "/" auf diese.
Auf LVM verzichten wir, denn auf der Bootplatte brauchen wir das nicht und mit ZFS auf den restlichen Platten ist das unnötig. Am Ende der Installation wählen wir noch Samba und SSH-Server aus, alles weitere können wir später entscheiden.
Den GRUB Boot Loader nehmen wir noch mit (hab ich auch auf das DOM gepackt), danach sind wir mit der Standard-Installation durch. :)
3d) Reboot und erster Start. Nach dem Einloggen begrüßt uns ein jungfräulicher Ubuntu-Server. Erst mal alles aktualisieren:
sudo apt update
sudo apt upgrade
Zeit sich häuslich einzurichten
Zuerst mal meine Bash Aliase nach .bash_aliases kopieren und die besten beiden CLI Filemanager installieren:
sudo apt install mc ranger
Ranger ist mein Favorit, aber als alter Norton Commander Benutzer der ersten Stunde (hach, die 1980er. *schwelg*) finden sich auch für MC Einsatzszenarien. :D
RAR und 7Zip sind natürlich auch ein Muß:
sudo apt install p7zip-full rar unrar atool
Ich bin wahrscheinlich der Einzige, der jemals RAR registriert (gekauft) hat, also kopiere ich meine fast 20 Jahre alte "rar.key" nach "/etc" ;-)
Mit "crontab -e" kurz die persönliche Crontab editieren und unser Config-Backup-Script (das ich auf jedem GNU/Linux Rechner benutze) als "@reboot" definieren. (d.h. bei jedem Reboot wird die Config gesichert).
#!/bin/sh
inxi -v4 -c0 > ~/.bck/inxi_$(hostname).txt
rar u -as ~/.bck/cfg_$(hostname).rar ~/.config/* ~/.*rc ~/.local/share/* /etc/*tab* /etc/samba/*.conf
cp -puv ~/.bck/* /ssd/autosave/$(hostname)/ > ~/logs/cp_mystart.log
Hinweis: Der Pfad für die cp-Zeile geht hier auf lokal und nicht, wie sonst, auf einen mountpoint (weil: wir sind ja schon auf dem Fileserver)
Snaps sollten wir noch rausoperieren und ein "sudo apt purge popularity-contest" entfernt eben diesen.
Fileshares und ZFS
Der Einfachheit halber verwende ich nur zwei Fileshares, einen auf der SSD (genannt "ssd") und einen auf den HDDs (genannt "hdd"). (Ich weiß, daß meine Namensgebung nicht sonderlich kreativ ist. :P) Aber wo lege ich die Fileshares hin? Faulerweise nehme ich "/ssd" für die SSD und "/hdd" für das ZFS-Volume. Das müssen wir natürlich noch kurz einrichten (nachdem die HDDs wieder eingeschoben wurden und evtl. vorhandene Partitionen mit fdisk gelöscht wurden):
sudo apt install zfsutils-linux
sudo zpool create hdd sdc sdd sde sdf sdg -f
Nach nochmaliger Überlegung machen wir das doch lieber per UUID wie hier beschrieben:
sudo zpool destroy hdd
ll /dev/disk/by-id/
# disk-ids heraussuchen ("ata-*")
sudo zpool create hdd [ID1] [ID2] [ID3] [ID4] [ID5]
zpool status
# wir wollen ohne root zu sein schreiben, daher:
sudo chown -Rv bingen:bingen /hdd/
Mit den 1 GB RAM in dieser Qnap kann man Deduplikation natürlich vergessen, aber LZ4 Kompression nehmen wir mit (die ist in ZFS ziemlich intelligent und ressourcenschonend)
sudo zfs set compression=lz4 hdd
sudo zfs set dedup=off hdd
Auf den HDDs gibt's nur zwei Verzeichnisse, dafür könnte man doch ZFS-Filesystems einrichten um später coole ZFS-Features wie snapshots, export oder send zu benutzen, oder? (Kann man optional natürlich auch weglassen oder weiter herunterbrechen (d.h. separate "nested datasets" für z.B. Audio, Videos, eBooks etc. Mal schaun...)
sudo zfs create hdd/medien
sudo zfs create hdd/archiv
ZFS-Scrubbing mache ich monatlich per anacron-job.
Warum kein RAID 5 oder 6?
Nun, die HDDs liefen jahrelang problemlos als RAID5, warum jetzt also nur ein Stripe-Set ohne Datensicherheit?
1) RAID6 ist mir zu "teuer". Zwei von Fünf Platten für vermeintliche Sicherheit ist mir zuviel.
2) RAID5 bringt mir leider auch kaum noch was: Die 3TB Platten sind mittlerweile alle über 8 Jahre alt. d.h. wenn eine davon die Grätsche macht, dann ist die Chance, dass beim RAID-Rebuild eine weitere ausfällt extrem hoch.
Außerdem mache ich drei mal pro Woche Backups auf unterschiedliche andere (lokale) Server, d.h. wenn das Stripe-Set ausfällt dann sind meine Backups maximal 2-3 Tage alt. Und die Daten auf den HDDs ändern sich selten bis nie, eins der Verzeichnisse heißt buchstäblich "archiv".
Andererseits wären Paritätsbits bei den alten Platten auch nicht schlecht. Früher oder später werden "bad blocks" oder "BitRot"auftauchen, die ZFS mit seiner "self-healing" Funktion ausgleichen kann. Die Einrichtung eines RAIDs unterscheidet sich bei Anlegen des Pools nur in einem Parameter:
sudo zpool create raidz1 hdd sdc sdd sde sdf sdg
Hm? Ne, ich bleibe doch beim Stripe-Set. Falls eine Platte ausfällt sollte ich eh alle austauschen...
Resterampe
Hab hier noch zwei 64GB USB-Sticks rumliegen, die man auch noch zu Backupzwecken verwursten kann. Die stöpseln wir ein und machen darauf wöchentlich eine Sicherung der wirklich wichtigen Daten (einer Mittwochs, einer Sonntags). Rsync & Cron sind dabei unsere Freunde.
Samba
Die Fileshares sind schnell eingerichtet. Die Qnap soll ein reiner Fileserver werden, alle Shares erhalten RW als Gast, AD/LDAP brauche ich nicht, bin normalerweise allein in meinem LAN unterwegs, evtl. Besucher bekommen über den Gastzugang der Fritzbox Zugriff auf's Internet und kommen nicht in mein Heimsegment. Zuerst setzen wir die Workgroup/Domain in der "/etc/samba/smb.conf":
workgroup = BLUBBER
Die jeweiligen Shares bekommen folgende Berechtigungen (hier mal der beispielhafte Eintrag für EINEN Share):
[ssd]
comment = ssd-share
path = /ssd
guest ok = yes
browsable = yes
writable = yes
create mask = 0666
directory mask = 0777
Dadurch erhalten Verzeichnisse das Ausführungs-Bit (welches notwendig ist) und Dateien bekommen Read/Write (ohne Execute-Bit, hier wird nix direkt vom Netz gestartet).
Wer AD/LDAP benutzen will setzt "domain master" in der smb.conf auf "yes". Ein lokaler Masterbrowser (für Workgroups) kann mit "local master" und "preferred master" gesetzt werden.
SSH-Server
Portforwarding, UPNP oder sonstiger Mist sind auf meinem Router deaktiviert (aka "Fort-Knox-Settings"), aber als zusätzliche Sicherheit editieren wir die "/etc/ssh/sshd_config" um nur lokale Verbindungen zuzulassen. Dafür fügen wir folgende Zeile hinzu:
AllowUsers *@192.168.0.0/24
Hinweis: Wenn wir später die UFW scharf schalten, dann brauchen wir davor natürlich ein "sudo ufw allow ssh".
Datenwiederherstellung
Jetzt müssen wir nur noch die Daten von der externen HDD zurückkopieren, am einfachsten geht das mit Rsync
lsblk
# feststellen welchen namen die externe hdd hat (hier z.B sdh2)
udisksctl mount --block-device /dev/sdh2
rsync -avh --chmod=ugo=rwX --delete /media/bingen/EXOS14TB/ssd/ /ssd/ | tee ~/logs/rsync_from_extern.log
Wir warten also nochmal etliche Stunden bis der Sync-Job beendet ist und dann sind wir fertig!
Hinweis: Geschwindigkeitsrekorde kann man von der mittelalterlichen Hardware natürlich nicht erwarten, aber als Backup-Fileserver tut's das Ding allemal und schneller als das Qnap QTS ist's ebenfalls. :)
Aber..Aber..Cloud?
Wie die meisten hab ich auch S3-Dropbox-GDrive-Onedrive-Konten. Hauptsächlich speichere ich bei den Cloudservices belanglosen Mist (z.B. Gaming Screenshots), einzig und allein um Google, Microsoft und Amazon die Festplatten zuzumüllen. Hehehe.
Aber wenn wir schon dabei sind, dann könnte man auch ein (automatisches) Backup der Dateien von den Cloudservices machen, oder? Zum Glück existiert "rclone" (ist sogar im Debian-Repo) und eventuell beschreibe ich die Vorgehensweise später mal hier. :P
