Groene LED's blijven knipperen en er is veel schijfactiviteit (DS415+)

[Birdy]

Hij is bezig met "herstellen". Momenteel blijft het fenomeen zich nog voordoen

Dat is logisch, NU "busy as a beaver".

[Robert Koopman]

Bekijk tijdens deze herstel fase maar eens naar je schijven, zie je zo 200-300Mb/s aan lees/schrijf snelheden.
SHR herstellen vergt nogal wat geschuif met data.

[Tim__]

Er is inderdaad sinds ik deze morgen een nieuwe hd heb gestoken meer activiteit op diskniveau. Maar bij iSCSI is er sindsdien nog niets veranderd. Is dat normaal?

[Birdy]

Maar bij iSCSI is er sindsdien nog niets veranderd.

Ik zie geen plaatje daarvan maar, het is volume/iSCSI en aangezien er op volume nivo ook veel activiteit m.b.t. herstellen, dan is dat wel normaal. 
Eerst maar "even" wachten tot het herstellen gereed is en dan pas kijken het er voor staat.

[Tim__]

Ondertussen is het 'herstellen' voltooid maar de Synology blijft dezelfde problemen vertonen. Ook na reboot.
https://dl.dropboxusercontent.com/u/26089/IMG_2227.MOV


Ga nu een schijfcontrole doen...

[Pippin]

Heb je de mogelijkheid de schijven in een PC te testen?
Ik heb ergens eens gelezen dat dat verschillende resultaten op kan leveren.
Dus dat DSM iets anders laat zien dan de WD tool.

Op het synology.com forum word dit probleem ook door gebruikers gemeld echter ook daar vind men geen oplossing.
http://forum.synology.com/enu/viewtopic.php?f=19&t=83280

[Tim__]

Ja doe heb ik. Straks eens proberen. Bedankt voor de tip!

[Tim__]

Wat is nu tegenkom is dat de Synology 'volloopt'. Er is al 1TB aan gegevens bijgekomen zonder dat ik gegevens op de Synology plaats 


De smart check is nog steeds bezig... evenals de backup na meer dan 2 dagen (66% backup op 48u).

[Hofstede]

Welke backup is dat? Je beseft toch wel dat het tegelijkertijd laten uitvoeren van de check en de backup zorgt dat alles heel langzaam verloopt? Die twee processen zitten elkaar continu in de weg. Het zou slimmer/sneller zijn om eerst de check af te laten lopen en dan pas de backup te doen.

[Tim__]

Een backup via "backup en replicatie". Je hebt gelijk maar dat kan toch de aanzet/reden niet zijn dat er plots 1TB aan gegevens wordt ingenomen?

[Hofstede]

Nee, het was meer bedoeld als opmerking.
Wat betreft de gebruikte ruimte denk ik eerder aan CloudStation. Heb je die aanstaan?

[Tim__]

Jazeker die draait al meer dan een jaar en een half zonder enig probleem :-)

[Tim__]

Hmm, ik heb al één van de schuldigen gevonden denk ik. Via ssh ben ik ingelogd in de Synology en zie dat de map /volume1/@img_bkp_repo 1,5TB groot is. Om het ENG forum vind ik dit weer: http://forum.synology.com/enu/viewtopic.php?t=82095


Dat doet mij vermoeden dat sinds het gepruts met de SQL database van PhotoStation het verkeerd is gegaan:
http://www.synology-forum.nl/photo-station-blog/albumrechten-in-photostation-verloren-na-terugzetten-backup/





Synology> du -d 1 -h 796.0K   ./bin
104.0K   ./dev
6.0M   ./etc
4.0K   ./initrd
130.7M   ./lib
5.2M   ./lib64
4.0K   ./mnt
2.9M   ./tmp
16.0K   ./.system_info
0   ./proc
32.0K   ./.old_patch_info
4.0K   ./lost+found
1.9M   ./root
17.6M   ./.syno
36.0K   ./volumeUSB1
36.0K   ./run
5.2M   ./sbin
0   ./sys
4.0K   ./volumeUSB2
318.7M   ./usr
39.8M   ./var
3.3T   ./volume1
5.6M   ./etc.defaults
156.0K   ./var.defaults
3.3T   .












Synology> cd /volume1/
Synology> du -d 1 -h
16.0K   ./lost+found
153.3M   ./@tmp
12.0K   ./@spool
444.4M   ./@database
367.8M   ./@appstore
248.2G   ./music
32.0K   ./Gedeelde_agenda
4.0K   ./@download
354.9M   ./web
481.0G   ./photo
366.0G   ./video
6.7G   ./surveillance
16.0K   ./@MailScanner
4.0K   ./@clamav
8.0K   ./@maillog
4.0K   ./@quarantine
592.3M   ./@eaDir
628.0K   ./Anthony-Wim
40.0K   ./ftp
168.0K   ./Gedeelde map
434.4G   ./homes
148.0K   ./owncloud
8.0K   ./public
258.3G   ./Time Machine
10.7G   ./@cloudstation
4.0K   ./@autoupdate
1.5T   ./@img_bkp_repo
3.3T   .




Synology> cd ./@img_bkp_repo/
Synology> ls
Config              Pool                repo_ver.json       repository_info.db  target_info.db
Synology> ls -la
drwxr-xr-x    4 root     root          4096 Nov  2 11:55 .
drwxr-xr-x   29 root     root          4096 Nov  2 11:32 ..
drwxr-xr-x    3 root     root          4096 Nov  1 11:42 Config
drwxr-xr-x    3 root     root          4096 Nov  1 11:42 Pool
-rw-r--r--    1 root     root            36 Nov  1 11:41 repo_ver.json
-rw-r--r--    1 root     root          3072 Nov  1 11:41 repository_info.db
-rw-r--r--    1 root     root          3072 Nov  2 11:55 target_info.db
Synology> du -d 1 -h
1.5T   ./Pool
8.3G   ./Config
1.5T   .




Synology> cd Pool/
Synology> ls -la
drwxr-xr-x    3 root     root          4096 Nov  1 11:42 .
drwxr-xr-x    4 root     root          4096 Nov  2 11:55 ..
drwxr-xr-x    3 root     root          4096 Nov  2 11:55 1
Synology> cd 1/
Synology> ls -la
drwxr-xr-x    3 root     root          4096 Nov  2 11:55 .
drwxr-xr-x    3 root     root          4096 Nov  1 11:42 ..
drwxr-xr-x   18 root     root          4096 Nov  4 16:56 0
-rw-r--r--    1 root     root          2048 Nov  1 11:42 avai_bucket.db
-rwx------    1 admin    users            8 Nov  4 20:37 bucketID.counter
-rwx------    1 admin    users            8 Nov  1 11:42 bucketID.counter_dup
-rwx------    1 root     root     2959225856 Nov  4 20:37 chunk_index
-rwx------    1 admin    users           64 Nov  2 11:33 chunk_index_dup
-rw-r--r--    1 root     root          2048 Nov  1 11:42 del_list.db
Synology> du -d 1 -h
1.5T   ./0
1.5T   .
Synology> cd 0
Synology> du -d 1 -h
100.2G   ./0
100.3G   ./1
100.4G   ./2
100.2G   ./3
100.2G   ./4
100.2G   ./5
100.2G   ./6
100.2G   ./7
100.2G   ./8
100.2G   ./9
100.2G   ./10
100.2G   ./11
100.2G   ./12
100.2G   ./13
100.2G   ./14
63.2G   ./15
1.5T   .

[Tim__]

Omdat een antwoord van synology maar niet kwam heb ik een clean install gedaan en daarna de data manueel overgezet. Ik heb ook alle instellingen opnieuw manueel ingesteld en de gebruikers manueel toegevoegd. Na het indexeren en converteren loopt de Synology nu goed.

Deze topic kan dus gesloten worden.

[Birdy]

Dank je TIM voor je update, have fun