DataCollector

Wenn Dein appdata im cache/pool vollständig ist und in dem appdata Verzeichnis Deine Docker zu sehen sind, ist alles da, wo es hin gehört. Dann kannst Du Deine Docker wieder starten. Und lass die Finger von den USER und USER0 Verzeichnissen!!! Diese zeigen nur als share das an, was Du in den physikalischen Disks vorhanden hast. das ist das selbe und soll auch so sein. So ist es bei mir: Rechts ist das appdata in meinem Cache und links siehst Du die Docker in dem appdata Verzeiczhnis. HIer sind als Beispiel meine Share Einstellungen zu appdate Und hier zeigt "Compute all", dass der Inhalt auch auf Cache liegt. "God's in his heaven, all's right with the world" Und am Ende noch meine Docker Settings

Ich nutze gerne mc, aber Du kannst natürlich auch krusader, den eingebauten Dateimanager oder auch unbalanced nehmen. Aber auch bei der Aktion sollte der Docker Dienst aus sein. Lass die Finger von "user" diesen Unterordnern!!!!!! (...wenn Du nicht genau weisst, was Du machst). Du willst /mnt/disk2/appdata nach /mnt/cache/appdata verschieben. das ist okay. Aber beziehe nicht die "USER" oder "USER0" Verzeichnisse mit ein. Das geht schief, weil das nur 'virtuelle Duplikate' für diverse Funktionen in unraid sind, wie beispielsweise das fuse Dateisystem.. Wenn Du anfängt in diesen user Verzeichnissen (shares) kreuz und quer zu den Disks zu vertschieben machst Du schlimmstenfalls mehr kaputt als Du wolltest! DANGER! FINGER WEG! Wenn man nicht gaaaaaaanz genau weiss, was man macht: NIE beim kopieren oder verschieben DISK(Verzeichnisse) mit SHARES kreuzen. GROßE Falle!!! Grün: okay - Kopieren/Verscxhieben zwischen physikalischen Disks (Cache/Pool und Disk2/Array) Rot: DANGER! NIE MACHEN! Kopieren zwischen physikalischem Laufwerk (Cache) und Share (User) erzeugt schlimmstenfalls Doubletten oder Fehlermeldungen. Verschieben kann Dateien verschwinden lassen (=löschen). Rot: DANGER! NIE MACHEN! Kopieren zwischen physikalischem Laufwerk (Cache) und Share (User0) erzeugt schlimmstenfalls Doubletten oder Fehlermeldungen. Verschieben kann Dateien verschwinden lassen (=löschen).

Ich greife aktuell zu den erwähnten Transcent Jetflash 600 und 780, weil diese (laut Beschreibung) MLC NAND Flash-Chips verwenden, von denen ich mir eine längere Haltbarkeit verspreche. Da die 600er Serie (USB2.0) nur noch in einigen geringeren Kapazitäten (als 32GB) erhältlich sind, wurde mein letzter unraid USB Stick ein 780 32GB (USB 3.0). Ich sollte aber nicht unterschlagen, daß auch meine ersten beiden USB Sticks mit unraid bisher super funktionieren (siehe auch meine Signatur): "Samsung Bar Plus" + "Sandisk Cruzer Fit" (beide vor rund 3 Jahren für unraid neu gekauft und nach anfänglichen Tests, seitdem als unraid Bootstick in USB 2.0 Anschlüssen am Mainboard betrieben). Ich verwende der Bequemlichkeit halber den "Unraid.USB.Creator.Win32-2.1.exe", den ich mir gesichert habe. Alternativ kann man aber auch den manuellen Weg gehen: https://docs.unraid.net/unraid-os/getting-started/manual-install-method/ Mit dem erwähnten Creator spiele ich gelegentlich ältere Versionen in mein Testsystem (Gigabyte B760M DS3H DDR4) ein, weil es sich mit unraid 6.12.4 einfacher testen läßt, als mit den Nachfolgeversionen. Der aktuelle unraid USB Stick Creator erfordert eine Installation und hat Probleme bei einigen USB Sticks die korrekte ID zu erkennen und zu nutzen. Da kommen dann (sinngemäß) Aussagen wie: der Stick sei nicht nutzbar oder habe keine eindeutige ID oder so. Mit dem älteren "Unraid.USB.Creator.Win32-2.1.exe" hingegen hatte ich noch keine solchen Probleme. Ich habe es gemacht, als ich die einmal nach einem Absturz entdeckt hatte und das unraid problemlos gebootet hat.

Das dürfte dann eher eben eher ein OS oder Treiberproblem sein. Das klingt mir nicht nach einem "stehenden" Kernel, da er diese Aufgaben ja abarbeitet.

Eigentlich klingt mir das ganze recht vernünftig eingestellt. Primär oder exklusiv Pool Wenn überhaupt Array als Secondry (falls der Pool doch mal voll läuft will man ja nicht gleich, daß alle Docker abschmieren). Und wenn Mover aktiv wird, soll er alles von Array (was nicht gerade durch Docker blöockiert wird) wieder in den Pool verschieben. Damit der Mover das machen kann, dürfen die Docker aber die Dateien eben nicht gerade festhalten. Also Docker aus, mover an, warten, docker wieder an, fertig. Solange ausreichend Platz im (SD) Pool vorhanden ist, will man das nicht im Array haben, ja. Sollte aber man der Pool voll gelaufen sein, ist es für mich schon sinnvoll den Docker temporär auch im Array werkeln zu lassen, anstatt, daß einzelne Docker wegen Schreibfehlern Stück für Stück mit Fehlermeldungen (oder gar ohne) abschmieren. Find ich gut. Ich sehe da kein problem drin. Vermutlich war der Dockerdienst dennoch an? Stoppe alle Docker, stoppe den Docker dienst, starte den Mover. Der sollte dann von der Disk in den Pool verschieben (sofern ausreichend Platz vorhanden ist). Wenn der Mover fertig ist, kannst Du Docker Dienst und die Docker selber wieder starten.

Ich verstehe nicht, warum ein ssh Zugriff auf das (im Ram laufende) unraidsystem von einem parallelen Schreibprozess auf einem USB Stick beeinflusst werden sollte und selbst wenn ein USb Stick langsam schreibt dürfte das (im Ram laufende) OS nicht vom Stick, sondern vom USB Kontroller des PC blockiert werden. DER USB STick ist eine eigenständig arbeitende Einheit, die vom PC nur Strom und Befehle bekommt. die Befehle führt der Stick in seinem eigenen Kontroller aus. Dass ein PC USB Kontroller dann eien Blockade auslöst ist nicht Sache des Sticks, sondern des nicht multitakstingfähigen PC Kontrollers (bzw. seiner Firmware oder OS Treiber). Unraid bootet vom USB Stick und schaut beim starten von Docker und Vm auf dem USB Stick nach der anzuwendenden Konfiguration. Auch wird ab und zu auf dem USB Stiuck nachgesehen ob die Lizenz da ist. Wenn man es einstellt wird auch das Syslog auf dem USB Stick platziert. Aber wenn man ein laufendes System (wie unraid) hat und den Update OS Button drückt wird das OS dort neu aufgespielt/ausgetauscht. Warum sollte die Aktivität auf dem USB Stick das in der beschriebenen Weise im RAM laufende OS beeinflussen? Es ist ja nicht so, daß damit auch das gerade laufende OS im RAM ausgetauscht wird oder der Transfer von 300-800MB OS Update sooooo extrem viel ist, daß der vorhandene PC Ram (vermutlich mindestens 4GB DDR Ram) maximal ausgelastet ist. Selbst das entpacken der gezippten Version sollte den PC nicht so stark auslasten, daß der ganze PC alles Andere stoppt. Wenn also ein OS Update (ohne danach zu booten) die Reaktion(en), des ansonsten sauber laufenden (und nicht hoffnungslos untermotorisierten) Systemes im RAM beeinflußt, ist es mir unverständlich, warum dies am USB Stick liegen soll. Aber ich kenne mich mit Linux leider auch nicht so genau aus. Sollte Linux evtl. doch nicht so multitaskingfähig sein, daß es einerseits einen USB Stick bespielen und andererseits laufende Prozesse, die nichts mit USB zu tun haben, nicht sauber weiter laufen lassen kann?

Da Du "Fertig" schreibst vermute ich Deutsches Sprachpaket. Das ist des öfteren schon bei Problemen mit der GUI Anzeige benannt worden.

Meine Win 10 und Win 11 funktionieren weiterhin (aus dem lokalen LAN) per VNC. Ich verwende aber bevorzugt realVNC Server + Client. Das mache ich täglich mehrfach. Bei Bedarf wähle ich mich auch von außen per Fritzbox VPN (WG) in mein Heimnetz ein und kann dann auch da auf diesem Wege zugreifen. Das mache ich pro Woche vielleicht 1 mal. Um das Booten oder Updateprozesse zu kontrollieren verwende ich auch gelegentlich das in unraid enthaltene noVNC. Auch das läuft bei mir im lokalen Netz weiterhin problemlos mit den selben Win10/11 VM. Zuletzt vor rund 2 Tagen, als ich unraid wegen Festplattenupgrade mal ausschalten und danach alles (incl. Docker & VMs) wieder hochfahren musste.

Klinght mir nach "USB Kontroller des Mainboard kappt die Verbindung/Stromversorgung, bevor der letzte Schreibvorgang abgeschlossen ist. Somit verliert der Stick die Möglichkeit die letzten zu schreibenden Bits eben zu schreiben, weil das Mainboard neu bootet und in dem (noch nicht abgeschlossenen) Vorgang des Schreibens auf den Stick unterbricht, indem es den USB Kontroller eben zu früh abschaltet/initialisiert. USB 3.0 Sticks (5GBit/s) sind eigentlich auf bis zu 5V mit 0,9A ausgelegt (basierend auf der USB Spec sind bis herab zu fast 4V zulässig). Mit dieser Leistung (Spannun * Strom) erreichen die die hohen Schreib-/Lesegeschwindigkeiten. Ein USB 2.0 Port ist aber nur für 0,5A vorgesehen. Deshalb beherrschen die Sticks auch einen Modus, welcher dann dort etwas langsamer arbeitet, weil einerseits das die elektrische Leistung reduziert und andererseits sowieso ein USB 2.0 Port eben weniger Daten liefern kann. Doch der USB Stick braucht dann intern auch mehr Zeit für die Verarbeitung (weil er bei normal hoher Geschwindigkeit ja mehr elektr. Leistung haben müsste). Der Kontroller im USB Stick meldet aber dem PC, daß er schon fertig ist, obwohl er intern die Daten noch in die Zellen quetscht. Sollte der PC dann in Reboot gehen ist es Glückssache ob man lange genug gewartet hat vor dem Reboot und alles sicher ind en Zellen angekommen ist oder ob der PC den Kontroller resettet und somit auch der USB Stick dieses "Alles zurück auf Anfang" Signal mitbekommt und dem Befehl folgt. Ja, das kann man in einem USB Stick entweder mit Puffern und geschickter Firmware abfangen, doch das kostet Geld. Und da sind wir dann eben wieder bei "ja, es gibt sehr viele Jetflash Sticks der Firma Transcend. Die Kosten und Qualität sind dabei von sehr preiswert bis doch recht hochwertig weit gestreut. Meine Jetflask 600, 780, 790 930c haben mir noch keine solche Probleme bereitet. Einige 760 und 350 haben mich hingegen vor etlichen Jahren stark enttäuscht und sind mittlerweise bei mir fast komplett entsorgt.

Transcend hat extrem viele sehr unterschiedliche Jetflash Typen im Angebot. Diese Aussage sagt somit leider nicht viel. Lokales Backup des USB Sticks machen (unraid bietet dafür eine Funktion), Unraid herunter fahren USB Stick löschen, einmal komplett mit nachvollziehbaren Daten voll schreiben und dann all diese Daten lesen und prüfen ob diese korrekt sind. - Wenn alles okay ist, Stick wieder löschen und das Flashbackup zurückspielen und dann urnaid damit wieder starten. - Wenn nicht alles okay ist: das deutet dann sehr stark auf einen Schreibfehler hin, was entweder ein USB-, Dateisystemfehler oder ein USB-Stick-defekt sein kann. In dem Fall sollte man sich noch genauer mit dem Stick und dem schreibenden PC beschäftigen. Die Zeitschrift ct (Heise Verlag) hat für solche Tests, schon vor Jahren, eine sehr praktische Windows Software "h2testw.exe" raus gebracht, welche einen Datenträger mit nachvollziehbarem Kauderwelsch voll schreibt und diesen im Nachgang dann auch auf Korrektheit prüft. Solche Dateien deuten darauf hin, daß da (zumindest im Dateisystem) etwa schief gegangen ist. Auch können solche Dateien ein Backup stark vergrößern. Ein Dateisysetmfehler bedeutet nicht, daß der Stick selber physikalisch defekt ist. Es bedeutet, daß zumindest logisch im Dateisystem etwas schief gegangen ist (Stromausfall beim Schreiben, USB Verbindungsabbruch beim Schreiben.... irgendetwas in de Art kann auch Schuld tragen). Da der Stick notwendig ist um unraid zu starten (und der auch sporadisch auf Vorhandensein der Lizenz gelesen wird), kann unraid schlecht den Stick selber löschen, beschreiben. testen und dann wieder löschen und Backup zurückspielen. Einen entspechenden Test mußt Du außerhalb von unraid machen.

Ich habe keine Ahnung, ob es bei Dir damit zu tun hat, aber die haben die Version 7.1.4 raus gebracht, die diverse Netzwerkprobleme beheben soll. (Eigentlich die Probleme, die mit 7.1.3 eingebaut wurden) Vielleicht ist es einen Versuch wert?

Ich glaube das wird schwierig. Wenn ich es richtig verstanden habe: Er hat einen bestehenden Unraidserver, der später "Proxmox Server" werden soll. Es wird also der unraid USB Stick entweder im alten oder im neuen Server verwendet. Somit hat er nur eine laufende unraid Installatioin. Ohne ein kompatibles OS auf dem zweiten System laufen zu haben wird das Plugin wohl entweder auf der Quelle nicht laufen oder kein Ziel finden. Oder habe ich das Tool falsch verstanden?

Ich weiß weiß nicht, ob sie wirklich der Verursacher ist, aber diverse WD NVME haben bei einigen Leuten niedrige C-States verhindert. Ich würde jetzt einfach (noch)mal ohne die WD testen.

Idee? nein. Da ich das aber auch bei Windows Maschinen untereinander habe, liegt es (meiner bescheidenen Meinung nach) an Windows und nicht an unraid. Witzig ist, daß es bei mir von PC zu PC unterschiedlich ist: Der eine WInPC zeigt einige der anderen WinPC nicht an, ein anderer zeigt andere WinPC nicht an und ein weiterer zeigt wieder ein paar andere der PC nicht an. Alle sind seit mindestens einer halben Stunde im selben lokalen Netz in Betrieb. Zugriffe auf Netzwerkfreigaben sind aber alle problemlos möglich. Das kenne ich aber auch schon seit mindestens win7, seit ich eben doch eine gewisse Anzahl von Computern/etc... (damals nur windows, heute auch unraid, android und IOT) im lokalen Netz betreibe.

Du hast Deinen Ram doch ausgiebig getestet.

Deiner Beschreibung nach scheint aber irgendetwas relevates dennoch auch auf Disk 4 zu liegen. Schau mal im Shares Tab Nach und lass mit "Compute All" feststellen welche Shares auch Disk 4 berühren. Ich vermute eines der Systemshares oder ein anderer Teil, der irgendeinen Docker betrifft, liegt dennoch auf Disk 4. Ich gehe davon aus, dass eben irgendein share dennoch Disk 4 berührt und mit Docke zu tun hat. Selbst ein leeres Verzeichnis auf Disk4, welches identisch zu einem Share benannt ist, würde zumindest lesend die Disk4 anlaufen lassen. Also schon mal 1 der 4 Systemshares (auch wenn das mit Docker normalerweise nichts zu tun hat). Kann es sein, daß der Ordner dennoch in einem Docker template angegeben ist? Wenn er sowieso leer ist: Verschiebe den doch mal auf Deinen Pool und teste einfach ob sich damit das Problem behoben hat. Sind die in einem Docker verlinkt?

Habe gerade auf einem meiner Systeme mit 7.1.3 getestet: bei mir funktioniert das Flashbackup weiterhin. Hast Du es schon probiert, bevor Du die Freigabe auf das Flash eingerichtet hast oder könnte es sein, daß die Freigabe hier blockiert? Wenn ich es richtig in Erinnerung habe wird das ZIP Backup erst auf dem USB Stick zusammengebastelt (deshalb dauert es wohl auch so lange) und dann übertragen. Hast Du vielleicht einen defekt auf dem USB St ick (ggf. Dateisystem beschädigt)?

Nur so nebenbei: Deine Probleme waren beim Paritycheck aufgetreten (also wenn das System wirklich prüft ob die Daten noch konsistent sind). Der Parityaufbau hingegen prüft gar nichts. Es wird nur die Parity berechnet und geschrieben. Erst ein Paritycheck würde zeigen ob die Daten auch noch dem entsprechen, was vorher berechnet wurde.

Dein Cache Pool scheint BTRFS zu sein. Punkt. Single Disks (auch Disks im Array): xfs Verbundene Disks (Pool): seit unrait 6.1.x: zfs. Bei viel zu vielen Beiträgen mit (anfangs) unerklärlichen Fehlern zeigt sich btrfs als beteiligt oder gar Ursache. Ich stehe auf dem Standpunkt: btrfs (Verbund) in unraid = böse. (Auch, wenn es hier Beispiele gibt, bei denen btrfs problemlos läuft vermeide ich es dennoch soweit wir möglich.) Selbst meine Docker Images sind nicht mehr btrfs.

ich habe mich hier darüber schon ausgelassen: https://forums.unraid.net/topic/156160-gigabyte-b760m-ds3h-ddr4-verschiedene-messungen-werte/page/2/#findComment-1434236 (und der Beitrag direkt darunter) Wie gesagt: mgutt hat da praktische Erfahrungen und ein Kabel, welches er für SATA nutzt.

Die 9500-8i sind generell erheblich sparsamer als die vorherigen und auch die nachfolgenden Serien. (Deswegen habe ich auch einen hier liegen) Leider ist bei dem 9500 die Kabelanschlußproblematik, da man dort auf einen neueren 8fach Anschluß umgestellt hat und den auch nicht ganz so beschaltet, wie es andere Kontroller mit dem SFF machen.. mgutt hat sowas zum Laufen gebracht und ich habe dazu von ihm noch on keinen Problemen gelesen. Aber die korrekte Kabelwahl ist gerade für den 9500 Kontrollern sehr wichtig.

Klitzekleine Ergänzung: Normale 2,5inch Festplatten laufen mit 5V und brauchen keine 12V. Aber 2,5Inch Festplatten sind (mit großer Bauhöhe) maximal mit 5TB zu haben (obwohl ich glaube vor kurzem gelesen zu haben, daß WD 6TB in 2,5inch Bauform anstrebt. Ob WD die aber dann fest mit einen USB Port verheiratet weiß ich nicht. Und auch die wären dann bestimmt 15mm hoch. Ich weiß nicht ob 15mm Bauhöhe in die Linkstation N2 rein passt.)

Was heißt für Dich "schnell"? Hast Du ein 25GbLan oder 10GbLan Netz, so daß es NVMe SSD Speicherplatz sein müsste? So nett wie die LincStattion ist, so wenige wirklichen Nutzen hat man im privaten Umfeld von dem Kistchen. Mit den bis zu 4 NVMe SSDs ist man bei dem Wunsch nach viel Spsicherkapazität (und das lese ich aus Deinem Beitrag irgendwie heraus, da Du ja schon zu 8TB schielst) dann doch schnell einerseits sehr teuer unterwegs oder sehr begrenzt. Zugrunde liegendes Rechenbeispiel: 4x WD SN850X 8TB 565 Euro = 2260 Euro 2x Samsung 8TB QVO 553 Euro = 1106 Euro (Wenn man mal die Mushkin Source HC 16TB, 2.5inch für allein 2459 Euro außen vor läßt) Und dann ist man schon am Ende. Klar dafür sättigt man dann auch lesend und schreibend die 10GbLan des NAS, aber ist einem das wirklich 3366 Euro (+ Deinen Kickstarterpreis) wert? Ein NAS, auf Standard PC Basis mit 3,5inch Festplatten und eine oder 2 schnellen Cache SSD sollte für den normalen Heimanwender vollkommen ausreichend sein und mit der selben Speicherkapazität erheblich weniger kosten. Selbst wenn Dir 4TB reichen ist das mit Standard PC Technik irgendwo zwischen gleich teuer und billiger machvar. Die PCIe 4.0 x4 Karten (ohne DRAM) werden sich an dem verbauten N100 mit PCIe 3.0 und dann x1 pro NVMe SSD bestimmt super langweilen. Abgesehen davon, daß die angegebenen 7400MB/s nur werbetechnische Schönfärberei des Herstellers ist, kann die SSD sowieso allerhöchstens rund 1GByte/s an dem PCIe 3.0 x1 transportieren. Das verbaute 10GBLan kann übrigens auch nur etwas weniger als 1GByte/s pro Richtung transportieren. Dann nutze sie auch anders, da sie nicht in die LincStation N2 rein passt (Siehe auch Kommentar von alturismo). Wenn Du Ausfallsicherheit willst: Array oder Pool mit 1 Daten + 1 Parity Datenträger = 4TB Nutzkapazität. Wenn Du keine Ausfallsicherheit willst: Array oder Pool mit 2 Daten Disks = 8TB Nutzkapazität. Mehr geht sowieso nicht mit nur 2 Datenträgern. Eine USB Disk ins Array zu verfrachten ist nicht empfohlen und einen USB Datenträger im Pool ...mag mir auch irgendwie nicht wirklich empfehlenswert erscheinen. Wenn Geld eine Rolle spielt (auch mit Hinblick auf Kosten bei Maximalaubau oder gar wenn man bei der aktuell absehbaren Kapazitätsgrenze von 6x 8TB ankommt): Lincstation N2 günstig verkaufen und besser auf PC Basis etwas zusammen stellen. Dort dann auch 3,2 inch Datenträger ermöglichen.

Also mein Step von 7.1.2 auf 7.1.3 hat keine Probleme auf den erwähnten 2 Systemen gezeigt.Sie laufen seit gestern. Ich kann sie (lokal im LAN) per Firefox ansprechen und WebGui bedienen. Aktuell habe ich bei einem der Systeme zwei Terminalfenster offen und kopiere/verschiebe seit gestern per mc Verzeichnisse mit Dateiinhalt zwischen einmal Cache auf Array und einmal zwischen 2 Disks im Array. Reine Vermutung: Das Problem liegt vielleicht nicht im 7.1.3, sondern in einen der Steps zwischen 7.01 und 7.1.3, welcher sich bei der (vielleicht speziellen) Konfiguration in Deinem (und anderen) System(en) auswirkt. Möglicherweise ist der Verursacher, der Dein System (und ggf. auch andere) aus dem Tritt bringt schon in einem der Upgrades dazwischen vorhanden. Ggf. könnte man es durch Einzelsteps einkreisen und dann auch besser finden, bevor man nun alle (weiter in den anderen Updates veränderten Punkte) gleich mit in Verdacht zieht?

Ich habe heute meine beiden Primärsysteme von 7.12 auf 7.1.3 umgestellt. Beide sind in meinem grundstücksinternen Lan weiterhin ohne Probleme erreichbar (WebGui). Bisher laufen auch die darauf befindlichen Win11 VM ohne, daß ich Einschränkungen erlebt habe. Auch AdGuard und mein SabNzbd (ich777) laufen bisher ohne erkennbare Probleme. Aber wie gesagt, das ist alles nur hier ein lokales LAN. Zum Thema Rollback: Wenn man das System weder aus der Ferne steuern, noch lokalen Zugriff auf das System hat: Pech gehabt. Vielleicht kann man einen dort platzierten Admin dazu bewegen das lokal zu machen. Wenn man irgendwie an das (Web)GUI doch noch ran kommt: 1.Backup des USB Sticks machen (und lagern) 2. In laufendem Unraid "Tools"/"Downgrade OS" nutzen um auf die vorherige Version zurück zu gehen. Wenn man keinen Zugriff auf GUI hat, aber an den USB Stick ran kommt kann man ein zuvor angefertigtes FlashBackup mit der vorherigen/gewünschten Version einfach wieder dort aufspielen. Man könnte sogar den Boot USB Stick einfach nehmen und die Systemdateien einer vorherigen Version dort drüber bügeln. Das selbst angepasste Zeugs ist sowieso im config Ordner auf dem Stick. Wenn alles nicht geht: USB Boot Stick löschen/säubern (ggf. auch mal testen ob die Probleme nicht durch defekten Stick oder Dateisystem entstanden sind) und mit der gewünschten Version neu bespielen. Dann ggf. den config Ordner eines vorherigen Backups mit drauf kopieren (incl. der Lizenz Key Datei). Da ich vor relevanten Änderungen (und auch mal so ab und zu zwischendurch) ein Flash Backup anlege und auf einem anderen PC lagere wäre das "Downgrade Tool" meine erste Wahl und wenn das aus unbekanntem Grund hängen bleibt eben das komplette Rückspielen eines meiner Backups auf den Stick.