DS415+ - BTRFS - SnapShot failed

[AndiHeitzer]

Mahlzeit in die Runde

Ich habe eine DS415+, darauf ein Volume mit EXT4 und ein weiteres kleines Volume mit BTRFS.
BTRFS nutze ich nur für Shared Folders, die mit häufigeren Bearbeitungen von Files betroffen sind.
Grund dazu ist eine gewisse Bequemlichkeit, um im Windows-Explorer schnell zu einer Vorgängerversion wechseln zu können, ohne über das DSM-Frontend mit dem HyperBackup arbeiten zu müssen.

Seit einiger Zeit treten sporadisch (ich kann das auch nicht provozieren) Benachrichtigungen und Mails bei mir auf, die einen fehlgeschlagenen Snapshot melden.



Mehr ist über das Webfrontend auch nicht zu erfahren. Auch nicht im zugehörigen Snapshotmanager oder der Protokollzentrale.

Also bin ich nach /var/log hinein und machte mich auf die Suche.
Lediglich in der /var/log/synolog/synodr.log finde ich folgende Zeilen/Hinweise:

info	2016/06/22 12:05:37	admin:	Took a shared folder snapshot [GMT-2016.06.22-10.05.04] from share [HOME_gabriele] by [scheduler].
err	2016/06/22 12:10:15	admin:	Failed to take a shared folder snapshot from share [HOME_andreas] by [scheduler]. (Operation failed)
info	2016/06/22 12:10:38	admin:	Took a shared folder snapshot [GMT-2016.06.22-10.10.03] from share [HOME_mediacenter] by [scheduler].

Das war's dann schon. Ist also nicht sehr befriedigend.
Ich habe keinerlei Datenverlust oder ähnliches, nur eben von einem der sechs Shares halt von einem einzigen Zeitpunkt dann keinen Snapshot.
Es sind alle sechs Shares betroffen, jedoch nie alle gleichzeitig. Manchmal gibt es auch Tage, da rennt das reibungslos.
Gibt es noch eine Idee, wo ich evtl. noch weitersuchen könnte?

Hier noch die Einstellung zur Aufbewahrung:

 

[dil88]

Danke für die Information! Hast Du dazu bei Synology ein Ticket aufgemacht? Wäre interessant, was sie dazu sagen.

 

[AndiHeitzer]

Ich möchte schon ein Ticket eröffnen.
Jedoch habe ich mir selber gegenüber den Anspruch, etwas mehr Informationen bereit zu stellen. Das mag aber durchaus meinem Job im 2ndL- & 3rdL-Datenbanksupport geschuldet sein.
Daher werde ich noch etwas mit Einstellungen "rumspielen" und damit gewonnene Erkenntnisse das Ticket füllen.

 

[AndiHeitzer]

Dann möchte ich mal weiter berichten.
Ich hatte die vier unter BTRFS (VOL3) eingerichteten Shares (500GB) zurückgeschoben auf meine EXT4-Volume (VOL1).

Im Anschluss habe ich diese vier Shares wieder auf die bestehende BTRF zurückgeschoben und die Snapshots wieder eingerichtet.
Alles war gut, keinerlei Fehlermeldungen

Heute war es wieder so weit, ich bekam den ersten Fehler, dass ein Share - Die DS415 nudelte hier im Leerlauf rum - wieder nicht gesnapt werden konnte.

Ich habe nun ein TT bei Synology eröffnet und warte nun mal ab, was angeboten wird.

 

[rednag]

Die aus dem Ticket gewonnenen Erkentnisse kannst Du hier zur Verfügung stellen. Das wird mit Sicherheit auch anderen Leuten helfen.
Ich selbst hatte die Meldung auch bereits 2x.

 

[AndiHeitzer]

+++ Synology Support Ticket: #856632 +++

Dear Andreas Heitzer,
Thank you for contacting Synology Support.
I have escalated this case to our developers for furtherinvestigation and I will inform you for any update. Apologies for yourinconvenience.
Thanks for your patience.
--
Sincerely,
David Fu


EDIT sagt:
Hatte das TT in Englisch eröffnet

 

[AndiHeitzer]

David Fu hat um Remote-Zugang gebeten ... mal sehen.

 

[AndiHeitzer]

Ich schrieb ja schon in #3, dass ich gerne mehr Infos zusammentragen würde, aber die Antwort vom Support hat mich dann schon zum Schmunzeln gebracht:

Thank you for the update.
We do suspect it's related to moving shared folder but it's verystrange no clues in /var/log/messages.

Das war es, was mich mit dem Ticket hat warten lassen ...
Das kann ja noch was werden

 

[jugi]

Kannst du definitiv ausschließen, dass es ein Problem mit den Clients ist? Ich denk da an gesperrte Office-Dokumente o.ä.…

 

[AndiHeitzer]

Ja, wie ich im Posting #4 schon erwähnte, gab es den Fehler, obwohl meine DS keinen Zugriff eines Clients hatte.
Vermutlich fühlte sie sich allein daheim etwas einsam und möchte ab und an gestreichelt werden?

 

[jugi]

Naja, der Begriff "Leerlauf" kann ne ganze Menge bedeuten - das war nicht eindeutig genug

Wäre natürlich nützlich, wenn man sich da irgendwie an den Fehler "dranhängen" könnte (Wenn die Meldung getriggert wird bitte einmal die Dateioptionen der betreffenden Datei raushauen o.ä.)

 

[AndiHeitzer]

Der Support-Mitarbeiter (Daniel Fu) und ich mussten nun warten, bis der Fehler wieder auftrat.
Er hat mir vor ein paar Tagen nur geschrieben dass er den Protokolldienst restartet habe und ich beim nächsten Vorfall die debug.dat zusenden möge.
Seine Anmeldung auf meiner DS lief etwa eine Stunde.

Heute Nacht war das soweit, zwei mal trat der Fehler auf ...

Die "/var/log/messages" hat nun den Vorfall etwas detaillierter ausgegeben:

Jul  9 02:25:17 DS415 synosharesnapshot: snapshot_create.c:300 Failed to add metadata for share [FREUNDE], snapshot [GMT-2016.07.09-00.25.04] [0x0400 file_lock_time_by_file.c:38]
Jul  9 02:25:19 DS415 synoretainer: share.c:48 Failed to list share(FREUNDE) snapshot [0x0400 file_lock_time_by_file.c:38]
Jul  9 02:25:19 DS415 synosharesnapshot: synosharesnapshot_sched.c:57 Failed to create snapshot for share [FREUNDE] with scheduler.[0x0400 snapshot_create.c:348]

Vorher war das nur ein schnöder "Einzeiler"

Mal sehen, wie das nun weiter geht, ich find's spannend.

 

[AndiHeitzer]

Mühsam nährt sich das Eichhörnchen.

Im Moment steht folgende Erkenntnis im Raum:
We found the the issue was caused by both HyperBackup andSnapshotReplication are running at the same timing which one of themfailed due to file lock error.
We would recommend to configure the scheduled task for bothHyperBackup and SnapshotReplication to different timeframes tomitigate the issue.
If to no avail, could you please help provide us remote access ofyour DS415+ again so we could try to enlarger the timeout to reducethe possibility of this issue.

Könnte sich nach einer "billigen" Lösung anhören, aber ich lasse da nicht locker.

Ich gab noch folgendes zum Nachdenken mit:
Some words from my side ...
In DSM5.x was a Backup-Service named "Time Backup". This Service ran in more Instances parallel.
In DSM6.x the "HyperBackup" runs only as one Instance and following Tasks are waiting for a Timeslot?!
What is the background for this single working Tasks?

My Background to use Snapshots:
In Time-Backup every User had access to his own versioned Backups, to recover Files on their own selection.
With HyperBackup this Option is not possible. So i configured Snapshots. Now the User can select Files as possible with Time-Backup from Windows Explorer.

Stay tuned

 

[dil88]

Danke für Deine Informationen und die Hartnäckigkeit. Einen lock-file-Konflikt sollte Synology eigentlich leicht lösen können.

 

[AndiHeitzer]

Und weiter geht es ...

Ich fragte, warum HyperBackup "nur" sequentiell arbeitet:
Due to backup task also include configuration backup, so we makesit as a single instance in case any configuration conflict amongdifferent instances of backup tasks running at the same time.
Simple speaking, to reduce the possibility of data andconfiguration inconsistency, we change the design to a single instanceto avoid such issue.

Ich musste nun meine Backupstrategie etwas anpassen.
Mit Hyperbackup werden die auf der BTRFS-Disk befindlichen Daten nur noch einmal täglich gesichert. Die feinere Versionierung obliegt nun ausschliesslich dem Snap-Mechanismus.
So ist sichergestellt, dass sich Hyperbackup und Snapmechanismus nicht in die Quere kommen.

Sollte es nun immer noch zu Unpässlichkeiten kommen, dann muss Synology wohl nochmal ran ...

Es bleibt spannend und interessant.

Und Loddar würde sagen: Again what learned