Apps von Volume(x) nach Volume(y) verschieben

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.475
Punkte für Reaktionen
1.087
Punkte
194
  • Haha
Reaktionen: Benie

Caramlo

Benutzer
Mitglied seit
11. Mai 2019
Beiträge
224
Punkte für Reaktionen
64
Punkte
34
Ich habe gestern mein Container Manager Paket auf mein NVME Laufwerk verschoben. Hatte beim Test auch die Meldung mit den unbekannten Symlinks. Hab‘ mir dann gedacht: “Mut zur Lücke, habe ja ein Backup” 😄 und dann einfach mal alles verschoben.
Habe keine Probleme gehabt, alle Container sind ohne Probleme wieder gestartet und laufen. Die Anwendungsdaten habe ich allerdings nicht verschoben, die liegen weiterhin auf der HDD.
Bin auf meiner 720+ bei DSM 7.2-64570 Update 3.

Danke für das tolle Script! 👍🏻
 

ctrlaltdelete

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
30. Dez 2012
Beiträge
13.633
Punkte für Reaktionen
5.809
Punkte
524
@Caramlo mit dem script release von 2016?
 

ctrlaltdelete

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
30. Dez 2012
Beiträge
13.633
Punkte für Reaktionen
5.809
Punkte
524
@zotac94 gab es beim Verschieben Probleme mit Synology Photos, Alben weg oder so etwas?
 

Caramlo

Benutzer
Mitglied seit
11. Mai 2019
Beiträge
224
Punkte für Reaktionen
64
Punkte
34
@ctrlaltdelete : Jau, mit dem Script von 2016. Habe dann später allerdings festgestellt, dass die Container trotzdem noch auf meinem HDD-Volume liefen. Ich habe dann
- den Container Manager gestoppt
- die Container exportiert
- den freigegebenen Ordner „Docker“ auf die NVME verschoben (über Systemsteuerung)
- und den Container Manager deinstalliert.
Dann alles was mit Docker etc. auf dem HDD-Volume lag von der Platte geputzt und den Container Manager auf dem NVME Volumen wieder installiert. Nach dem Start die Container wieder importiert und gestartet. Alles reibungslos funktioniert. Die Container liegen dann auf dem NVME-Volumen.
Die Daten meines Paperless-NGX habe ich auf der HDD gelassen. Die Paperless Ordner liegen bei mit nicht im Docker Ordner, sondern auf einem anderen freigegebenen Ordner. Die Yaml habe ich unverändert gelassen und den Stack neu gestartet. Dann laufen die Container auf der NVME und die Daten auf der HDD. Könnte man natürlich auch mit auf die NVME umziehen, muss dann aber die Yaml anpassen und die Ordner verschieben.
Ob ich den Container Manager hätte deinstallieren müssen - fraglich. Der war ja schon auf dem NVME Volumen. Erschien mir aber der sicherere Weg.
 

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.475
Punkte für Reaktionen
1.087
Punkte
194
@ctrlaltdelete trau dich mal bitte für mich und gib mir Feedback, ob Photos auch bei dir im Nachgang noch sauber funktioniert hat!
Vielleicht traue ich mich dann auch! 🤡
 
  • Haha
Reaktionen: ctrlaltdelete

Benjamin83

Benutzer
Mitglied seit
09. Nov 2018
Beiträge
15
Punkte für Reaktionen
8
Punkte
53
Hallo zusammen,

Durch die positiven Meldungen hier im Thread motiviert habe ich gestern beschlossen die Apps auf meiner DS mit DSM 7.2-64570 Update 1 mittels des Scripts auf die SSD zu verschieben. Es hat funktioniert; wenn auch nicht ganz Reibungslos.

Hier ist der Ablauf, auf das andere es vielleicht etwas leichter haben:

Ausführen des Scripts als root:
Bash:
ash-4.4# sh app_mover_v0.2.sh /volume2 /volume3/ notest
***   move apps on /volume2 to /volume3/   ***
Do you really want to do this [Y|y|Yes|yes] (default=No)? y

***  looking for apps in /var/packages  ***
package "FileStation"
    /usr/local/packages/@appstore/FileStation need no adjustment, app will be ignored!
    /var/packages/FileStation/home     - unknown SymLink, pls adjust yourself!
    /var/packages/FileStation/var     - unknown SymLink, pls adjust yourself!
    /var/packages/FileStation/tmp     - unknown SymLink, pls adjust yourself!
    /var/packages/FileStation/share     - unknown SymLink, pls adjust yourself!
package "AudioStation"
package "GlacierBackup"
    /volume2/@appstore/GlacierBackup
    stopping GlacierBackup...done
    move from /volume2 to /volume3/...done
    symLink source will be adjusted to //volume3//@appstore/GlacierBackup...done
    starting GlacierBackup...could not be started!
    /var/packages/GlacierBackup/home     - unknown SymLink, pls adjust yourself!
    /var/packages/GlacierBackup/var     - unknown SymLink, pls adjust yourself!
    /var/packages/GlacierBackup/tmp     - unknown SymLink, pls adjust yourself!
    /var/packages/GlacierBackup/share     - unknown SymLink, pls adjust yourself!
package "USBCopy"
    /usr/local/packages/@appstore/USBCopy need no adjustment, app will be ignored!
    /var/packages/USBCopy/home     - unknown SymLink, pls adjust yourself!
    /var/packages/USBCopy/var     - unknown SymLink, pls adjust yourself!
    /var/packages/USBCopy/tmp     - unknown SymLink, pls adjust yourself!
    /var/packages/USBCopy/share     - unknown SymLink, pls adjust yourself!
...
...
...

Die Ausgabe geht dann Paket für Paket so weiter; mutmaßlich alle Apps betroffen.

Hier ein Beispiel wie eine App-Verzeichniss dann aussah:
Bash:
ash-4.4# ls -al
total 76
drwxr-xr-x  4 root root  4096 Dec 13 23:49 .
drwxr-xr-x 34 root root  4096 Dec 13 05:19 ..
drwxr-xr-x  3 root root  4096 Dec 13 23:49 conf
lrwxrwxrwx  1 root root    27 Nov  2 14:44 etc -> /volume2/@appconf/AntiVirus
lrwxrwxrwx  1 root root    27 Nov  2 14:44 home -> /volume2/@apphome/AntiVirus
-rw-r--r--  1 root root 60692 Nov  2 14:44 INFO
drwxr-xr-x  3 root root  4096 Nov  2 14:44 scripts
lrwxrwxrwx  1 root root    28 Nov  2 14:44 share -> /volume2/@appshare/AntiVirus
lrwxrwxrwx  1 root root    30 Dec 13 23:49 target -> //volume3//@appstore/AntiVirus
lrwxrwxrwx  1 root root    27 Nov  2 14:44 tmp -> /volume2/@apptemp/AntiVirus
lrwxrwxrwx  1 root root    27 Nov  2 14:44 var -> /volume2/@appdata/AntiVirus

Es fällt sofort der target-Link mit den doppellen / auf, ich habe aber trozdem erstmal weitergemacht indem ich die nicht automatisch angepassten Links mit einem kleinen Script korrigiert habe:

Bash:
#!/bin/bash

directory="/var/packages/"
search_string="/volume2/"
replace_string="/volume3/"

find "$directory" -type l -name "*" | while read -r link; do
    path=$(readlink "$link")
    if [[ $path == *"$search_string"* ]]; then
        new_path=$(echo "$path" | sed "s|$search_string|$replace_string|")
        
        echo "Link: $link"
        echo "Current Path: $path"
        echo "New Path: $new_path"
        
        rm "$link"
        ln -s "$new_path" "$link"
        
        echo "Updated: $link"
    fi
done

Die Apps ließen sich jedoch weder starten, noch neu installieren oder reparieren. Ja noch nicht mal sauber im appmanager aufrufen.

Also habe ich erst nach den Datenverzeichnisse (@appconf, @appdata, @apphome etc.) gesehen. Das neue Volume war fast leer, das ursprünglich hatte jemde Menge Inhalt. Also habe ich per rsync alle @-Verzeichnisse aufs neue Volume verschoben. Das ging relativ lange, vor allem die Dockerverzeichnisse mit ihren tausenden kleiner Files.

Jedoch weiterhin keine Chance die Apps zu starten oder zu kopieren.

Also habe ich noch die doppelten / in den "target-Links" korrigiert:
Bash:
]#!/bin/bash

directory="/var/packages"

find "$directory" -type l -name "target" | while read -r link; do
    path=$(readlink "$link")
    
    # Korrigiere den doppelten Schrägstrich am Anfang des Pfads
    path=$(echo "$path" | sed 's|^//|/|')
    # Korrigiere den doppelten Schrägstrich in der Mitte des Pfads
    path=$(echo "$path" | sed 's|//@|/@|')
    
    echo "Link: $link"
    echo "Current Path: $path"
    
    rm "$link"
    ln -s "$path" "$link"
    
    echo "Updated: $link"
done

Und siehe da, schon ließen sich die Apps reparieren und anschließend auch starten.

Komischerweise sind aber app-inhalte verloren gegangen, zum Beispiel waren alle Container im Containermanager "verschwunden" (Gestoppt hatte ich sie eh) und das mcVlan war auch nicht mehr vorhanden. (Ein Problem war das nich, weil ich alle Scripte die ich brauchte im Aufgabenplander hinterlegt habe.) Andere Apps habe ich noch nicht überprüft.

Instesammt hat die ganze Aktion gut 2h gedauert und war Erfolgreich, wenn auch mit ein paar Hindernissen.
Viele Grüße
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Mitglied seit
28. Okt 2020
Beiträge
15.028
Punkte für Reaktionen
5.401
Punkte
564
Sauber. Danke für die Anleitung.
Vielleicht war diese 2h-Aktion dennoch schneller, als das Neuinstallieren aller Apps + Backup einspielen + Nachkonfigurieren.
Es wird aber meiner Meinung nach Zeit, dass Synology selbst eine Lösung anbietet im Paket-Zentrum, die Apps zu verschieben. Denn offensichtlich geht es ja. Hierzu mal wieder der Link: Feature Request
 

Benjamin83

Benutzer
Mitglied seit
09. Nov 2018
Beiträge
15
Punkte für Reaktionen
8
Punkte
53
Na du kennst doch das alte Credo: Warum etwas in 1 h manuell tun, wenn man auch 1 Tag daran verzweifeln kann es zu automatisieren. :)

Featurerequest ist gemacht.

Als Anleitung habe ich meinen Beitrag übrigens nicht verstanden. Eher als Bericht dessen was ich getan habe um ein Problem zu lösen, das ich nicht verstanden habe. Ich weiß nicht, was davon sinvoll war und was unnötig, oder ob ich den Fehler nicht vielleicht sogar selbst ausgelöst habe. 🤷‍♀️
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.541
Punkte für Reaktionen
1.373
Punkte
234
Ich fände es gut (solange es keine offizielle Möglichkeit im DSM gibt), dieses Skript von @QTip mal etwas auf aktuelle Beine zu stellen.
Hättest du vielleicht Lust, wenn du dich gerade damit etwas näher beschäftigt hast? Ich meine hier keine Generalüberholung, sondern einfach die Anpassungen zum aktuellen DSM, die teilweise offensichtlich zu Stolperfallen führen.

Vielleicht wäre Github ein gutes zu Hause, wo auch andere ihre Verbesserungen mit einbringen können.

Leider kann ich mir aktuell dafür nicht bereitstellen, weil noch zu viele andere Baustellen offen sind.
 
  • Like
Reaktionen: Benie

Benjamin83

Benutzer
Mitglied seit
09. Nov 2018
Beiträge
15
Punkte für Reaktionen
8
Punkte
53
Ich fände es gut (solange es keine offizielle Möglichkeit im DSM gibt), dieses Skript von @QTip mal etwas auf aktuelle Beine zu stellen.
Hättest du vielleicht Lust, wenn du dich gerade damit etwas näher beschäftigt hast? Ich meine hier keine Generalüberholung, sondern einfach die Anpassungen zum aktuellen DSM, die teilweise offensichtlich zu Stolperfallen führen.

Vielleicht wäre Github ein gutes zu Hause, wo auch andere ihre Verbesserungen mit einbringen können.

Leider kann ich mir aktuell dafür nicht bereitstellen, weil noch zu viele andere Baustellen offen sind.
Das Script anpassen würde ich wahrscheinlich hinbekommen. (Mit KI Hilfe verliert shell einem guten Teil seiner Schrecken:))
Es bei GitHub zu hinterlegen wohl auch.
Aber wie schon geschrieben habe letztendlich überhaupt keine Ahnung was tatsächlich zu tun ist.
Wenn mit jemand aufschreibt was zu tun ist könnte ich es umsetzen.
 

Synchrotron

Benutzer
Sehr erfahren
Mitglied seit
13. Jul 2019
Beiträge
5.096
Punkte für Reaktionen
2.065
Punkte
259
Habe es gerade genutzt, DSM 7.2.1 Update 3.

Umzug von Volume1 (SATA SSD) auf Volume2 (NVME). Alle Pakete i.o., bis auf Node x.x (2x) und Perl. Die waren mit einem Klick im Paketzentrum repariert.

Der VMM ist auch umgezogen. Das virtuelle Datenvolume habe ich in der VMM umziehen müssen.

Docker hatte ich noch nicht auf dieser DS, daher keine Erfahrung.
 

Nierotter

Benutzer
Mitglied seit
02. Nov 2012
Beiträge
135
Punkte für Reaktionen
26
Punkte
34
So, nun haben wir meinen Server auch vom 16TB Limit befreit. Habe die Gelegenheit genutzt und 2x 1TB M2 eingesetzt und via Script von Qtip alle Pakete auf die M2 verschoben. Dann nachdem 2 Tage lang alles gesichert wurde das Volume mit der 15,7TB Größe gelöscht und neu angelegt. Das natürlich gleich in BTRFS und nun mit 25TB endlich wieder Luft zum atmen.
Ohne dieses Script wäre das nicht möglich gewesen, auch nach so vielen Jahren lief alles sehr gut durch und bedarf nur ein paar Anpassungen via Paketmanager. Dies haben wir gut hinbekommen, nicht zuletzt mit Hilfe von ctrlaltdelete

liebe grüße aus dem hohen Norden
SvenB
 

Benie

Benutzer
Contributor
Sehr erfahren
Mitglied seit
19. Feb 2014
Beiträge
8.473
Punkte für Reaktionen
3.510
Punkte
344
Es gibt ein neues Appmover Script, -> auf Github entdeckt,

stammt vom selben Entwickler der auch das NVME Script entwickelt hat und betreut.

Synology_app_mover

Verschiebe Synology-Pakete ganz einfach von einem Volume auf ein anderes.

Wähle einfach das Paket und das Zielvolume aus und das Skript stoppt die App, verschiebt sie, aktualisiert die Symlinks und startet dann die App. Praktisch zum Verschieben von Paketen auf ein SSD-Volume oder auf ein anderes Volume, sodass Sie das ursprüngliche Volume löschen können.
Unterstützt DSM 7. mit DSM 6 getestet.

Ich selbst habe ich es bisher noch nicht getestet, da aktuell nichts zum verschieben ist.
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Es gibt ein neues Appmover Script…
Haha… der Entwickler ist mir direkt sympathisch, hat er doch u.a. mein LogAnalysis getestet. 😃

Ich glaub, das schau ich mir am Wochenende mal an und teste das ggfl. noch mit einen andern Paketen.
 

Synchrotron

Benutzer
Sehr erfahren
Mitglied seit
13. Jul 2019
Beiträge
5.096
Punkte für Reaktionen
2.065
Punkte
259
Klingt interessant: Mit der bisherigen Methode hatte ich einigen Reparaturbedarf. Nichts kritisches, aber es dauert etwas, bis man alles 1x geöffnet und (meistens) über die Autokorrektur wieder glatt gezogen hat.
 

ctrlaltdelete

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
30. Dez 2012
Beiträge
13.633
Punkte für Reaktionen
5.809
Punkte
524
Das ist auch interessant:

007revad commented 3 hours ago

I've been working on a new version that has an option to backup or restore all packages. It should be ready in the next 24 hours.
 


 

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