Ugreen NAS: Augen auf bei rsync
von caschy | 23 Kommentare
Die Freude über das neue SSH-Feature mit rsync-Backup-Funktion bei Ugreen-NAS-Systemen währte bei mir nur kurz. Bei genauerem Hinsehen offenbart sich auch eine problematische Implementierung der Backup-Verschlüsselung beim integrierten rsync im Modul „Sync & Backup“.
In der Dokumentation zu Sync und Backup findet sich ein unschöner Hinweis: Backups werden standardmäßig verschlüsselt, und zwar so, dass sie ausschließlich auf Ugreen-NAS-Systemen wiederhergestellt werden können. Das klingt zunächst nach einem Sicherheitsfeature, entwickelt sich aber schnell zum Bumerang, wenn es hart auf hart kommt.
Der Knackpunkt: Fällt das heimische NAS aus oder wird durch einen Schadensfall zerstört, lassen sich die gesicherten Daten nur auf einem neuen Ugreen-System wiederherstellen. Eine Möglichkeit, eigene Verschlüsselungsschlüssel zu verwenden? Fehlanzeige.
Stattdessen nutzt Ugreen offenbar eine proprietäre Verschlüsselung ohne Zugriff auf Schlüsseldateien oder Passwörter. Das widerspricht dem eigentlichen Zweck von Offsite-Backups, nämlich Daten im Notfall auch ohne das ursprüngliche System zurückholen zu können. Erinnert ein bisschen an Hyper Backup von Synology, die haben ja die hbk-Files, während Ugreen auf .ubk setzt. Immerhin kann ich bei Syno auf mein verschlüsseltes Backup zugreifen…
Screenshot
Generell würde ich aktuell die Finger von rsync über Sync & Backup lassen und stattdessen das Ganze über das Terminal laufen lassen, um so eine unverschlüsselte Sicherung anzulegen (Ugreen unterstützt außer dem komischen Tresor eh keine Verschlüsselung). Ebenso muss man immer gut die Augen aufhalten, denn die Übersetzung bei Ugreen ist schon abenteuerlich: Quizfrage über diesem Absatz: Was ist mein Remote-Server? Ziel oder Ziel?
Und momentan ist es zumindest bei mir so, dass rsync über die Oberfläche keine genauen Fehler ausgibt, wenn eine Aufgabe fehlschlägt. Außer eben, dass sie unerwartet fehlgeschlagen ist.
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
Wird geladen ...
Verschlüsselte Backups die nur von spezieller SW wieder gelesen werden können, gibt es ja quasi nur noch. Da habe ich schon ein mulmiges Gefühl aber HW die man braucht um das wieder zu bekommen…. ok für ein Time Machine Backup braucht man auch einen Mac, aber ein NAS finde ich echt frech. Eines meiner Backups meiner Foto Datenbank landet unverschlüsselt per rsync auf einem TB drive das allerdings per PW am Mac hängt.
Danke für den Hinweis.
Ich hatte schon früher mal einen großen Datenverlust durch eine Verschlüsselung, und das brauche ich wirklich nicht noch einmal
Also entweder ist im Artikel das Problem unverständlich beschrieben, oder es liegt ein Missverständnis vor: Ich verstehe zwar prinzipiell die Kritik an security by obscurity Lösungen, aber wie man bei einem defekten Hardware-RAID Controller auf die Platten ohne eben diesen zugreifen will, um Daten zu restoren, ohne die exakte RAID-Konfiguration des bisherigen Hardware-RAID-Controllers zu kennen und emulieren zu können, eher weniger.
Anyway: Wer die Kommandozeile nicht scheut, dem kann ich nur wärmstens restic empfehlen. Das kann (u.a.) auch Backup via ssh und verschlüsselt immer (außerdem lokaler Ordner, sftp, rest-server, amazon s3, minio, wasabi, openstack swift, backblaze b2, microsoft azure blob storage, google cloud storage, rclone). Ist zudem für alle relevanten Desktop-Betriebsysteme verfügbar.
Wie Robin weiter unten in den Kommentaren geschrieben hat, nutzt UGREEN drunter wohl restic. Wenn ich das richtig verstehe, ist das fatale daran aber, dass sie für die restic Repositories ein Standard Passwort nutzen, was auf jedem UGREN NAS liegt.
Restic benötigt ja für die Verschlüsselung des Repositories ein Passwort.
An sich ist eine Sicherung mittels restic sehr sinnvoll. Nutze ich intensiv bei Kubernetes.
Wenn da nun ein Standard Passwort rumfliegt, dann viel Spaß wenn das mal raus kommt. Dann könnte quasi jeder auf UGREEN Backups zugreifen die ihm in die Hände fliegen.
Meine Daten die auf der UGREEN liegen schiebe ich vom Mac mittels rclone zu 3 verschiedenen Object Storage Anbietern.
Die meisten NAS in dieser Klasse verwenden ein MDADM Raid. UGreen ist da keine Ausnahme. Daher kann man die Platten einfach in einen Linux Rechner hängen und dort dann das Raid zusammenfügen und mounten.
Was restic angeht bin ich ganz bei dir. Ich verwende es ebenfalls und anscheinend auch UGreen. So wie es aussieht versteckt sich hinter der „Sync & Backup“ Funktion tatsächlich restic.
Schade das ein Hersteller immer noch so kurzsichtig agiert. Sobald der Key irgendwie, und die Wahrscheinlichkeit würde ich als hoch einschätzen, leakt ist die Verschlüsselung doch für den Ar***.
hab mal kurz gegoogelt, Ugreen scheint „relativ“ als Backup zu nutzen, also wohl nicht proprietär:
https://ugreen-forum.de/forum/thread/1277-sync-backup-repository-ins-dateisystem-mounten/
ggf einfach mal ausprobieren…
„restic“ sollte das heißen. blöde Autokorrektur
Der ganze Post ist komplett schwachainn. Schade, dass der Artikel völlig ohne Recherche und Validierung geschrieben ist und noch dazu die Kommentare alles Geschriebene als die richtig ansehen…
Ich bin kein Ugreen-Jünger, aber ein kurzer Blick in die Backup-Files zeigt, dass es sich um ein restic-Repository handelt, welches mir dem Passwort „ugreen“ gesichert (ja nicht wirklich…) ist.
also zusammengefasst:
– keine exotischen Backup-Tools, sondern restic
– keine eigene Verschlüsselung, sondern der restic-Standard (ohne den es BTW gar nicht geht…)
Naja, solche Artikel brockt man sich aber auch ein wenn man seine Doku so schreibt bzw. übersetzt…
Trotzdem ist der Punkt ob man dabei einen eigenen Schlüssel verwenden kann (über die GUI wohlgemerkt) dadurch nicht geklärt für mich. Ich kenne restic nicht und habe auch kein Ugreen NAS, fände es aber gut wenn man da näher drauf eingehen würde. Nachdem Synology aus meiner Empfehlungsliste geflogen ist, wäre Ugreen ein guter Kandidat für Leute die nach einer Fertiglösung suchen.
Warum so aggressiv? – Schwachsinn, ohne Validierung… Zwingt dich jemand diese Artikel zu lesen und zu kommentieren? Kommentieren und „normalos“ zu helfen den Sachverhalt zu verstehen ist dir nur in Verbindung mit Beleidigungen der Autoren dieses Blog möglich? Du weißt es deutlich besser und willst der Menschheit helfen? – wo finde ich deinen Blog / Publikationen/ White Paper?
Warum glauben Leute wie Du @Recherchierer eigentlich, sie hätten in irgendeiner Form mehr recht und ihre Aussagen mehr Aussagekraft, wenn sie ihre Posts mit Diffamierungen und ausfallend aggressiven Formulierungen spicken?
Ich verlasse mich nie auf ein NAS alleine.
Ich habe immer zwei in Betrieb, eines als Produktivsystem, ein zweites als Backup.
Einmal die Woche wird Gerät 1 auf Gerät 2 gespiegelt.
Mag ein teurer und für manche umständlicher Weg sein, aber meine Daten (Fotoalben, Musiksammlung und andere unwiederbringliche Erinnerungen) sind mir die Kosten und den Aufwand wert.
Sein kann immer was, aber so habe ich schonmal ganz gut vorgesorgt.
„Was ist mein Remote-Server? Ziel oder Ziel?“
Der Text dort mit „Ziel der Sicherung“ und „Sicherungsziel“ erinnert mich irgendwie an die „Judäische Volksfront“ und die „Volksfront von Judäa“.
Synology DSM ist ein normales Ubuntu und fragt am Anfang, ob es auf Synology Hardware läuft. Der Bootloader auxxxilium (deutscher Entwickler) ermöglicht DSM auf Ugreen. Für mich das beste aus allen Welten.
Die Verschlüsselungsthematik (sowohl beim Backup als auch auf den internen Festplatten) ist leider für mich DER Grund weshalb ich dieses Mal nochmals zu einem Synology NAs gegriffen habe bzw. greifen musste. Ich hoffe, Ugreen legt hier noch ordentlich nach, damit sie beim nächsten Upgrade in ein paar Jahren eine gute Option für mich sind.
Was mich echt nervt: Bei RAID 1 ist es nicht möglich, eine dritte Platte als separaten Speicherpool vorübergehend zu deaktivieren, ohne dass gleich Fehlermeldungen aufploppen. Dabei wäre es doch praktisch, ein zusätzliches Laufwerk für Backups zu nutzen, das man getrennt lagert und nur sporadisch für Sicherungen einsetzt.
„Was ist mein Remote-Server? Ziel oder Ziel?“
Was steht denn da wenn die Oberfläche auf Englisch ungestellt ist? Ist hier was bei der Übersetzung schlecht gemacht oder einfach Programmierfehler (Menüpunkt doppelt).
„aber schnell zum Bumerang, wenn es hart auf hart kommt.“
Prüfe wer sich bindet. Wenn ich das Risiko für mich sehe das ich Daten verliere und daher ein Backup benötige und auch ein Backup erstelle habe ich schon mal ein ersten Schritt gemacht. Das auch das Backup genau wie mein Original verloren gehen kann sollte doch jeden klar sein. Das daher vielleicht eine weitere Sicherung nötig ist, darf ein jeder für sich selber bewerten. Ebenso das auch ein Restore getestet wird. Wie weit das jeder treiben möchte ist dem persönlichen Sicherheitsheitsbedürfnis geschuldet. Und ja ich ziehe ein Backup vor wo ich ggf. auch mit einen andern OS und andere Hardware noch zugreifen kann.
Welche NAS-Plattform würdet ihr Stand heute empfehlen:
Ugreen, Synology, QNAP?
Im Wesentlichen als Backup:
Gern aber auch geordnet nach Backup, Mediacenter (audio/video) und Render-Aufgaben (video).
Das ugreen NAS ist schon OK. Super verarbeitet. Das beste ist aber, man kann sein eigenes Betriebssystem installieren. Zb. Truenas und das wäre auch meine Empfehlung. Vom Konzept erinnert es mich ein wenig an den HP Microserver der aber leider mit der Gen11 nur noch schlecht geworden ist.
Und so fängt es auch bei Ugreen an, das man die Kunden an sich binden will. Demnächst bei Ugreen: Nur Ugreen gelabelte Festplatten.
Aber das ist halt der Preis der Bequemlichkeit, wenn man sich kein eigenes NAS bauen möchte.
Blödsinn. Thema nicht verstanden.
Naja, weiß nicht. Es ist nicht so ganz klar, aber es könnte einfach ein Layer-8-Problem sein: rsync mit restic verwechselt. Bei restic wird das Ziel immer verschlüsselt, wenn der Key aber immer ‚ugreen‘ ist, wie jemand weiter oben schrieb, kann man von Verschlüsselung eigentlich nicht sprechen. Und von Lock-in schon gar nicht, denn restic ist nicht proprietär, man kann das Backup mit jedem OS öffnen, für das es restic gibt (sogar für Windows gibt es das, glaube ich). Aber solange sich der Autor des Artikels nicht dazu geäußert hat, ob es lediglich eine Verwechslung von rsync mit restic ist, kann man lange diskutieren.