Synology HyperBackup mit rsync

Veröffentlicht am

RAID ist kein Ersatz für ein Backup, darum sind NAS-Geräte von Synology sinnvollerweise ab Werk mit einem Backup-Program ausgestattet.

Dieses Backup-Programm trägt den wenig bescheidenen Namen “HyperBackup“. Bei manchen DMS-Versionen ist es vorinstalliert, bei anderen muss es offenbar als “App” nachinstalliert werden.

HyperBackup kann die Daten vom NAS zeitgesteuert irgendwo hin kopieren. Wie es sich gehört werden dabei nur die Änderungen zum letzten Backup übertragen. Außerdem kann man nicht nur die letzte sondern auch alle vorherigen Dateiversion wiederherstellen. Als Backup-Medium werden allerlei kommerzielle Dienste von Amazon über Google zu Microsoft angeboten. Wer keine Lust hat seine Daten auf fremde Server zu schieben kann einen USB-Stick (wenig praktikabel) oder einen rsync-Server verwenden.

Die Doku von Synology ist zu rsync etwas dürftig, ein bisschen rumprobieren verrät dann, dass HyperBackup ganz normal rsync über ssh zum Zielsystem tunnelt (à la rsync -e ssh <quelle> <ziel>).

Auf dem Zielsystem muss kein rsync-Dämon laufen. Die rsync-Ports können geschlossen bleiben, nur der ssh-port (22, tcp+udp) muss geöffnet sein.

HyperBackup verwendet keine Verzeichnisangabe für das Ziel, sondern den Namen eines sog. Backup-Moduls. Backup-Module werden auf dem Zielsystem unter /etc/rsyncd.conf eingetragen:

charset: utf-8
[backup-von-synology]
   path = /data/hyperbackup-backup
   comment = Backup von Synology NAS
   use chroot = true
   uid = root
   gid = root
   read only = false

Hier wird ein rsync-Backup-Modul namens “backup-von-synology” erstellt, bei dessen Verwendung ins Verzeichnis “/data/hyperbackup-backup” gesichert wird.

Nur noch schnell auf dem Zielsystem einen Benutzer anlegen und ihm Schreibrecht auf den Backup-Pfad geben, fertig.

 

Sollte das Zielsystem ein Netgear ReadyNAS sein, kann man sich die Konfiguration einfach in dessen Weboberfläche zusammenklicken:

  1. Neuen User anlegen und SSH-Shell-Zugriff erlauben
  2. Share anlegen (Name des Shares = rsync-Modulname)
  3. Dem neuen User Schreibrechte auf den neuen Share geben
  4. Den Share außerdem für Rsync  (lesen+schreiben, keine Benutzerrestriktionen) freigeben

Auf Snapshots kann verzichtet werden, die macht HyperBackup selbst.

 

Einstellungen in HyperBackup:

Servertyp: rsync-kompatibler-server

Servername oder IP-Adresse: <Servername>

Übertragungsverschlüsselung: Ein

Port: 22

Benutzername: <benutzernameAufZielsystem>

Passwort: <passwortDesBenutzers>

Backupmodul: backup-von-synology

Verzeichnis: Synology-Backup (wird dann unterhalb des Backup-Modul-Verzeichnisses automatisch angelegt, kann auch leer gelassen werden)

 

Debian Linux auf IBM RS/6000 44P-170

Veröffentlicht am

Die IBM 44P-170 ist eine Low-End-Unix-Workstation aus den 2000ern, die vor allem für CAD eingesetzt wurde. Damaliger Listenpreis: stolze 30.000 USD.

Hardware

Der Prozessor, ein IBM POWER3-II, ist auf einer Steckkarte untergebracht, die sich beim Transport gerne lockert. Der Rechner bleibt dann beim Hochfahren (was gut und gerne bis zum Erscheinen des OpenFirmware-Bildschirms 5 Minuten dauert) mit “E0…” im 7-Segment-Display stehen.

In Linux 3.17 wurde die Unterstützung für diesen Prozessortyp entfernt – nachdem sie schon einige Versionen davor nicht mehr funktioniert hat.

Den Rechner gab es mit verschiedenen Grafikkarten: GXT3000P, GXT4000P, GXT4500P, GXT6000P und GXT6500P. Linux-Kernel vor Linux 3.8 unterstützen davon nur GXT4500P und die GXT6000P. In Linux 3.9 kam Unterstützung für GXT4000P und GXT6500P dazu, der Patch funktioniert jedoch auch mit älteren Kernel-Versionen. 3D-Beschleunigung darf man nicht erwarten, es wird nur der Framebuffer-Modus unterstützt.

Sowohl unter AIX als auch unter Linux startet der Rechner mit diesen Grafikkarten mit einer Auflösung von 1280×1024@60Hz.

IBM hatte außerdem einige umgelabelte Grafikkarten von anderen Herstellern im Angebot, die von AIX und Linux unterstützt werden: GXT2000P (3D Labs Permedia 2), GXT110P (S3 Trio64V+), GXT120P (Matrox Millenium I), GXT130P (Matrox Millenium II) und GXT135P (Matrox G450).

Debian-Installation

Die Linux-Installation mit einer nicht unterstützten Grafikkarte ist möglich, nur etwas umständlicher: Man kann sich mit einen zweiten Rechner über die serielle Schnittstelle mit der 44P-170 verbinden. Ich habe das nicht ausprobiert, sondern mir für etwa 15€ eine GXT135P besorgt.

Sobald man weiß, welches CD-Image bootet und ob die aktuelle Grafikkarte von jeweiligen Kernel unterstützt wird, ist die Debian-Installation einfach:

Von Debian 6 zu 7 zu 8 zu 9

Die letzte funktionsfähige Debian-CD ist das Netinst-Image von Debian 6: https://cdimage.debian.org/mirror/cdimage/archive/6.0.10/powerpc/iso-cd/debian-6.0.10-powerpc-netinst.iso

Runterladen, auf CD brennen, booten.

Beim Bootprompt “install64” wählen.  Während der unspektakulär verlaufenden Installation als Spiegelserver “archive.debian.org” eintragen und als Bootloader “yaboot” auswählen. Debian 6 installiert Kernel 2.6.32.

Danach auf Debian 7 upgraden: Dazu in /etc/apt/sources.list die Quellen von “squeeze” durch die von “wheezy” ersetzen, apt-get update && apt-get dist-upgrade. Debian 7 installiert Kernel 3.2.

Weiter zu Debian 8 – der letzte Debian-Version offizieller PowerPC64-Unterstützung: In /etc/apt/sources.list die Quellen von “wheezy” durch die von “jessie” ersetzen, apt-get update && apt-get dist-upgrade. Debian 8 installiert Kernel 3.9. Achtung: Dieser Kernel hängt beim Booten mit SCSI-Resets und ist damit unbrauchbar. Am Besten gleich wieder deinstallieren! Der alte Kernel 3.2 von Debian 7 funktioniert jedoch auch unter Debian 8.

Trotz Einstellung des offiziellen Debian-PowerPC64-Zweiges gibt es noch neue Debian-Pakete in Debian 9 (“stretch”), nur nicht mehr in “stable”, sondern nur noch in “unstable”.

Eigener Kernel

Da meine Workstation ursprünglich mit einer GXT4000P kam, habe ich mir selbst einen Kernel kompiliert aus den Quellen des Kernel 3.2 von Debian 7, ergänzt um den GXT4000P/6500P-Support-Patch. Hier das Kernel-Paket: linux-image-3.2.78_1.0.geierb~ppc64gxt_powerpc.deb

Yaboot

Beim Booten sucht die OpenFirmware auf der Festplatte nach einer PReP-Bootpartition (die wird bei der Debian-Installation automatisch angelegt) und startet, was auch immer da drin liegt.

Yaboot legt dort ein anhand von /etc/yaboot.conf konfiguriertes Binary ab, das ein simples Menü anzeigt, Kernel und Ramdisk aus /boot lädt und startet.

Die Datei /etc/yaboot.conf erinnert ein wenig an die GRUB-Konfigurationsdatei und ist größtenteils selbsterklärend. Man kann Kernelparameter eintragen, Kernelimage und initrd, usw.

Wenn /etc/yaboot.conf geändert wurde , muss ein neues Binary in die PReP-Bootpartition geschrieben werden. Dazu einfach den Befehl ybin -v ausführen.

Um den Kernel laden zu können muss yaboot das Dateisystem verstehen, auf dem /boot liegt. Man hat die Wahl zwischen ext2, ext3 und ext4.

Was nicht geht

Sound. Sound geht nicht. Auf dem Mainboard ist ein Crystal CS4236B-Soundchip verbaut, der per ISA-Bridge angebunden ist. Der PowerPC64-Kernel unterstützt leider kein ISA – auch nicht, wenn man die Unterstützung per Patch reinzwingt und die richtigen Modul-Parameter für den Soundchip kennt (port=0x534, cport=0x538, irq=5, mpu_port=0x330, mpu_irq=9, fm_port=0x388, dma1=1, dma2=3). Ich habe es nicht geschafft, den Rechner mit einem 32-Bit-Kernel zu starten. Der könnte mit ISA umgehen.

Als Abhilfe bietet sich eine PCI-Soundkarte mit Crystal CS4281-Chip an. IBM verkaufte diese für die Intellistation-Workstations als “IBM 8244 AudioPCI”. Die funktioniert sowohl unter AIX als auch Linux.

Fazit

Wenn man weiß wie es geht ist es einfach, der Weg dahin jedoch ziemlich steinig. Steinig im Sinne von zeitaufwändig: Die lange Boot-Dauer macht das Ausprobieren ziemlich nervig.