Nur DSM von HDD auf SSD umziehen lassen, Daten bleiben auf HDD - Synology DS216+II & DX213

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

Danke an alle für die Antworten.
Ihr wisst ja, man hat da seine Vorstellungen und dann ist nicht alles für einen geeignet, aber immer dankbar für den Austausch. Natürlich, viele Wege führen nach Rom.

Die DSM und SWAP Partition wird auf der DX nicht genutzt, aber die Partitionen werden trotzdem gem. allg. Partitionstabelle angelegt. Ich kann nachher mal schauen, ob da auch was gespeichert wird.
Ansonsten ist so ein Setup absolute Bombe, weil die HDDs in der DX kaum zu hören sind!!!
Ja, so hab ich mir das vorgestellt. Docker und System läuft weitgehend lautlaus auf SSD und auf den HDD's im Erweiterungsmodul greife ich auf Bedarf zu. Das ist eben angenehm, wenn man die DS und DX im Wohnzimmer stehen hat.

Die DX wacht bei mir immer alle 35min - 1h auf, obwohl aktiv kein Zugriff passiert. Das muss ich mir noch ansehen.

LG, Tommily
 
  • Like
Reaktionen: ctrlaltdelete
Hallo zusammen.

Die DX wacht bei mir immer alle 35min - 1h auf, obwohl aktiv kein Zugriff passiert. Das muss ich mir noch ansehen
Es ist vollbracht.
Hat es Nerven gekostet? JA.
Alles Mögliche wurde schon ausgeschlossen und auch der Synology Support konnte nicht weiterhelfen.

Synology Support hat immer nur auf die Website mit den Standardantworten verwiesen und gesagt es liegt wahrscheinlich am SMB service. Sowie alle Pakete deaktiveren und ein Logging aufsetzen. Aber leider ist hier nichts dabei rausgekommen.

Außerdem: "At the moment, we do not have a complete troubleshooting procedure specifically for expansion unit drive hibernation issues."

Remote Zugriff wollte ich nicht gewähren, somit war es das dann.

Durch Zuflall hat sich dann für mich die Lösung ergeben.
Unabsichtlich hab ich der DX die Kommunikation zur DS genommen, ich weiß, Schande über mich.
Dadurch ist sie natürlich in den schreibgeschützten Modus gegangen und wurde anschließend "repariert".
Stellt euch vor, nach der Reparatur funktioniert alles einwandfrei.
Also ich gehe davon aus, dass hier schon mein ursprünglicher Gedanke nicht ganz falsch war, es war auf jeden Fall etwas Synology Internes.

Nun läuft die DS ganz normal flüsterleise mit den SSD's und Docker und den wichtigsten Daten.
Die DX mit den HDD's ist auch flüsterleise, denn sie startet vielleicht 2x täglich was ich im Log sehen kann und natürlich bei aktivem Zugriff.

Schönen Tag & LG, Tommily.
 
Das war mit Sicherheit nicht die Ursache. Denn solange die Reparatur des Speicherpools auf der DX läuft, gehen deren Platten erst gar nicht in den Ruhezustand. Sie können also gar nicht alle 30-60 min daraus wieder aufwachen.
 
Das ist schön, dass Du das mit Sicherheit sagen kannst.
Ich muss jedoch Widersprechen, habe mich lange genug mit dem Thema beschäftigt.
Ich glaube eher da hast Du nicht richtig gelesen.

Es geht ja nicht um den Zeitpunkt der Reparatur, sondern, dass die Reparatur das Problem des immer wiederkehrenden zyklischen Aufwachens behoben hat.
Also Zeitpunkt nach der Reparatur im normalen Betrieb.

Ich kann das anhand der Logs eindeutig belegen.

LG, Tommily
 
Trotzdem ist nicht klar, was genau die Ursache war und warum die Wiederherstellung des Schreibzugriffes auf das Volumen das Problem beseitigt hat. Sofern es da überhaupt einen Zusammenhang gibt.
 
@synfor ich kann Dir nur zustimmen, es ist nicht klar was da genau im Hintergrund passiert ist. Das kann ich leider auch nicht nachvollziehen.
Also bei mir ist dann natürlich der Speicherpool gecrashed, da ja keine Verbindung mehr bestanden hat.
Naja, da passiert schon etwas mehr wenn sich ein Volume im schreibgeschützten Modus befunden hat.
  • Überprüfung vom Volume (unter anderen syno_disk_volume_check, SMART-Status)
  • Reparatur vom Volume (defekte Metadaten oder falsche Verknüpfungen etc.)
  • Oder wenn was grobes nicht passt, Reparatur über fsck oder btrfs
  • Wenn alles wieder OK, dann wird es wieder gemountet bzw. Schreiben wieder möglich.

Und ja, da gibt es definitiv einen Zusammenhang.
Crash: 29.12. um 00:33

Hibernation wake up log vom 28.12 und bis vor zum Juni 2025 zeigen kontenuierliches aufwachen der Platten.
Hibernation_wake_up_before_crash.png

Seit dem Crash und der anschließenden Reparatur gibt es dieses Verhalten nicht mehr, das ist fix.
Hibernation_wake_up_after_crash.png
Somit ist sicher, dass die Reperatur das Problem behoben hat, aber nicht klar was genau passiert ist bzw. gelöscht / repariert wurde.

Ich wollte das nur kommunizieren, damit man eventuell auch in diese Richtung schaut, falls jemand ein ähnliches Problem hat. Schaden kann es auf jeden Fall nicht.
Ich bin mir sicher, dass dieses Event den Fehler behoben hat, da es durch logs dokumentiert ist und Pasta. 🍝
Warum ist mir in dem Moment auch egal, da es wirklich viele Nerven gekostet hat und ich einfach nur glücklich bin, dass es funktioniert. 😇

LG, Tommily
 

Additional post fields

 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat