Basic Backup – 3rdParty App für Synology NAS (DSM 7)

Tommes

Well-known member

Basic Backup – 3rdParty App für Synology NAS (DSM 7)​


Basic Backup ermöglicht eine GUI gestützte, dateibasierte Datensicherung auf Grundlage von rsync, sowie ein Versionsbackup nach dem Generationenprinzip unter Verwendung von Hardlinks. Mögliche Datensicherungsquellen sowie Ziele sind neben internen Volumes und extern an eine DiskStation angeschlossene USB/SATA-Datenträger, auch über SSH verbundene, rsync fähige Remote Server.

GitHub Repository: https://github.com/toafez/BasicBackup

Systemvoraussetzungen​


BasicBackup wurde speziell für die Verwendung auf Synology NAS Systemen entwickelt die das Betriebsystem DiskStation Mangager 7 verwenden.

Installationshinweise​


Laden Sie sich die jeweils aktuellste Version von Basic Backup aus dem Bereich GitHub Releases herunter. Öffnen Sie anschließend im DiskStation Manager (DSM) das Paket-Zentrum, wählen oben rechts die Schaltfläche Manuelle Installation aus und folgen dem Assistenten, um das neue Paket bzw. die entsprechende .spk-Datei hochzuladen und zu installieren. Dieser Vorgang ist sowohl für eine Erstinstallation als auch für die Durchführung eines Updates identisch.

Updatehinweise​


Nach dem starten von BasicBackup wird die installierte Version mit der auf GitHub verfügbaren Version verglichen. Steht ein Update zur Verfügung, wird der Benutzer über die App darüber informiert und es wird ein entsprechender Link zu dem Release eingeblendet. Der Download sowie der anschließende Updatevorgang wurde bereits unter dem Punkt Installationshinweise erläutert.

Versionsgeschichte​


Details zur Versionsgeschichte finden Sie in der Datei CHANGELOG.

Entwickler-Information​


Lizenz​


Dieses Programm ist freie Software. Sie können es unter den Bedingungen der GNU General Public License, wie von der Free Software Foundation veröffentlicht, weitergeben und/oder modifizieren, entweder gemäß Version 3 der Lizenz oder (nach Ihrer Option) jeder späteren Version.

Die Veröffentlichung dieses Programms erfolgt in der Hoffnung, daß es Ihnen von Nutzen sein wird, aber OHNE IRGENDEINE GARANTIE, sogar ohne die implizite Garantie der MARKTREIFE oder der VERWENDBARKEIT FÜR EINEN BESTIMMTEN ZWECK. Details finden Sie in der Datei GNU General Public License.
 
Da hat sich ja wer richtig Mühe gegeben. Respekt. (y)
Ich bin auf dem produktiven System noch mit DSM 6.2.4 unterwegs.
Aber ab DSM > 7 möchte ich mir das schon angucken. Evtl. finde ich ja wieder einen Bug. :)
 
Vielen Dank. Dank GitHub habe ich noch ein paar graue Haare dazu bekommen. Da muss man sich auch erstmal reinfuchsen. Aber gut… für den Moment bin ich selber recht zufrieden und ein wenig von mir selbst überrascht, das ich das überhaupt hinbekommen habe. Aber wer eine pfSense und einen Cisco Switch gebändigt bekommt, der kann es wohl mit jedem System aufnehmen 🤣

Wie schon gesagt… irgendwann wirst auch du updaten wollen… oder müssen 🤣

Und falls du einen Bug finden solltest, darfst du ihn gerne behalten 😋
 
Ne, ich bin immer noch unheimlich stolz auf meinen bei Ultimate Backup gefundenen Bug. Der wurde in einem späteren Update abgefangen.
Und auf Ultimate Change warte ich bis heute. :)
Ja, früher oder später were ich updaten müssen. Das System ist aber mittlerweile zu vielfältig eingebunden und in Benutzung.
Also lieber später. :LOL:
 
[RETRO]
Damals… als Ultimate Backup noch voll im Saft stand, haben die Macher heimlich im Hintergrund über ein Jahr an der Evolutionsstufe NG für Ultimate Backup Next Generation gearbeitet. Also nix mit Ultimate Change! Das es nie zu einer Fertigstellung sowie Veröffentlichung kam, lag wohl hauptsächlich an mir. Über die Gründe möchte ich mich aber nicht weiter auslassen, das tut auch nichts zur Sache. Ich bin aber immer noch dabei ;)

Mit Erscheinen von DSM 7 war aber auch klar, das weder Ultimate Backup noch Ultimate Backup NG den Sprung schaffen würde. Zu restriktiv waren die Sicherheitsbeschränkungen von DSM 7, das System zu abgeschottet, um als 3rdParty Entwickler so agieren zu können, wie man es bisher getan hat. Es musste also ein komplett neuer Ansatz, ein neues Vorgehen und somit eine komplette Neuausrichtung her. Da das am Ende aber nichts mehr mit Ultimate zu tun hatte, konnte der Name so natürlich auch nicht weitergeführt werden. Daher entstand dieses Projekt hier… und ich finde Basic Backup trifft es eigentlich ganz gut, da ich mich auf‘s Wesentliche beschränke.
[/RETRO]


Aber um dir den Umstieg ein wenig schmackhafter zu machen und du vielleicht hier und da das 3rdParty Paket autorun genutzt hast… das kannst du unter DSM 7 mit Basic Backup umsetzten. Ich nenne diese Funktion liebevoll AutoPilot und funktioniert im Prinzip genauso wie autorun… nur das ich wieder eine GUI implementiert habe und man die Protokolle auch über die GUI einsehen kann. Aber was rede ich… bleib du mal schön auf DSM 6 hocken… ätschbätsch
 
Deswegen finde ich das beachtens,- und bewundernswert. So ein Projekt im Grunde nochmal von vorne zu beginnen.
Natürlich hat man schon Erfahrung, aber die Arbeit bleibt trotzdem. Und wenn wir hier eine echte Alternative zu cphub etablieren, wäre das ein großer Gewin für die Community als auch jeden einzelnen.

PS: Ich musste doch tatsächlich gucken was das 3rd Party autorun macht. Noch nie gebraucht und auch nicht vermisst. :D
 
Wer die Syno nutzt nutzt Hyperbackup. Wie auch ich :) Auch um per rsync auf einen rsync Server zu sichern.

Ich faende es gut wenn Du mal beschreiben wuerdest was BasciBackup und Hyperbackup unterscheidet und was die Vorteile und auch ehrlich - was die Nachteile sind ;) So ganz sehe ich momentan nicht warum ich statt Hyperbackup BasicBackup nutzen sollte bzw in welchen Anwendungsfaellen BasicBackup besser ist als Hyperbackup.
 
Ich hole kurz ein wenig aus um zu erläutern, wie es überhaupt dazu kam ein Backup Programm für ein Synology NAS System zu schreiben.

Bis zum DiskStation Manager 5.x gab es ausschließlich eine dateibasierte Datensicherung die auf rsync beruhte. Mit Einführung von DiskStation Manager 6 erblickte auch Hyper Backup das Licht der Welt, nur mit dem Unterschied, das man anfänglich keine dateibasierte- sondern ausschließlich eine datenbankgestützte Datensicherung anlegen konnte. Man war - und ist es bis heute - darauf angewiesen, Backup-Inhalte nur noch über eine, von Synology bereitgestellte Software einzusehen. Wie gesagt, in den Anfängen gab es nur diese Option, was vielen Benutzern - darunter auch mir - ziemlich sauer aufgestoßen ist. Ich denke, das dank des großen Widerstandes der Community es letztendlich dazu geführt hat, das Synology die dateibasierte Datensicherung auf Basis von rsync wieder implementiert hat. In der Zeit dazwischen habe ich damals dazu aufgerufen, ein dateibasiertes Backup Programm ins Leben zu rufen… so entstand dann Ultimate Backup.

Mit Ultimate Backup war es wiederum möglich, nicht nur einfache dateibasierte Datensicherungen durchzuführen, sondern diese auch in verschlüsselten Ordnern auf Basis von ecryptfs zu deponieren, also mit der Technologie, wie Synology heute noch freigegebene Ordner verschlüsselt. Des Weiteren konnte man ein Versionsbackup nach dem Generationenprinzip unter Verwendung von Hardlinks erstellen, was somit ebenfalls dateibasiert und nicht datenbankgestützt erfolgte. Zu guter letzt konnte man sogar ein versioniertes Backup, verschlüsselt auf einem externen Datenträger ablegen, wobei Ultimate Backup den verschlüsselten Ordner eigenständig einhängen und trennen konnte. Es gab aber noch viele weitere Dinge, wie das automatische einrichten von SSH Verbindungen, eine autostart Funktion um Backupaufträge durch einstecken eines extern an die DiskStation angeschlossenen Datenträgers automatisch auszuführen. Ich habe bestimmt noch einiges vergessen, was den Funktionsumfang von Ultimate Backup betrifft… aber es war wirklich, wie der Name schon sagt…ultimativ.

Und dann kam DSM 7… und all die Funktionen, Möglichkeiten und Vorteile waren mit einem Schlag vernichtet. Zu restriktiv waren die Beschränkungen, zu hoch die Auflagen an 3rdParty Developer, systemnahe Befehle ausführen zu können. Mit Einführung von DSM 7 wurde somit das Ende von Ultimate Backup eingeläutet. Genau aus diesem Grund habe ich angefangen Basic Backup zu entwickeln, einfach weil ich es nicht hinnehmen wollte, das all das, was wir einst geschaffen hatten, mit einem Schlag für die Tonne war. Seit dem versuche ich, wenigstens ein paar elementare Dinge zurück zu holen, die mir persönlich sehr am Herzen gelegen haben.

So und nun komm ich zu den Vor- und Nachteilen.

Aktuell sehe ich die Vorteile von Basic Backup hauptsächlich darin, das man neben einer einfachen dateibasierten Sicherung, auch ein Versionsbackup auf Dateiebene anlegen kann. Ebenso halte ich die vor kurzen erst von mir implementierte AutoPilot Funktion für einen weiteren Vorteil gegenüber Hyper Backup. Über die integrierte USB/SATA-AutoPilot Funktion können nämlich sowohl Datensicherungsaufträge als auch sonstige Bash-Scripte automatisch beim Anschluss eines externen USB/SATA-Datenträgers ausgeführt und bei Bedarf im Anschluss wieder automatisch ausgeworfen werden. Wie weiter oben bereits erwähnt, lehnt sich AutoPilot an die 3rdParty App autorun an, die, soweit ich weiß, seit DSM 7 auch nicht mehr richtig funktioniert.

Aber ja... es gibt auch Nachteile… und davon sogar jede Menge. Denn das meiste von dem was Ultimate Backup noch konnte, kann Basic Backup nicht mehr und wird es auch nicht mehr können. Das ist aber hauptsächlich DSM 7 geschuldet. Aber gut. Einer der Hauptnachteile ist wohl eine fehlend Restore Funktion. Ebenfalls kritisch sehe ich, das teilweise Dateirechte und Besitzrechte verändert werden, wenn man ein SSH Push Backup auslöst und man nicht als root am Remote Server angemeldet ist. Ein weiterer Nachteil ist, das man mit Basic Backup nicht mehr auf die Ordnerstrukturen von Remoteservern zugreifen kann, da man über die GUI keine SSH Verbindungen mehr herstellen kann. Man kann über die GUI nicht mal einen Ping abfeuern um zu schauen, ob der Remote Server online ist. Aber…

Mir geht es mittlerweile aber nicht mehr darum, mich mit Hyper Backup zu messen, so wie es in den Anfängen vielleicht noch war. Denn es liegt auf der Hand, das ich an das Level von Hyper Backup nicht mehr herankommen werde. Ich preise mein System auch garnicht groß an, binde es niemandem auf die Nase oder mache einen großen hehl daraus. Letzenendes tu ich das alles nur, weil ich Bock darauf habe… ich muss niemanden etwas beweisen und ich erhebe keinen Anspruch auf Vollkommenheit... auf Perfektion vielleicht aber das ist wieder ein anderes Thema.

Ich hoffe das war ehrlich genug für dich und du kannst mit meinen Ausführungen etwas anfangen. Ich würde mich jedenfalls freuen, wenn du dir mein Programm zumindest einfach mal anschaust um mir ein positives oder negatives Feedback geben zu können. Ich kann nur besser werden, wenn ihr mir dabei helft.

Tommes
 
Vielen Dank fuer Deine Erklarungen.

Ich nutze HB um meine Daten zu sichern und bin damit eigentlich zufrieden. Klar nutzt Syno da eine proprietaere DB aber eigentlich stoert es mich nicht. D.h ich hatte mich gefragt ob es ein Feature von BB gibt welches ich in HB vermisse und deshalb BB einsetzen sollte.

Die Vorteile und Nachteile habe ich jetzt soweit verstanden. Dass der Restore im Tool fehlt macht einen Restore etwas unhandlicher aber es ist nicht unmoeglich.

Um einem unbedarften Nutzer der HB kennt die Unterschiede aufzuzeigen und zu helfen zu beurteilen ob BB fuer ihn hilfreich ist waere meiner Meinung nach eine Tabelle mit 2 Spalten, HB und BB, wo die jeweiligen Features in Zeilen gelistet sind und ob und in wieweit HB oder BB das unterstuetzt. Dadurch kann man sehr schnell sehen wo Unterschiede und Gemeinsamkeiten sind. Eventuell noch als dritte Spalte UB dazunehmen. Dann koennen auch Nutzer von UB die Unterschiede zu BB und HB sehen. Die Tabelle koennte man sehr gut im README.md im github erstellen. Das ist sichelrich Arbeit. Aber wenn die Tabelle dort steht koennen auch weitere Nutzer die Tabelle per PR erweitern und Dir helfen ;)
 
Hey @framp

Das mit der Tabelle ist keine schlechte Idee, nur hast du mir damit eine kleine Mammutaufgabe gestellt. Denn je länger ich über mögliche Unterschiede nachdenke, um so mehr fällt mir ein. Einen detaillierten Vergleich zu konstruieren, werde ich wohl nicht schaffen, da Hyper Backup durchaus über eine Vielzahl an Funktionen verfügt, die Basic Backup nicht bieten kann. Daher habe ich mich vorerst nur auf das Wesentliche konzentriert und die Hauptunterschiede aufgeführt.

Leider mangelt es mir grade ein wenig an Zeit, weshalb ich die Tabelle erst mal hier zur Verfügung stelle. Es würde aber sicherlich Sinn machen, diese Tabelle in naher Zukunft auch in die README.md meines GitHub Repositorys einzustellen. Bis es soweit ist, hier mal ein erster Entwurf, der die wesentlichen Unterschiede zwischen BB und HB aufzeigen soll. Den Vergleich mit Ultimate Backup spare ich mir an dieser Stelle, da all das, was Basic Backup kann, auch Ultimate Backup kann.


Basic_BackupHyper_Backup
Allgemein
Gesicherte Daten lassen sich über die GUI komfortabel wiederherstellen
-​
✔️
Diverse Paketeinstellungen lassen sich über die GUI komfortabel sichern und wiederherstellen
-​
✔️
Speichern eines Versionsbackups (ggf. erschlüsselt) in eine Datenbankdatei
-​
✔️
Speichern eines Versionsbackup (unverschlüsselt) in Dateiform mittels Hardlinks
✔️
-​
Anfertigen eines detaillierten Datensicherungsprotokolls
✔️
-​
Optische- und/oder Akustische Signalausgabe über die LED’s bzw. den Lautsprecher des Synology NAS
✔️
-​
USB/SATA-Datenträger
Ein angeschlossener USB/SATA-Datenträger kann als Datensicherungsziel ausgewählt werden
✔️
✔️
Es lassen sich Datensicherungsquellen von einem USB/SATA-Datenträger auswählen.
✔️
-​
Es kann eine lokale Datensicherung von einem USB/SATA-Datenträger auf einen weiteren USB/SATA-Datenträger ausgeführt werden.
✔️
-​
Automatisches Ausführen eines Datensicherungsauftrages nach einstecken eines USB-/SATA-Datenträgers sowie ein abschließendes auswerfen des Datenträgers nach Beendigung der Datensicherung.
✔️
-​
Remote Server
Lokal ausgewählte Datensicherungsquellen lassen sich auf einen Remote Server sichern. (Push Backup)
✔️
✔️
Datensicherungsquellen, die sich auf einem Remote Server befinden, lassen sich auf das lokale Synology NAS sichern. (Pull Backup)
✔️
-​
Aufwecken eines Remote Servers vor Beginn der Datensicherung (Wake on LAN)
✔️
-​
Herunterfahren eines Remote Servers nach Beendigung der Datensicherung (shutdown)
✔️
-​
Angehängte freigegebene Remote Ordner können als Datensicherungsquelle oder -ziel ausgewählt werden.
✔️
-​

Anmerkung I:
Das sichern von USB/SATA-Datenträgern kann evtl. fehlerbehaftet sein, da sich der Mountpoint des Gerätes ziwschenzeitlich ändern kann. Wird ein USB/SATA-Datenträger als Datensicherungsziel angegeben, so kann dieser mittels seiner UUID anstatt seines Mountpoints identifiziert werden. Der Mountpoint wird ggf. intern umgeleitet.

Anmerkung II:
Das sichern von bzw. auf angehängte, freigegebenen Remote Ordner ist ebenfalls fehlerbehaftet, da rsync hier u.U. Probleme bei der Delta-Kodierung bzw. Differenzspeicherung bekommen kann.

Nachtrag:
Habe noch den Punkt Paketeinstellungen sichern und wiederherstellen hinzugefügt
 
Zuletzt bearbeitet:
Die Tabelle gefaeelt mir (y) denn man kann jetzt sehr schoen die zusaetzlichen Features von BB zu HB auf einen Blick erkennen.
Daher habe ich mich vorerst nur auf das Wesentliche konzentriert und die Hauptunterschiede aufgeführt.
No net hudle wie es hier so schoen heisst. Dir faellt bestimmt im Traum oder beim Spaziergang noch Weiteres ein. Das dann nur nicht vergessen (ist speziell im Traum nicht ganz einfach :D) und hier erweitern. Und UB hatte ich auch nur der Vollstaendigkeit halber erwaehnt.
 
Dir faellt bestimmt im Traum…
…wenn du wüsstest, was mir im Traum alles nicht einfällt 😅

Scheinbar bin ich eben aber mal kurz eingenickt und nach dem aufwachen kam mir gleich eine Ergänzung in den Sinn. Verrückt!

An die Mod‘s hier. Wie lange kann man seinen eigenen Beitrag eigentlich editieren? 24 Stunden? Es muss auf jeden Fall ein längerer Zeitraum sein, da ich hier bereits öfters einen Beitrag nachträglich editiert und mich über die bereits verstrichene Zeit gewundert habe. Ist aber auch nicht wichtig
 
Zuletzt bearbeitet:
Das letztmögliche Ändern des eigenen Posts haben wir auf 48 Stunden festgelegt.
Längere Zeiten halten wir auch für nicht sinnvoll. Das fällt in anderen Foren unangenehm auf; dort werden Posts nach langer Zeit noch editiert, so das der ursprüngliche Verlauf nicht mehr gegeben ist - die Nachvollziehbarkeit und der Lesefluss werden so beeinträchtigt.
 
48 Stunden halte ich aber bereits für einen durchaus komfortablen Puffer, den ich natürlich sehr begrüße. Vielen Dank für diese Info @Progof
 
Ich habe eben mal einen PR fuer Dein Repo erstellt in dem ich Deine hiesige Tabelle in git Markup umgewandelt habe ;) Wenn Du den PR akzeptierst sieht es bei Dir im Repo so aus

Da hast Du etwas mehr Zeit fuer Updates als 24 Stunden :) Ich denke nicht dass Du jede 2te Nacht eine weitere Eingebung hast 😁
 
Zuletzt bearbeitet von einem Moderator:
Wow! Danke @framp …das ist ja klasse. Ich habe somit zum ersten mal ein PR in mein Repo eingebunden. Hammer!

Ich schau mir die benefits.MD heute Abend noch mal genauer an und ergänze vielleicht noch das ein oder andere. Hat das einen Grund warum du die Dateierweiterung .MD groß und den Dateinamen klein geschrieben hast? Sollte doch eigentlich egal sein, oder?

Auch müsste ich mich langsam mal darum kümmern, meine README.md mehrsprachig auszulegen. Wie macht man das am besten. Sollte ich alles in eine Datei schreiben mit interner Verlinkung zu der entsprechenden Sprache im Text, oder besser vielleicht die Orginal README.md in englischer Sprache halten und eine weitere Datei namens README-de.md für die deutsche Übersetzung etc.
 
Zuletzt bearbeitet:
Ich habe somit zum ersten mal ein PR in mein Repo eingebunden.
Auch das erstellen eines PR geht sehr einfach :)
Hat das einen Grund warum du die Dateierweiterung .MD groß und den Dateinamen klein geschrieben hast? Sollte doch eigentlich egal sein, oder?
Soweit ich weiss muss die Repo Readme README.md heissen. Ich wollte mit meinem PR Dir nur zeigen wie man eine Tabelle in github erstellen kann und habe sie dann eben gleich konvertiert. Was Du jetzt damit machst ist jetzt Dir ueberlassen ;)
Sollte ich alles in eine Datei schreiben mit interner Verlinkung zu der entsprechenden Sprache im Text, oder besser vielleicht die Orginal README.md in englischer Sprache halten und eine weitere Datei namens README-de.md für die deutsche Übersetzung etc.
Ich persoenlich bin der Meinung die README.md sollte in github immer Englisch sein. Dann noch andere READMEs fuer andere Sprachen anzulegen ist Aufwand denn ein README aendert sich immer wieder und man muss staendig die andere Sprache nachziehen. Ich habe zugegebenermassen bei mir noch ein paar Links ins Deutsche uebersetzt da sie auf meine Webseite zeigen wo ich fast alle Seiten in Deutsch und Englisch erstelle. Joomla bietet support fuer Multilanguage. github aber nicht.

Mir hat jemand die Meldungen von raspiBackup freundlicherweise ins Franzoesische uebersetzt. Zum Schluss hat er dann auch noch einen PR fuer das README in Franzoesisch gestellt. Deshalb habe ich ein uebersetztes README ueberhaupt bei mir im Repo drin. Ich habe es dann im README.md entsprechend verlinked und die Dateien in den Ordner README_fr gestellt. Die README heisst dort auch wieder README.md.
 
Ich persoenlich bin der Meinung die README.md sollte in github immer Englisch sein. Dann noch andere READMEs fuer andere Sprachen anzulegen ist Aufwand denn ein README aendert sich immer wieder und man muss staendig die andere Sprache nachziehen
Basic Backup ist bereits für Mehrsprachigkeit ausgelegt und verfügt aktuell über die Sprachen Deutsch und Englisch. Von daher wäre die Erstellung sowie die Pflege einer weiteren, englischsprachigen README für mich das kleinere Übel. Es kostet halt nur Zeit. Da ich aber dazu geneigt bin, Commits in Git sowie Kommentare innerhalb meiner Scripte in deutscher Sprache zu verfassen, würde ich die README.md ebenfalls in deutscher Sprache anbieten und z.B. eine README_en.md für englischsprachige Benutzer erstellen. Und ich denke, das ich das auch genau so umsetzen werde.

Ich bin mir nur noch nicht sicher, wie ich mit der benefits.md bzw. mit dessen Inhalt umgehen soll. Ob ich hier auch eine BENEFITS.md und eine BENEFITS_en.md anlegen soll oder ob ich das alles in die entsprechende README packen soll. Vielleicht erstelle ich auch noch ein Verzeichnis, worin sich die Sprachdateien packe. Mal sehen.

Ich habe die benefits.MD noch ein wenig umgebaut, angepasst und erweitert. Wer mal einen Blick darauf werfen möchte, hier mal der Link wobei sich der Dateiname und damit der grade gepostete Link in naher Zukunft evtl. nochmal ändern wird. Auch wird es noch einige Anpassungen geben… ich hab momentan jedoch nicht die Zeit, mich ausgiebig und abschließend damit auseinanderzusetzen. Ich bin aber dran…

Update: Konnt nicht mehr schlafen, also habe ich grade die benefits.MD in BENEFTIS.md umgewandelt und den Link zur entsprechenden Datei hier angepasst.
 
Zuletzt bearbeitet:

Basic Backup Version 0.6-300 vom 15.04.2022

  • Es wurde der Vorgang beschrieben, wie man über die File Station der "autopilot" Datei das Attribut "ausführbar" vergeben kann.
  • UUID eines SATA-Datenträgers wurde nicht ausgelesen. Fehler wurde behoben.
  • Über die Optionsschalter -v, -vv sowie -vvv werden neben den erweiterten rsync Protokollen nun auch SSH Verbindungsprotokolle für den Debugging Mode 1, 2 und 3 ausgegeben.


Weiterhin viel Spaß mit Basic Backup

Tommes
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Keine Mitglieder online.

Letzte Anleitungen

Statistik des Forums

Themen
5.799
Beiträge
56.644
Mitglieder
5.716
Neuestes Mitglied
blinker
Zurück
Oben