Ich hatte auch ein Ticket beim QNAP Support geöffnet und die haben geraten Qsync zu beenden.
Anfangs ging der NAS nicht wirklich in Standby, aber nun klappt es sehr häufig.
Time steht auf 5 Minuten.
Bin mal gespannt wie die nächsten Tage laufen.
Ich hatte auch ein Ticket beim QNAP Support geöffnet und die haben geraten Qsync zu beenden.
Anfangs ging der NAS nicht wirklich in Standby, aber nun klappt es sehr häufig.
Time steht auf 5 Minuten.
Bin mal gespannt wie die nächsten Tage laufen.
Ah, stimmt ja. Das wird es dann nicht sein. Was ist denn noch installiert? (wobei jede Minute um 04:00 auch nicht so prickelnd ist)
Ja, komisch. Gibt ja noch nen 2. Eintrag mit diesen Angaben in meiner crontab.
Aktuell läuft gerade wieder mal blkdevMonitor_v2*.sh, das ich vom Helpdesk aus gestartet habe.
Hier der aktuelle Output (letzte Zeilen gelöscht, da sonst über 10.000 Zeichen):
===== Welcome to use blkdevMonitor_v2 on Sat Aug 29 19:58:19 CEST 2020 =====
Stop klogd.sh daemon... Done
Turn off/on VM block_dump & Clean dmesg
Countdown: 3 2 1 Start...
============= 0/100 test, Sat Aug 29 19:58:25 CEST 2020 ===============
<74<<7>[784699.053859] hal_enc_temp(2350)<7>[784699.056556] hal_enc_temp(2350): dirt<<7>[784699.060984] md9_raid1(2219): WRITE block 1060216 on unknown-block(8,0) (1 sectors)
============= 1/100 test, Sat Aug 29 19:58:38 CEST 2020 ===============
<7>[786581.599787] setcfg(11083): dirtied inode 13886 (CACHEDEV1_DATA.log) on md9
============= 2/100 test, Sat Aug 29 20:30:01 CEST 2020 ===============
<<7>[786670.939895] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
============= 3/100 test, Sat Aug 29 20:31:30 CEST 2020 ===============
<<<7>[788561.104650] md9_raid1(2219): WRITE block 1060216 on unknown-block(8,0) (1 sectors)
============= 4/100 test, Sat Aug 29 21:03:00 CEST 2020 ===============
<7>[788605.885930] md9_raid1(2219): WRITE block
============= 5/100 test, Sat Aug 29 21:03:45 CEST 2020 ===============
<<7>[789103.295738] jbd2/md9-8(2232): WRITE block 849400 on unknown-block(9,9) (8 sectors)
============= 6/100 test, Sat Aug 29 21:12:02 CEST 2020 ===============
<7>[789185.452611] md9_raid1(2219): WRITE block 1060216 on unknown-block(8,0) (1 sectors)
============= 7/100 test, Sat Aug 29 21:13:24 CEST 2020 ===============
<7>[791949.802384] md9_raid1(2219): WRITE block 1060216 on unknown-bloc
============= 8/100 test, Sat Aug 29 21:59:29 CEST 2020 ===============
<7>[792107.941358] md9_raid1(2219): WRITE block 1060216 on unknown-block(8,0) (1 sectors)
============= 9/100 test, Sat Aug 29 22:02:07 CEST 2020 ===============
<<<<<<<<<7>[794362.439720] jbd2/md9-8(2232): WRITE block 812320 on unknown-block(9,9) (8 sectors<<<<<<<<
============= 10/100 test, Sat Aug 29 22:39:41 CEST 2020 ===============
<7>[796403.100034] jbd2/dm-0-8(2691): WRITE block 15465520056
============= 11/100 test, Sat Aug 29 23:13:42 CEST 2020 ===============
<<7>[798933.213881] jbd2/md9-8(2232): WRITE block 849880 on unknown-block(9,9) (8 sectors)
============= 12/100 test, Sat Aug 29 23:55:52 CEST 2020 ===============
<7>[802081.109827] userConfig.cgi(23352): dirtied inode 13483 (config.tmp) on md9
<7>[802081.524572] appRequest.cgi(23368): dirtied inode 13819 (last_uptime_ger) on md9
<7>[802081.524577] appRequest.cgi(23368): dirtied inode 13819 (last_uptime_ger) on md9
<7>[802081.524840] appRequest.cgi(23368): dirtied inode 13785 (?) on md9
============= 13/100 test, Sun Aug 30 00:48:21 CEST 2020 ===============
<<<7>[802112.793496] md1_raid<<<<<<<<<<<<<<<<<<<<<<<<7>[802112.909439] jbd2/md9-8(2232): WRITE block 814184 on unknown-block(9,9) (8 se<<<<<<<<<<<<<<<<<<<<7>[802112.909797] jbd2/md9-8(2232): WRITE block 25952 on unkn<<<<
<<<7>[802112.793496] md1_raid<<<<<<<<<<<<<<<<<<<<<<<<7>[802112.909439] jbd2/md9-8(2232): WRITE block 814184 on unknown-block(9,9) (8 se<<<<<<<<<<<<<<<<<<<<7>[802112.909797] jbd2/md9-8(2232): WRITE block 25952 on unkn<<<<
============= 14/100 test, Sun Aug 30 00:48:52 CEST 2020 ===============
<<7>[802913.335470] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
============= 15/100 test, Sun Aug 30 01:02:13 CEST 2020 ===============
<<7>[803068.616537] jbd2/md9-8(2232): WRITE block 850328 on unknown-block(9,9) (8 sectors)
============= 16/100 test, Sun Aug 30 01:04:48 CEST 2020 ===============
<7>[803518.818532] jbd2/md9-8(2232): WRITE block 4128 on unknown-block(9,9) (8 sectors)
<7>[803518.818541] jbd2/md9-8(2232): WRITE block 4136 on unknown-block(9,9) (8 sectors)
<7>[803518.818547] jbd2/md9-8(2232): WRITE block 4144 on unknown-block(9,9) (8 sectors)
<7>[803518.818553] jbd2/md9-8(2232): WRITE block 4152 on unknown-block(9,9) (8 sectors)
<7>[803518.818557] jbd2/md9-8(2232): WRITE block 4160 on unknown-blo
============= 17/100 test, Sun Aug 30 01:12:18 CEST 2020 ===============
<7>[803871.451457] jbd2/md9-8(2232): WRITE block 792808 on unknown-block(9,9) (8 sectors)
============= 18/100 test, Sun Aug 30 01:18:10 CEST 2020 ===============
<<7>[806091.665270] jbd2/md9-8(2232): WRITE block 23072 on unknown-block(9,9) (8 sectors)
============= 19/100 test, Sun Aug 30 01:55:11 CEST 2020 ===============
<7>[806759.681186] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
============= 20/100 test, Sun Aug 30 02:06:19 CEST 2020 ===============
<<7>[807205.569182] jbd2/md9-8(2232): WRITE block 31560 on unknown-block(9,9) (8 sectors)
============= 21/100 test, Sun Aug 30 02:13:45 CEST 2020 ===============
<<<<7>[808557.914931] md9_raid1(2219): WRITE block 1060216 on unknown-block(8,0) (1 sectors)
============= 22/100 test, Sun Aug 30 02:36:17 CEST 2020 ===============
<7>[809181.328901] md9_raid1(2219): WRITE block 1060216 on unknown-block(8,0) (1 sectors)
============= 23/100 test, Sun Aug 30 02:46:40 CEST 2020 ===============
<7>[809488.301857] md9_raid1(2219): WRITE block 1060232 on unknown-block(8,0) (1 sectors)
============= 24/100 test, Sun Aug 30 02:51:47 CEST 2020 ===============
<7>[809981.772569] sh(12301): READ block 29003874448 on unknown-block(253,0) (16 s<7>[809981.773121] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
<7>[809981.772569] sh(12301): READ block 29003874448 on unknown-block(253,0) (16 s<7>[809981.773121] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
============= 25/100 test, Sun Aug 30 03:00:01 CEST 2020 ===============
<7>[809985.822023] 19_rule.rule_20(16317): dirtied inode 6653 (QcloudSSLCertificate) on md9
============= 26/100 test, Sun Aug 30 03:00:05 CEST 2020 ===============
<7>[809986.722993] vs_refresh(12296): dirtied inode 588259282 (thumbnails) on dm-0
============= 27/100 test, Sun Aug 30 03:00:06 CEST 2020 ===============
<7>[810000.261028] vs_refresh(12296): dirtied inode 278266051 (8A99E2CBCC2F1AA7A78B82B31C5623B5) on dm-0
============= 28/100 test, Sun Aug 30 03:00:20 CEST 2020 ===============
<7>[810002.054023] vs_refresh(12296): dirtied inode 271450529 (923D264C3075FC6658210F9B7BF501FD) on dm-0
============= 29/100 test, Sun Aug 30 03:00:21 CEST 2020 ===============
<7>[810008.503086] vs_refresh(12296): dirtied inode 235536399 (4B488C0369C44D5ABB8EDD4B7A4EEBA2) on dm-0
<7>[810008.503157] vs_refresh(12296): dirtied inode 235536417 (8DAAACC0E3B54F94503E5D7B8E029506) on dm-0
<7>[810008.503196] vs_refresh(12296): dirtied inode 23553<<<<<7>[810008.504902] vs_refresh(12296): dirtied inode 235274859 (39EDF2DAE7F69A6C4D5DF413E987CB08) on dm-0
============= 30/100 test, Sun Aug 30 03:00:28 CEST 2020 ===============
<7>[810013.462857] vs_refresh(12296): dirtied inode 230031672 (837FFB8B574E451D6BAA4F4361203A73) on dm-0
============= 31/100 test, Sun Aug 30 03:00:33 CEST 2020 ===============
<7>[810016.400982] vs_refresh(12296): dirtied inode 227279526 (DayTripperFunky Schnappschuss 16.12.2018, 21:19:41) on dm-0
============= 32/100 test, Sun Aug 30 03:00:36 CEST 2020 ===============
<7>[810025.009896] vs_refresh(12296): dirtied inode 709361833 (Unbekanntes Album) on dm-0
<7>[810025.009943] vs_refresh(12296): dirtied inode 709361834 (Enema Of The State) on dm-0
============= 33/100 test, Sun Aug 30 03:00:44 CEST 2020 ===============
<<<<<<<<<<<<<<<<<<<<<<<7>[810038.706293] jbd2/dm-0-8(2691): WRITE block 15465527752 on unknown-b<<<<<<<<<<<<<7><<<<<<<<<
============= 34/100 test, Sun Aug 30 03:00:58 CEST 2020 ===============
<<7>[810079.473909] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
============= 35/100 test, Sun Aug 30 03:01:40 CEST 2020 ===============
<7>[814875.609530] jbd2/md9-8(2232): WRITE block 25528 on unknown-block(9,9) (8 sectors)
============= 36/100 test, Sun Aug 30 04:21:34 CEST 2020 ===============
<<7>[815151.833460] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
<7>[815151.833477] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
============= 37/100 test, Sun Aug 30 04:26:10 CEST 2020 ===============
<7>[818848.046202] jbd2/md9-8(2232): WRITE block 812736 on unknown-block(9,9) (8 sectors)
============= 38/100 test, Sun Aug 30 05:27:46 CEST 2020 ===============
<7>[818981.965499] setcfg(3834): dirtied inode 13840 (CACHEDEV1_DATA.log) on md9
============= 39/100 test, Sun Aug 30 05:30:01 CEST 2020 ===============
<<7>[820360.538048] jbd2/md9-8(2232): WRITE block 849880 on unknown-block(9,9) (8 sectors)
============= 40/100 test, Sun Aug 30 05:52:59 CEST 2020 ===============
<<<7>[821164.761327] md9_raid1(2219): WRITE block 1060232 on unknown-block(8,0) (1 sectors)
============= 41/100 test, Sun Aug 30 06:06:24 CEST 2020 ===============
<<7>[821553.880921] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
<7>[821553.880943] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
============= 42/100 test, Sun Aug 30 06:12:52 CEST 2020 ===============
<7>[822724.146887] jbd2/md9-8(2232): WRITE block 814696 on unknown-block(9,9) (8 sectors)
============= 43/100 test, Sun Aug 30 06:32:23 CEST 2020 ===============
<<7>[823977.369722] rsyslogd(8324): dirtied inode 6645 (kmsg) on md9
============= 44/100 test, Sun Aug 30 06:53:18 CEST 2020 ===============
<<<<7>[831373.147115] jbd2/md9-8(2232): WRITE block 849200 on unknown-block(9,9) (8 sectors)
============= 45/100 test, Sun Aug 30 08:56:31 CEST 2020 ===============
<7>[832166.814928] md9_raid1(2219): WRITE block 1060216 on unkno
============= 46/100 test, Sun Aug 30 09:09:45 CEST 2020 ===============
<<7>[832812.375989] jbd2/md9-8(2232): WRITE block 850544 on unknown-block(9,9) (8 sectors)
Alles anzeigen
Ich habe bei weiterem Recherchieren noch Hinweise gesehen, dass das auch rein aus der HDD Firmware heraus getriggert werden könnte.
Also dieses alle 6 - 8 Sekunden erfolgende "Klacken" könnte auch das permanente Anfahren der Parkposition des Festplattenkopfes sein.
Allerdings müsste doch die HDD auch in den Sleepmode gehen, wenn das NAS das ansteuert!?
Kennt jemand hier so sein Verhalten?
Vielen Dank!
So nun muss auch ich mal wieder mit dem Thema standby nerven.
Mein System:
TS-253D-4G mit 1x Seagate 16TB ST16000NE000
Output von /root/blkdevMonitor_20151225.sh (auch stundenlanges laufen lassen liefert da keine weiteren Erkenntnisse):
[~] # /root/blkdevMonitor_20151225.sh
===== Welcome to use blkdevMonitor_v2 on Sun Aug 23 20:11:20 CEST 2020 =====
Stop klogd.sh daemon... Done
Turn off/on VM block_dump & Clean dmesg
Countdown: 3 2 1
Start...
============= 0/100 test, Sun Aug 23 20:11:27 CEST 2020 ===============
<7>[268818.924396] md9_raid1(2219): WRITE block 1060232 on unknown-block(8,0) (1 sectors)
============= 1/100 test, Sun Aug 23 20:40:40 CEST 2020 ===============
<7>[268865.234174] md9_raid1(2219): WRITE block 1060216 on unknow
============= 2/100 test, Sun Aug 23 20:41:26 CEST 2020 ===============
<<7>[269202.824220] jbd2/md9-8(2232): WRITE block 858232 on unknown-block(9,9) (8 sectors)
============= 3/100 test, Sun Aug 23 20:47:03 CEST 2020 ===============
<7>[269229.448102] md9_raid1(2219): WRITE block 1060216 on unknown-block(8,0) (1 sectors)
============= 4/100 test, Sun Aug 23 20:47:31 CEST 2020 ===============
^C
[~] #
Alles anzeigen
Hier meine crontab ("# 0-59/15 * * * * /etc/init.d/nss2_dusg.sh" breits erledigt):
[~] # crontab -l
# m h dom m dow cmd
0 2 * * * /sbin/qfstrim
0-59/20 3 * * * /sbin/adjust_time
0 1 * * * /etc/init.d/flush_memory.sh >/dev/null 2>&1
0 4 * * * /sbin/hwclock -s
0 3 * * * /sbin/vs_refresh
0 3 * * * /sbin/clean_reset_pwd
# 0-59/15 * * * * /etc/init.d/nss2_dusg.sh
30 7 * * * /sbin/clean_upload_file
0-59/10 * * * * /etc/init.d/storage_usage.sh
30 3 * * * /sbin/notice_log_tool -v -R
*/10 * * * * /sbin/config_cache_util 0
32 9,21 * * * /sbin/notify_update --nc 1>/dev/null 2>&1
10 15 * * * /usr/bin/power_clean -c 2>/dev/null
00 03 * * * sh /share/CACHEDEV1_DATA/.qpkg/MalwareRemover/MalwareRemover.sh scan;#_QSC_:MalwareRemover:malware_remover_schedule:None:d::
00 02 * * * sh /share/CACHEDEV1_DATA/.qpkg/MalwareRemover/Upgrade.sh;#_QSC_:MalwareRemover:malware_remover_upgrade:None:d::
19 1 * * * /share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/scripts/insight/insight.sh -runall >/dev/null 2>&1
0 3 * * 0 /etc/init.d/idmap.sh dump
* * * * * /var/cache/netmgr/lock_timer.sh
* 4 * * * /usr/sbin/logrotate /etc/config/mariadb_mc.logr
0 4 * * * /etc/init.d/wsd.sh restart
0 2 * * 0 /usr/local/medialibrary/bin/mymediadbcmd checkRepairDB >/dev/null 2>&1
0 12 * * * /mnt/ext/opt/LicenseCenter/bin/qlicense_tool local_check
0 0 * * * /usr/local/sbin/qsh nc.archive >/dev/null 2>&1
04 19 * * * /mnt/ext/opt/QcloudSSLCertificate/bin/ssl_agent_cli
35 7 * * * /sbin/qsyncsrv_util -c > /dev/null 2>/dev/null
0 0 * * * /sbin/qsyncsrv_tool --fix > /dev/null 2>/dev/null
* 4 * * * /usr/sbin/logrotate /etc/config/mc_logr.conf
4 3 * * 3 /etc/init.d/backup_conf.sh
[~] #
Alles anzeigen
Das Sonderbare ist, das immer im Abstand von 6 Sekunden ein HDD Zugriff erfolgt (gut hörbat als "tacken") und im Ressorcenmonitor ist auch alle 6 Sekunden ein Schreibzugriff mit 2/s (max. 3/s, min. 1/s) zu sehen.
Das Netzwerkkabel habe ich auch schon gezogen - alles ohne Erfolg.
Der Prozess "ext4lazyinit" ist übrigens auch nicht in der Prozessliste zu sehen.
Gibt es weitere Ideen?
Vielen Dank schon mal!
Gruß ausm Keller
Also nun komme ich doch in der FileStation 5 weiter.
Ich verschiebe einfach die Ordner, die ja bereits alle eine Ordnerebene zu tief liegen, eine Ebene höher und das klappt bei den meisten Ordnern nur durch einen Verzeichniseintrag im Filesystem. D.h. das geht in Sekundenbruchteilen.
Aber andere Ordner verschiebt er dann doch wieder File für File - echt komisch ...
Und ich bin nun ja auf der ext. 8TB WD HDD, die per USB3 angeschlossen ist.
Ansonsten habe ich 1GBit/s zw. beiden NAS und komme da tw. doch auf bis zu 66MB/s.
Dir auf jeden Fall vielen Dank für die tatkräftige und schnelle Unterstützung!
Jetzt muss ich nur noch mein Zugriffsproblem vom Mac aus in den Griff gekommen - der Finder lässt sich nicht per AFP connecten, obwohl in der 253D alles aktiviert ist ... :-|
Viele Grüße,
(auch) Udo
Sind so 10 - 15 Stk.
In der FileStation bin ich auch bereits, aber die Ordner haben zw. 1TB und 4TB Daten und da wäre eine Sequenzialisierung der Aufträge nützlich, sonst muss ich a) die Sachen individuell per Hand starten, oder b) alle Paare kurz hintereinander manuell starten, dann laufen die HDD Zugriffe aber parallel und durch die Kopf-Positionierung wird alles seeehr laaaangsam ...
Vielen Dank trotzdem!
Viele Grüße,
Udo
So ich kämpfe nun schon seit Donnerstag mit dem Zugrückspielen / bzw. Kopieren der Daten vom TS-219P -> TS-253D.
Mein erster Versuch per Rsync vom 219P aus ist aufgrund extermer Langsamkeit gescheitert.
Ich habe ca. 7TB Daten und die Vorhersage lag im Bereich 10 - 15 Tage!!
Da ich am 219P eh eine ext. 8TB Platte zur Sicherung verwende, habe ich nochmals eine aktuelle Sicherung vom 219P auf die ext. 8TB gemacht und dann per HBS 3 und "Wiederherstellung" die Daten von ext. 8TB -> 253D zurück gespielt.
Dachte ich zumindest, denn obwohl ich immer sauber Ordnerpaare angegeben habe, wurde mir im Ziel immer <Ordnername>/<Ordnername> angelegt.
Also z.B. liegt auf (der externen Platte) "Disk1Ext8TB/transfer" und soll auf (die interne Platte) "DataVol1/transfer" zurück gespielt werden, landet dann dort aber unter "DataVol1/transfer/transfer". Es gibt keine Möglichkeit im Ziel quasi die root "/" anzugeben.
Wie schaffe ich es meine Daten von Quelle:
/Ordner_1
/Ordner_2
/Ordner_3
...
/Ordner_n
auf das Ziel:
/Ordner_1
/Ordner_2
/Ordner_3
...
/Ordner_n
zu kommen?
Besten Dank und Gruß ausm Keller
Vielen Dank für die Info.
Bist Du sicher, dass die Konfig nicht übernommen werden kann?
Ich hatte bei QNAP eine "Kompatibilitätsmatrix" für Migration gefunden und da war von TS-x19 auf TSx53 als möglich angegeben.
Die Daten dann eh per NAS to NAS Funktion?
Ich habe mir eine TS-253D + 16TB HDD bestellt und möchte alle Settings meiner bisherigen TS-219 übernehmen. Klar dass ich die Dateien dann noch separat kopieren muss.
Aber meine Frage ist, ob ich das richtig sehe:
Geht die Migration von der TS-219 (2x 4TB) auf die TS-253D einfach per Settings Backup -> Restore in QTS?
Wie würdet Ihr die Daten kopieren? Was geht bei QTS und einer 1GBit/s Verbindung am schnellsten/besten?
Vielen Dank!
Gruß ausm Keller
Kein Problem – ist halt leider immer noch aktuell!
Uups, das war nicht ich sondern silencshadow
Ganz dumm gefragt:
Was ist ein Plex Ordner?
Meine Indizierung läuft über QMultimedia als normalen Freigabe Ordner.
Edith: nachdem ich gerade meine iTunes Bibliothek aus dem Multimedia Ordner herausgeschmissen habe, bekomme ich wieder angezeigt welche Datei gerade indiziert wird.
Beziehungsweise nicht in die ziert sondern es werden die Miniaturbilder erzeugt.
Ich habe genau das gleiche Problem mit meiner TS-219P.
Bei mir hat nur der komplette Neuaufbau der Indexdatei(en) geholfen.
Generell läuft dieser komplette Vorgang sehr intransparent.
Teilweise ist es so, dass Fortschritt und die verbleibenden Dateien angezeigt werden, auf der anderen Seite so wie es gestern bei mir der Fall war hängt der Prozess ewig lang im Zustand Indizierung. Damit ist es nicht möglich den aktuellen Zustand dieses Vorgangs nachzuvollziehen.
Hier sollte die Benutzer Oberfläche noch über deutlich mehr Analysemöglichkeiten beziehungsweise Informationen verfügen.
Ich verwende die neueste Firmware 4.3.3.
Nur der Vollständigkeit halber ein "Update" dieses Threads:
Bei der Firmware 4.2.4 zB steht es in der Weboberfläche oben rechts im Untermenü der "drei vertikalen Punkte" unter "Über" ...
Zitat von "Eraser-EMC2-"Um auf die Daten der 2TB-Festplatte zugreifen zu können, muß man dann manuell Freigaben auf die vorhandenen Ordner erstellen.
Ich möchte die Ordner ja nur von der 2TB auf die 4TB zurück kopieren. Danach die 2TB wieder rausnehmen.
Das müsste ja dann doch auch über den internen Slot gehen?
Vielen Dank für die Antwort
Ist eigentlich logisch, allerdings nur dann, wenn die 2. Platte dann sofort "automatisch" in den "JOBD-Verbund" aufgenommen wird.
Eigentlich hätte ich eher erwartet, dass egal ob die Platte am eSATA-, oder am SATA-Port hängt, zunächst nur ein einfacher mount stattfindet, ohne dass die konfigurierten Freigaben "gemappt" werden.
Im Prinzip sind das ja nur Unterordner auf einem anderen, gemounteten Device mir natürlich unterschiedlichem absoluten Pfad.
Oder fehlen mir da "QNAP-OS" Kenntnisse? Meine Überlegungen müssten zumindest bei "normalem" Linux passen ...
Zitat von "GorillaBD"Genau so mache ich das immer...
Geht das eigentlich nicht auch im 2. freien Slot?
Also zuerst die 4TB neu Konfigurieren, dann die alte 2TB in den 2. Slot stecken und zurück kopieren?
Lässt das die QNAP-SW evtl. nicht zu?
Ich hab in meiner TS-219P eine 2TB HDD und würde diese gerne gegen eine 4TB austauschen (2. Slot ist frei).
Die Idee, die 2. Platte (4TB) zusätzlich rein zu stecken und auf RAID1 zu konfigurieren und hinterher die 2TB raus zu ziehen und auf JBOD "zurück zu konfigurieren" geht ja laut unzähligen Threads hier und im engl. Forum wohl leider nicht ...
Was haltet Ihr für die schnellste Art diesen Wechsel zu vollziehen?
4TB zus. rein und per ssh komplett kopieren (geht das überhaupt?)?
Oder die 4TB alleine rein und vom Backup der Konfiguration neu einrichten und die alte 2TB Platte an eSATA anstecken und per FileStation alles zurück kopieren?
Vielen Dank und Gruß ausm Keller!
OK, hat nun geklappt!
Aber ich musste unter Parallels den USB3-Port deaktivieren und unter "Hardware -> Netzwerk 1" den NIC-Typ auf Vitio-Netzwerkadaper und den Typ auf Ethernet x stellen, dann hats geklappt.
Den inetd hab ich dann auch gleich gesehen, aber der tftpd war nach dem Reset des TS-219P nur kurz zu sehen (max. ein paar 10 Sek.), dann war der Prozess wieder verschwunden. Durchgebootet wurde aber erst ein paar Minuten später.
BTW: ich spiele gerade mein Backup von der ext. eSATA-Platte zurück - gibts keine komfortablere Möglichkeit als mit der File Station Ordner für Ordner zu kopieren?
Ich hatte zum Glück noch ein älteres Backup der Daten und der Konfiguration, musste aber natürlich die int. Platte neu formatieren.
[EDIT]Das folgende Problem hab ich nun beheben können: die "fehlenden" Ordner hatten für die Admins keine Rechte eingetragen (das Backup war von 2011 und da hatte ich das wohl noch nicht mit drin).[/EDIT]
Mit ssh hab ich dann unter /share/HDA_DATA die Ordner meiner Freigaben wieder angelegt (mit mkdir). Aber teilweise erkennt die File Station die Ordner dann nicht, in der sonstigen Konfiguration (z.B. bei "Freigaben") werden sie aber gefunden. Auch dazu ne Idee?
Vielen Dank und Gruß ausm Keller!