Beim Backup stehen sich heute zwei technische Ansätze gegenüber: umfassende Suiten und spezialisierte Kleinprogramme. SEP Sesam Jaglion v2 gehört zweifelsfrei zu den Alleskönnern, zeigt im Test aber kritische Detailschwächen.
“Keiner will Backups – alle wollen Restore”, so lautet ein Bonmot in der IT-Industrie, das im Kern durchaus ein Fünkchen Wahrheit enthält. Wenn der Administrator aus Versehen wichtige Daten ins Jenseits befördert hat oder ein RAID-Controller in einer zentralen Maschine den Geist aufgibt und die von ihm verwalteten Daten mitreißt, ist ein funktionierendes Backup oft Gold wert.
Damit es in solchen Situationen parat ist, muss der Administrator allerdings einige Vorarbeit leisten und dafür sorgen, dass Sicherungen der wichtigen Daten einer Installation regelmäßig entstehen und auch so gelagert werden, dass sie sich im Falle eines Falles schnell nutzen lassen. Dass der Verlust unternehmenskritischer Daten im schlimmsten Falle einer Firma das Genick brechen kann, ist eine allgemein bekannte Tatsache. Welche Konsequenzen sich daraus für das Thema Backup herleiten, daran entzünden sich allerdings vielerorts schon wieder heftige Kontroversen.
Traditionell treten am Markt zwei Familien von Software gegeneinander an, wenn es um das Thema Backups geht. Kategorie A umfasst kleine, hoch spezialisierte Werkzeuge, die von einzelnen Programmen Sicherungen anlegen, etwa von Datenbanken oder bestimmten Anwendungen wie Gitlab. Ihnen stehen die eierlegenden Wollmilchsäue gegenüber, die so viel Backup-Funktionalität wie möglich unter einer einheitlichen Oberfläche vereinen und Admins das Wunschlos-glücklich-Paket versprechen. Beide Ansätze haben durchaus ihren Reiz: Auf eine Aufgabe spezialisierte Tools bieten häufig einen größeren Funktionsumfang als die Einzelteile einer riesigen Lösung, die eben auch die jeweils betroffene Software umfasst. Dafür sind das Setup und der Betrieb aber auch kleinteiliger und aufwendiger als das einmalige Einrichten eines Backup-Alleskönners.
Zur letzteren Kategorie gehört definitiv SEP Sesam Jaglion [1], das kürzlich in der neuen Version 2 erschienen ist. Der Hersteller SEP ist am deutschen Backup-Markt alles andere als ein Unbekannter und mit seinen Lösungen seit vielen Jahren aktiv. Zusammen mit BareOS, dessen Fork Bacula sowie Acronis handelt es sich bei SEP Sesam um einen der großen Player am Markt der auch für Linux geeigneten Lösungen. Entsprechend war die Lösung im Linux-Magazin bereits einige Male Thema, zuletzt im Juni 2020.
Wer den Werdegang von SEP Sesam verfolgt, merkt schnell, dass der Hersteller SEP sich auf seinen Lorbeeren nicht ausruht, sondern seine Lösung kontinuierlich erweitert und mit neuen Funktionen anreichert. Grund genug, sich die neuesten Entwicklungen und Features der gerade frisch erschienenen Version von SEP Sesam Jaglion im Detail anzusehen.
Namenskonfusion
Jaglion mag als Name für das Produkt im ersten Augenblick etwas sperrig klingen, doch leuchtet die Bezeichnung durchaus ein, kennt man den Hintergrund. Bei Sesam Jaglion handelt es sich um das fünfte Backup-Produkt der SEP AG und mithin um den unmittelbaren Nachfolger von Sesam Hybrid. Jaglion ist laut Anbieter ein Kofferwort aus Jaguar und Lion, eine Kombination also aus einer besonders mächtigen und einer besonders schnellen Katze – und genau so will der Anbieter sein Produkt verstanden wissen.
Zwar ergeben sich in Jaglion v2 Unterschiede zur ersten Jaglion-Version, doch erscheint es an dieser Stelle sinnvoller, sich zunächst mit der grundlegenden Architektur von Sesam in der fünften Variante zu befassen und die Grundfunktionen zu beleuchten. Das “hybrid” bezieht sich beim Programm nicht nur auf die Kombination aus Vielfalt und Performance, sondern auch und gerade auf die nutzbaren Backup-Quellen.
Endlose Möglichkeiten
Wie bisher auch teilt die Architektur von SEP Sesam sich in eine Server-Komponente sowie verschiedene Agents auf, die je nach Backup-Quelle auf unterschiedlichste Arten zum Einsatz kommen.
Kräftig überarbeitet hat SEP vor allem die Benutzerschnittstelle in Sesam Jaglion (Abbildung 1), die nun deutlich moderner daherkommt und nicht mehr den altbackenen Esprit alter Java-Anwendungen versprüht. Obendrein ist sie flexibler geworden: War es in früheren Sesam-Versionen vorrangig der Admin, der zur Tat schritt, lassen sich mittlerweile durchaus auch Sesam-Accounts an weniger erfahrene Anwender herausgeben. Die können dann Sicherungen ihrer eigenen Anwendungen anfertigen, ohne dem Administrator damit zur Last zu fallen – Lifecycle-Management und Cloud lassen grüßen.

Abbildung 1: SEP Sesam Jaglion kommt unter anderem mit einer komplett überarbeiteten GUI daher, zu der der hier gezeigte Restore-Assistent für das schnelle Wiederherstellen von Daten gehört. Quelle: SEP
Möglich macht das unter anderem eine runderneuerte Schnittstelle auf Basis von HTTP und HTML, die es erlaubt, Sesam auch ohne unmittelbaren Zugriff auf die Server-Software von außen mit Anweisungen zu versorgen. Hier ist erkennbar, dass SEP dem API-Prinzip folgt und Sesam sich langsam in Richtung eines API-basierten Diensts entwickelt.
Zusammen mit Features dieser Art liefert der Hersteller alles in Sachen Compliance und Sicherheit Notwendige mit. An bestehende Benutzerverzeichnisse lässt sich SEP Sesam wie schon bisher anschließen. Auch das Schaffen lokaler oder verzeichnisbasierter Gruppen von Nutzern mit vordefinierten Rechte-Sets unterstützt es weiterhin (Abbildung 2).

Abbildung 2: In Sachen Sicherheit und Compliance erlaubt SEP Sesam sich keinen Lapsus. Lokale Benutzer sind ebenso möglich wie solche aus zentralen Verzeichnissen, samt zentralisierter Rechtevergabe. Quelle: SEP
Im Interesse der Separation of Concern, also der strikten Trennung von Verantwortlichkeiten für unterschiedliche Backup-Quellen, ist das unbedingt notwendig, wenn Sesam den Service-Charakter haben soll, den der Anbieter verspricht. Der spielt bei Jaglion insgesamt eine große Rolle, wie die Anspielung auf ein hybrides Tier im Namen deutlich macht: SEP Sesam soll eben nicht nur die Anwendung für lokale Backups etlicher Programme sein, sondern virtuos auch Daten aus der Cloud und in der Cloud sichern.
Perfekte Basics
Cloud hin, APIs her – in den meisten Einsatzszenarien für SEP Sesam werden Admins sich vor allem solide Backups lokaler Anwendungen erhoffen. Hier leistet SEP Sesam sich kaum Schwächen: Sämtliche Linux-Distributionen lassen sich mittels entsprechender Agenten ebenso in Backup-Quellen verwandeln wie diverse Anwendungen.
Der Hersteller trägt hier dem Umstand Rechnung, dass die klassischen Vollsicherungen heute vielerorts ausgedient haben. Wo es früher Usus war, ganze virtuelle Maschinen in Backups zu packen, liegt der Fokus heute stattdessen auf den Nutzdaten der Anwendungen in den VMs. Ähnliches gilt für Anwendungen, die Unternehmen aus Sicherheits- oder Performance-Gründen nicht in VMs betreiben: Auch hier sichert man heute eher nicht mehr das gesamte Datenbanksystem, sondern nur die Inhalte von PostgreSQL, MariaDB oder MS SQL. In vielen Firmen steht ja mittlerweile ein umfassendes Lifecycle-Management zur Verfügung, mit dem sich Grundsysteme jederzeit aus der Dose wiederherstellen lassen. Meist geht das sogar deutlich schneller, als ein komplettes System aus einem Backup zurückzuholen. Wer noch nicht so modern unterwegs ist, findet in SEP Sesam aber auch die Möglichkeit, ganze Systeme zu sichern.
Passend dazu ermöglicht SEP Sesam auf Wunsch auch den Zugriff auf verschiedene Ebenen etwa eines Virtualisierungs-Stacks. Mit KVM, VMware oder Nutanix (Abbildung 3) redet die Anwendung dabei auf Anweisung ebenso wie direkt mit Linux-Kerneln. Alle gängigen Linux-Distributionen gehören dabei zum Lieferumfang. Die aktuelle Version 2 von Jaglion hat allerdings ein paar alte Zöpfe abgeschnitten und Unterstützung für ältere Distributionen entfernt. Das betrifft etwa Ubuntu 16.04, das allerdings in den meisten Fällen ohnehin keinen Hersteller-Support mehr genießt und deshalb kaum noch irgendwo aktiv im Einsatz ist.

Abbildung 3: Ganze Systeme lassen sich mit SEP Sesam entweder aus dem System heraus oder – bei VMs – auf der Ebene des Hypervisors nutzen. Quelle: SEP
Zwei Editionen
Grundsätzlich unterteilt SEP sein Produkt in zwei Varianten, nämlich die Professional- und die Ultimate-Edition. Letztere bietet Agenten für Spezialsoftware wie IBM DB2 oder diverse SAP-Produkte. Admins, die solche Produkte betreuen, greifen vermutlich schon intuitiv und aus Gewohnheit zur deutlich teureren Ultimate-Edition. Für das Gros der Umgebungen dürfte die Professional-Edition aber ausreichen. Sie deckt die meisten alltäglichen Szenarien ab.
Zu den bereits erwähnten Linux-Distributionen und Anwendungen kommen hier auch Backup-Module für die Daten in diversen Public Clouds hinzu, die SEP Sesam unmittelbar per API ansteuern kann. Dieses Feature dürfte vermutlich eher aus Sicht des Endanwenders als aus Sicht des Admins im Rechenzentrum interessant sein. Immerhin ermöglicht SEP Sesam es aber, dass Unternehmen wirklich eine kohärente Strategie im Hinblick auf ihre Backups fahren, statt einzelne Anwender zu Insellösungen für ihre jeweiligen Daten zu zwingen.
Viele Backup-Ziele
Praktisch funktioniert SEP Sesam nach einem relativ einfachen Prinzip. Auf dem Server definiert der Administrator Backup-Jobs, die drei Faktoren umfassen: die zu sichernden Daten, deren Herkunftsort sowie das Ziel für die Sicherung. Bei den Backup-Zielen leistet SEP Sesam sich wenig überraschend kaum einen Lapsus. Prinzipiell eignet sich alles, was sich von einem Linux-System (dem mit SEP Sesam) als Blockgerät oder über einen Netzwerkpfad ansprechen lässt, potenziell als Ziel für Sicherungsdaten (Abbildung 4).

Abbildung 4: Praktisch alles, was unter Linux oder auf diversen Appliances als Block- oder Netzwerkgerät darstellbar ist, lässt sich in SEP Sesam als Ziel nutzen. Quelle: SEP
Mittlerweile bietet SEP Sesam zudem Unterstützung für diverse Netzwerk-Appliances. Liest man allerdings das Marketingmaterial des Herstellers, gelangt man fast zwangsläufig zur Feststellung, dass SEP die Cloud-Ambitionen seiner neuen Sesam-Version fast am wichtigsten sind. Auch hier liefert der hybride Charakter des Produkts zweifelsohne wieder einen Fingerzeig, und in der Praxis wirken die Cloud-Fähigkeiten von SEP Sesam sich konkret aus.
Wer etwa mit der Herausforderung zu tun hat, Daten von einem Standort an einem unabhängigen zweiten Standort abzulegen, denkt dabei intuitiv womöglich zuerst an Lösungen wie Amazon S3. Folgerichtig implementiert SEP Sesam gleich mehrere Varianten für Backups auf S3. Die alte Option firmiert unter der Bezeichnung Si3 Deduplication, die neuere bekommt ein NG für Next Generation an den Namen angehängt.
Technisch unterscheiden sich die zwei Ansätze allerdings fundamental. Beide unterstützen zwar Deduplizierung, filtern also aus den zu sichernden Daten doppelte Informationen heraus (und können solche Backups später bei Bedarf auch wieder adäquat einspielen). Die erste Generation des S3-Backups bei Sesam bot allerdings erst gar nicht die Möglichkeit, Daten unmittelbar auf AWS S3 abzulegen. Stattdessen definierte der Admin umständlich für bestehende Backup-Jobs eine Spiegelung hin zu S3, sodass die Daten lokal wie remote verfügbar waren.
Die neue Art der Implementierung, also die NG-Version, geht deutlich hemdsärmeliger zu Werke. Hier lässt sich S3 als unmittelbares Backup-Ziel angeben. Insbesondere bei der kürzlich erschienenen Version 2 von Jaglion hat der Anbieter die Si3-Funktionalität der NG-Variante noch einmal deutlich nachgebessert. Auf Zuruf verschlüsselt Jaglion nun etwa Daten, bevor es sie auf S3 hochlädt.
Was wie ein technisches Detail klingt, dürfte in vielen Firmen überhaupt erst die Möglichkeit eröffnen, SEP Sesam für Backups auf S3 einzusetzen. Liegen die Daten verschlüsselt in S3, nützen sie einem Angreifer selbst dann nichts, wenn er physischen oder digitalen Zugriff auf den gesamten Datensatz erhält. Nicht verschlüsselte Daten hingegen wären für jeden frei lesbar, was in vielen Compliance-Abteilungen die Wahrscheinlichkeit gegen null gedrückt haben dürfte, die Funktion in Jaglion 1 überhaupt zu nutzen. Es ist dem Anbieter insofern hoch anzurechnen, dass er diese Möglichkeit schnell nachgereicht hat (Abbildung 5).

Abbildung 5: Si3 NG bietet Replikation direkt in AWS S3 und kann Backups verschlüsselt ablegen, sodass Datensicherheit und Compliance kein Problem darstellen. Quelle: SEP
Zwischenbilanz
Bis hierhin ist klar: Bei den Grundfunktionen, die Administratoren von einer großen und umfassenden Backup-Lösung wie SEP Sesam Jaglion erwarten, leistet das Produkt sich kaum Schnitzer. Bei den Quellen des Backups herrscht eine ebenso große Wahlfreiheit wie bei dessen Zielen. Zeitgemäße Features wie verschlüsselte Sicherungen in der Cloud funktionieren und sind sinnvoll in alle Abläufe der Software integriert. Dabei fällt auf, dass insbesondere neuere Features wie das verschlüsselte Sichern in AWS S3 umsichtig implementiert und technisch gut umgesetzt wurden.
Der Eindruck setzt sich in anderen Themenbereichen fort. Früher mussten Admins beispielsweise beim Anlegen von Backups den Aspekt des Datenschutzes kaum im Hinterkopf haben. Das ist heute anders, denn die DSGVO propagiert den strikten Grundsatz der Datensparsamkeit und schreibt vor, nicht mehr benötigte Daten zu löschen. Wer etwa in seinen Backups aus grauer Vorzeit noch immer Daten über ehemalige Kolleginnen und Kollegen speichert, die mittlerweile gar nicht mehr im Unternehmen arbeiten oder womöglich bereits verstorben sind, hat zweifelsohne einige interessante Gespräche vor sich, wenn der jeweils zuständige Datenschutzbeauftragte genauer hinsieht.
Auch hier versucht SEP Sesam, Administratoren zu unterstützen. Bei Datenbanken etwa lässt sich fein abgestuft festlegen, welche Daten ins Backup sollen. SEP hat dabei durchaus auch Randthemen im Hinterkopf, die viele Admins gar nicht als potenzielles Problemfeld wahrnehmen. Oft genügt es etwa nicht, alte Sicherungen zu löschen, wenn – wie es bei Tapes häufig vorkommt – deren Metadaten erhalten bleiben. Auch die stellen potenzielle Datensenken dar und können Daten enthalten, die sich längst im Orkus befinden müssten. Jaglion V2 bietet deshalb explizit die Option, Metadaten von Bandlaufwerken beim Löschen von Backups vollständig und sicher zu beseitigen. Die Features mit DSGVO-Bezug in Sesam Jaglion sind insgesamt eher neu, und hier setzt sich einmal mehr der Eindruck fort, dass der Hersteller seine neuen Features und ihre Entwicklung im Griff hat.
Der Vollständigkeit halber sei erwähnt, dass gerade beim DSGVO-konformen Speichern und Löschen von Backups der Anbieter den Administrator nur im Rahmen seiner Möglichkeiten zu unterstützen vermag. Legen spezielle Userland-Anwendungen etwa ihre Daten in eigenen, womöglich proprietären Formaten ab, in die SEP Sesam nicht hineinsehen kann, ist es weitgehend machtlos. Dass die von Jaglion gebotenen Funktionen den Administrator nicht vom Mitdenken und Aufpassen entbinden, muss aber klar sein – hier ergibt sich also kaum ein Grund, den Hersteller zu rüffeln.
Altbekannte Probleme
Sehr wohl Grund zur Klage ergibt sich allerdings, sieht man sich einige der Features und Probleme an, die SEP Sesam gewissermaßen seit langer Zeit mit sich herumschleppt. An zwei Beispielen lässt sich das gut verdeutlichen. Das erste betrifft eine Funktion, die SEP als “Disaster Recovery” bezeichnet. Das Feature war bereits im letzten Artikel Anlass zur Kritik.
Was SEP Sesam mit Disaster Recovery meint, hat nichts mit der Funktionalität zu tun, die Admins intuitiv unter dem Schlagwort erwarten. Disaster Recovery bedeutet in SEP Sesam, dass die Software gewissermaßen ein Backup von sich selbst an einem anderen Standort ablegen kann. Damit lässt sich, falls ein Standort unbrauchbar wird, eine komplette SEP-Sesam-Installation mit derselben Konfiguration wie am alten Standort in verhältnismäßig kurzer Zeit wiederherstellen. Sofern nun noch die Nutzdaten der Backup-Ziele am anderen Standort ebenfalls vorhanden sind, ermöglicht es die Funktion, im neuen RZ Systeme mit der Konfiguration des untergegangenen Standorts schnell wiederherzustellen.
Gerade in Setups mit hohem Automationsgrad dürfte ein Teil dieser Funktionalität jedoch obsolet sein. Wer am zweiten Standort Lifecycle-Management betreibt und beispielsweise das Gitlab-Verzeichnis mit der Konfiguration seiner Automation permanent von der primären Site spiegelt, erhält vergleichbare Funktionalität, erspart sich im Falle eines Falles aber sogar das Aufsetzen von SEP am neuen Standort. Seine Nische findet SEP Sesam hier vor allem bei jenen Anwendungen und Applikationen, die sich nicht ohne Weiteres automatisieren lassen und bei denen die Trennung zwischen Metadaten und den generischen Programmdateien schwerfällt. Gerade in diesen Situationen kann ein Feature wie SEPs sogenannte Disaster Recovery durchaus hilfreich sein.
Die Industrie versteht unter dem Begriff allerdings gemeinhin ein Setup, mit dem sich ein Standort innerhalb weniger Minuten oder gar nur Sekunden in Betrieb nehmen lässt, nachdem ein anderer Standort ausgefallen ist. Es geht also weniger um Datensicherung als um Verfügbarkeit, und damit hat SEP Sesam eher wenig zu tun. Zwar bietet die Software auch Replikationsfunktionen etwa via AWS S3, doch vom Umschalten in kürzester Zeit kann auch hier kaum die Rede sein.
In der Praxis dürften die Auswirkungen der eher begrifflichen Ungenauigkeiten in SEP Sesam überschaubar sein. Admins, die ein teures Setup über mehrere Standorte mit Fail-over-Funktionalität betreiben, wissen in der Regel sehr gut, welche Daten es wann, wo und wie zu replizieren gilt. Mehr sprachliche Klarheit wäre hier allerdings dennoch sinnvoll.
Die leidige Doku
Das zweite, ungleich größere Problem, das SEP Sesam seit Jahren mit sich herumschleppt, betrifft den Zustand seiner Dokumentation. Eine so umfassende Backup-Lösung lässt sich ungeachtet der neuen GUI kaum intuitiv bedienen. Das gilt umso mehr, wenn Sonderfunktionen wie verschlüsselte S3-Backups oder Disaster Recovery zum Einsatz kommen sollen. Auch bei den Basisfunktionen dürften selbst erfahrene Administratoren in SEP Sesam wie bei jeder anderen Software eine kurze Phase der Eingewöhnung und des Zurechtfindens benötigen. Dabei dürfen sie zu Recht erwarten, dass der Hersteller ihnen mit guter, verständlicher, klarer und faktisch korrekter Dokumentation unter die Arme greift.
Der Zustand der SEP-Sesam-Dokumentation gibt indes zumindest Grund zur Sorge. Heute hat es sich allgemein eingebürgert, die eigene Dokumentation auf einer Webseite getrennt nach den verschiedenen Versionen mit Aufklappmenü zu pflegen. SEP Sesam geht seit Jahren einen anderen Weg und setzt auf ein Wiki, in dessen Hintergrund Mediawiki werkelt, also die Software, die auch die Wikipedia betreibt. Das ist per se nichts Schlechtes, führt jedoch dazu, dass Features wie die Auswahl einer Dokumentation für eine spezifische Version schlicht nicht zur Verfügung stehen.
Das Ergebnis ist absehbar: Gibt man in die Suchmaske der Dokumentation einen bestimmten Begriff ein, findet man etliche Seiten mit fast identischem Seitennamen, durch die man sich durchklicken muss, bis man die passende Seite für die eigene Version findet. Oder zumindest gefunden zu haben glaubt, denn weitere Faktoren erschweren das Verständnis der Dokumentation erheblich. Zum Teil liegt sie etwa in deutscher und zum Teil in englischer Sprache vor, und die Auswahl trifft das Wiki von SEP anhand der Einstellungen im Webbrowser des Nutzers. Das führt im ungünstigsten Fall dazu, dass man eine deutsche Seite sieht, obwohl dieselbe Version in englischer Sprache aktuellere Details enthielte. Ein Hinweis darauf findet sich lediglich in Form einer kleinen Notiz ganz oben auf der Seite, die man im Eifer des Gefechts schnell übersieht.
Obendrein fällt auf, dass sich die fehlende klare Menüstruktur und der Versuch, die Übersicht durch Versionsnummern in Wiki-Seitentiteln zu erhalten, fatal auf den Lesefluss und die Auffindbarkeit von Informationen auswirken. Optische Gestaltungselemente tun ihr Übriges. Besteht eine Wiki-Seite zu einem Thema aus etlichen kommentierten Screenshots unterschiedlicher SEP-Versionen und vielen roten Warnkästen in einer sehr unübersichtlichen Struktur, wirft irgendwann selbst der geduldigste Admin das Handtuch.
Hier gibt es nichts zu beschönigen: Der Versuch, die SEP-Dokumentation in einem Wiki so zu pflegen, wie SEP es augenblicklich tut, ist gescheitert und lässt sich vermutlich auch nicht mehr retten. Es stünde dem Anbieter gut zu Gesicht, bei einer der nächsten Versionen die Dokumentation des Produkts zu einem Hauptaspekt zu machen und einen neuen Anlauf zu wagen, der sich an den Standards der Gegenwart orientiert.
Fazit
SEP Sesam Jaglion präsentiert sich als umfangreiche Backup-Software für beinahe alle Lebenslagen, die ihren Hauptkonkurrenten weder in Sachen Funktionalität noch in Sachen Performance nachsteht. Gerade die neueste Version v2 hat bei der Geschwindigkeit etwa in Sachen AWS-S3-Backup ganz erheblich zugelegt und befindet sich auf Augenhöhe mit den anderen Standardlösungen der Branche. Dass die Ultimate-Version auch Sonderagenten für Nischensoftware wie SAP HANA oder IBM DB2 bietet, untermauert den universellen Anspruch des Produkts und verstärkt den Eindruck seiner hohen Qualität.
Abzüge gibt es allerdings in der B-Note. Eine Software wie SEP Sesam lässt sich ohne eine gute, durchgängig verständliche Dokumentation kaum meistern. Auszureizen ist der volle Funktionsumfang der Software jedenfalls nicht, wenn der Admin nicht verlässlich nachschlagen kann, welcher Haken im GUI welche Funktion liefert und auf welche speziellen Details es zu achten gilt. Hier steht SEP Sesam sich unnötig selbst im Weg. Es bleibt zu hoffen, dass der Anbieter diesen Missstand umgehend beseitigt. Umfang und Funktionen von SEP Sesam Jaglion jedenfalls rechtfertigen eine ordentliche Dokumentation, deren Fehlen im Grunde den einzigen großen Nachteil des Produkts darstellt. (jcb/jlu)
Infos
- SEP Sesam Jaglion v2: https://www.sep.de/sep-sesam/sep-sesam-jaglion/





