Business Active Backup for Business Probleme mit Deduplizierung

[Gilbert_17]

Hallo zusammen,
ich nutze Active Backup for Business um 5 Windows 2016 Server zu sichern. Laut Active Backup for Business sollen die Backups ca. 3.6TB groß sein. Der @ActiveBackup Ordner ist auch so groß, allerdings habe ich noch einen Ordner ActiveBackupData dieser ist mittlerweile über 80TB groß.
Da der NAS nur ca. 48TB nutzbaren Speicher hat bekomme ich nun andauernd Fehlermeldung und auch die Snapshot Replication von VMM funktioniert nicht mehr, da der NAS ja voll ist.
Soll das so sein? Ich habe bis jetzt einen ähnliche Problematik nur im Zusammenhang mit der Beta von ActiveBackup gefunden jedoch ohne Lösungsansätze.
Ich hoffe ihr könnt mir helfen.

 

[Adama]

Wenn man den ActiveBackup-Share mittels HyperBackup sichern will, bekommt man beim Ordner ActiveBackupData folgende Anzeige:



Das sind also keine 80TB in dem Ordner. Die eigentlichen Sicherungsdaten liegen in @ActiveBackup.

Bei mir soll ActiveBackupData 2,8TB groß sein, diese Datenmenge taucht aber nicht im Gesamtverbrauch meiner Syno auf. Insofern würde ich vermuten, Dein Problem liegt nicht daran.

 

[Gilbert_17]

Grad in der Systemsteuerung nachgeschaut und dort wird die Größe auch korrekt angezeigt. Nur die Filestation zeigt das falsch an.
Nun hab ich aber das Problem ich habe 5 freigegebene Ordner. aufgerundet sind diese 3TB, 9TB, 3x 200GB. Also alles weit unter 48 TB. ActiveBackup wäre für mich die einzig nachvollziehbare Variante gewesen, da der NAS nach und nach immer weniger Speicherplatz frei hatte.
Jetzt habe ich dann keine Idee mehr warum der NAS voll sein soll. Ich probier mal ob ich über Konsole etwas finden kann.

 

[Adama]

Ich vermute, dass die Filestation "du" benutzt, um die Werte zu ermitteln. "du" arbeitet nicht gut mit btrfs zusammen. Einige der Besonderheiten kennt "du" halt nicht.

Was bekommst Du denn genau für eine Meldung? Vielleicht bringt uns das auf den richtigen Weg...

Ichhab' grad mal geschaut, was man in der messages findet: "cat /var/log/messages | grep Active"

Vielleicht gibt's auch da einen Hinweis.

 

[Gilbert_17]

Hab grad mal durchgeschaut und mal die doppelt Einträge für die Unterschiedlichen Backup Jobs entfernt.

2020-07-15T00:01:34+02:00 Backup synosharesnapshot: fs_btrfs_cmd.c:390 Failed to increase BTRFS snap-count over the path [/volume1/@sharesnap/ActiveBackupforBusiness/GMT-2020.07.14-22.00.03][0x0400 file_lock_time_by_file.c:38]
2020-07-15T00:51:14+02:00 Backup workflow: #0 (22730) /volume1/@appstore/ActiveBackup/bin/../lib/libsynoabk.so.1(synoabk::exception::Exception::_setBacktrace()+0x40) [0x7f957ef09ba0]
2020-07-15T00:51:14+02:00 Backup workflow: #1 (22730) /volume1/@appstore/ActiveBackup/bin/../lib/libsynodedup-engine.so.1(synoabk::exception::Exception::Exception<char const*>(char const*, char const*&&)+0x60) [0x7f957f4bf920]
2020-07-15T00:51:14+02:00 Backup workflow: #2 (22730) /volume1/@appstore/ActiveBackup/bin/../lib/libsynodedup-engine.so.1(void synoabk::exception::DedupEngine::throwErrnoError<int, char const (&) [14], int>(char const*, int&&, char const (&) [14], int&&)+0x201) [0x7f957f5e6a21]
2020-07-15T00:51:14+02:00 Backup workflow: #3 (22730) /volume1/@appstore/ActiveBackup/bin/../lib/libsynodedup-engine.so.1(DedupEngine::writeFd(int, char const*,unsigned long)+0xa7) [0x7f957f5e3767]
2020-07-15T00:51:14+02:00 Backup workflow: #4 (22730) /volume1/@appstore/ActiveBackup/bin/../lib/libsynodedup-engine.so.1(DedupEngine::copyFd(DedupEngine::ScopedFd const&, DedupEngine::ScopedFd const&, unsigned long)+0x8b) [0x7f957f5e1e7b]
2020-07-15T00:51:14+02:00 Backup workflow: #5 (22730) /volume1/@appstore/ActiveBackup/bin/../lib/libsynodedup-engine.so.1(+0x182124) [0x7f957f4d4124]
2020-07-15T00:51:14+02:00 Backup workflow: #6 (22730) /volume1/@appstore/ActiveBackup/bin/../lib/libsynodedup-engine.so.1(DedupEngine::renameWrite(std::string const&, int, std::function<void (DedupEngine::ScopedFd&)> const&)+0xda) [0x7f957f5e5a9a]
2020-07-15T00:51:14+02:00 Backup workflow: #7 (22730) /volume1/@appstore/ActiveBackup/bin/../lib/libsynodedup-engine.so.1(+0x1852e7) [0x7f957f4d72e7]
2020-07-15T00:51:14+02:00 Backup workflow: #8 (22730) /volume1/@appstore/ActiveBackup/bin/../lib/libsynodedup-engine.so.1(+0x18f114) [0x7f957f4e1114]
2020-07-15T00:51:14+02:00 Backup workflow: #9 (22730) /volume1/@appstore/ActiveBackup/bin/../lib/libsynodedup-engine.so.1(DedupEngine::unlinkAction(std::string const&, bool, bool)+0x2b7) [0x7f957f4e1fc7]
2020-07-15T00:51:14+02:00 Backup workflow: #10 (22730) /var/packages/ActiveBackup/target/bin/workflow() [0x402158]
2020-07-15T00:51:14+02:00 Backup workflow: #12 (22730) /var/packages/ActiveBackup/target/bin/workflow() [0x403566]
2020-07-15T08:33:26+02:00 Backup synodedup-fused: [ERROR] operator.cpp:49(24446, 140174693644032) Code: [2] What: [fuse/env.cpp:348(24446) path[/volume1/ActiveBackupforBusiness/@ActiveBackup/Server-xy/ActiveBackup_2020-04-18_220054], errno=[2/No such file or directory]]
2020-07-15T08:33:26+02:00 Backup synodedup-fused: #0 (24446) /volume1/@appstore/ActiveBackup/bin/../lib/libsynoabk.so.1(synoabk::exception::Exception::_setBacktrace()+0x40) [0x7f7d0a23aba0]
2020-07-15T08:33:26+02:00 Backup synodedup-fused: #1 (24446) /volume1/@appstore/ActiveBackup/bin/../lib/libsynoabk-daemon.so.1(synoabk::exception::Exception::Exception<char const*, int&>(int, char const*, char const*&&, int&)+0x73) [0x7f7d0a77b643]
2020-07-15T08:33:26+02:00 Backup synodedup-fused: #2 (24446) /volume1/@appstore/ActiveBackup/bin/../lib/libsynoabk-daemon.so.1(void synoabk::exception::throwErrnoError<char const (&) [13], int, int, char const*>(int, char const*, char const(&) [13], int&&, int&&, char const*&&)+0x2da) [0x7f7d0a81ebda]
2020-07-15T08:33:26+02:00 Backup synodedup-fused: #3 (24446) /volume1/@appstore/ActiveBackup/bin/../lib/libsynoabk-daemon.so.1(+0x19bcd2) [0x7f7d0a81ecd2]
2020-07-15T08:33:26+02:00 Backup synodedup-fused: #4 (24446) /volume1/@appstore/ActiveBackup/bin/../lib/libsynoabk-daemon.so.1(+0x1946dd) [0x7f7d0a8176dd]
2020-07-15T08:33:26+02:00 Backup synodedup-fused: #5 (24446) /volume1/@appstore/ActiveBackup/bin/../lib/libsynoabk-daemon.so.1(synoabk::Fuse::DirectoryTree::stat(std::string const&, stat&) const+0x2f1) [0x7f7d0a81b461]
2020-07-15T08:33:26+02:00 Backup synodedup-fused: #6 (24446) /volume1/@appstore/ActiveBackup/bin/../lib/libsynoabk-daemon.so.1(synoabk::Fuse::getattr(char const*, stat*)+0x52) [0x7f7d0a80e802]

 

[Adama]

Und wie ist die Meldung von ActiveBackup beim Backup-Versuch?

Zwei Zeilen fallen mir in Deinem Log auf:

2020-07-15T00:01:34+02:00 Backup synosharesnapshot: fs_btrfs_cmd.c:390 Failed to increase BTRFS snap-count over the path [/volume1/@sharesnap/ActiveBackupforBusiness/GMT-2020.07.14-22.00.03][0x0400 file_lock_time_by_file.c:38]

und:

2020-07-15T08:33:26+02:00 Backup synodedup-fused: [ERROR] operator.cpp:49(24446, 140174693644032) Code: [2] What: [fuse/env.cpp:348(24446) path[/volume1/ActiveBackupforBusiness/@ActiveBackup/Server-xy/ActiveBackup_2020-04-18_220054], errno=[2/No such file or directory]]

Ich hab' aber noch keine Idee, was uns das sagen könnte...

Was gibt "btrfs filesystem df /volume1/" aus?

 

[Gilbert_17]

Hier einmal der Output

Data, single: total=48.52TiB, used=48.50TiB
System, DUP: total=8.00MiB, used=992.00KiB
Metadata, DUP: total=1.19TiB, used=922.54GiB
GlobalReserve, single: total=2.00GiB, used=96.00KiB

Damit hab ich auch versucht mal den Übeltäter zu finden, aber für alle Unterverzeichnisse bekomme ich den exakt selben Output-

 

[Adama]

Das bezieht auch auf das gesamte BTRFS-Filesystem, nicht auf einzelne Unterverzeichnisse. Dafür müsstest Du "btrfs filesystem du" benutzen.

Mich stört ja irgendwie die zweite Meldung im Log mit dem fehlenden Ordner. Ich denke, da ist der Hund begraben. Damit ist vermutlich die Konsitenz des Backups beschädigt (Meine Vermutung).

Benutzt Du für alle Server eine Aufgabe?

Kannst Du eine neue Aufgabe anlegen? Erstmal nur für einen Server. Läuft die dann durch?

 

[Gilbert_17]

Da der NAS momentan häufiger abstürzt, versuche ich gerade erst einmal ein paar alt Daten auf eine extern Platte zu ziehen und werde das ganze dann testen.
Dabei ist mir allerdings noch aufgefallen, das Windows anzeigt, dass ca 31TB von 48TB belegt sind. Versucht man etwas auf den NAS zu kopieren wird angezeigt das nicht genug Speicher frei ist.
Sobald ich wieder etwas freien Speicher hab und das System dann auch hoffentlich stabiler läuft, werde ich die Backup aufgaben mal checken und bereichten.

 

[Adama]

Da scheint ja etwas Grundsätzliches nicht zu stimmen und ABB ist nur eines der Opfer.

Ich bin gespannt...

 

[Gilbert_17]

Bis jetzt gestaltet sich der ganze Prozess sehr schwierig, der NAS wird immer wieder voll und ist dann nicht mehr erreichbar. Ich habe soweit es geht alle Funktionen auf andere Server ausgelagert und bin nun dabei, leider sehr langsam, Daten zu verschieben um so etwas Platz zu schaffen in der Hoffnung, dass das System dann stabiler läuft.

Intressanter Weise ist unsere Remotesystem, auf welches der NAS gespiegelt wird auch mit 40TB befüllt obwohl die eigentliche Replikation nur 12TB groß ist und sich sonst keinerlei Daten auf dem Remotesystem befinden.

 

[NSFH]

In einem anderen Fall waren hier die Papierkörbe Schuld. Nimm die mal aus der Replikation etc raus.

 

[Gilbert_17]

Die Papierkörbe werde ich mal prüfen und aus der Replikation ausschließen.

Kleiner Zwischenstand: Ich hab es jetzt irgendwie geschafft 5TB frei zu bekommen. Active Backup läuft wieder problemlos, scheint also tatsächlich nicht der Auslöser zu sein. Zwischenzeitlich habe ich nur VMM deinstalliert, der als Replikationsziel für Snapshots diente und diese auch getestet hat.

 

[Gilbert_17]

Da ich das Problem allein leider nicht gelöst bekommen habe, durfte ich, nach viel Überzeugungsarbeit, dann doch den Synology Support über das System gucken lassen. Dieser hat den Fehler auch schnell gefunden. Das Problem lag an der Snapshot Replication, diese hat vom ABB Ordner fleißig Snapshots erstellt. Nun hab ich dies angepasst und alt lasten gelöscht und siehe da fast 35TB sind wieder frei.
Kann den Synology Support nur empfehlen.