Ext. Laufwerk wird nicht automatisch ausgeworfen / Keine Erfolgsbenachrichtigung per E-Mail

    Hallo Zusammen,


    habe zwei kleine Probleme bei einem Kunden mit dem Sicherungsmanager. Vielleicht hat jemand von euch eine Idee.


    Hintergrundinfo:

    TS-431P mit QTS 4.3.4.0597 Build 20180528


    Auf dem NAS wird jede Nacht die Datensicherung vom Server (ESXi wird per VEEAM gesichert) abgelegt.


    Im Sicherungsmanager ist ein Sicherungsauftrag unter "Externer Datenträger" eingerichtet. Hier wird wöchentlich am Sonntag um 10 Uhr die Datensicherung vom Server nochmal auf ein externes USB Laufwerk kopiert. In den Jobeinstellungen ist eingestellt, dass das externe Laufwerk bei Abschluss des Auftrags automatisch ausgeworfen werden soll. In den Allgemeinen Optionen des Sicherungsmanagers ist konfiguriert, dass eine Benachrichtigungsmail verschickt werden soll, wenn eine Synchronisation abgeschlossen ist (also nicht nur im Fehlerfall).


    Nun besteht allerdings das Problem, dass:

    - Die ext. HDD nach Abschluss nicht ausgeworfen wird

    - Im Erfolgsfall keine Benachrichtigungsmail verschickt wird


    Hat jemand eine Idee woran das liegen kann? Ein SMTP Server zum Mailversand wurde korrekt konfiguriert. Testmails und auch E-Mails bei Fehlern/Warnungen gehen raus. Im Protokoll der Sicherung ist auch nichts auffälliges zu sehen. Der Status ist "Abgeschlossen".



    qnap1.PNGqnap2.PNGqnap3.PNG



    Was auffällt: Bei einem anderen Kunden (gleiche Konstellation, nur ein etwas älteres qnap) sieht schon alleine das Backup LOG ganz anders aus:




    Meine letzte Sichtkontrolle ergab aber, dass das NAS alle Daten korrekt kopiert hat, auch wenn das LOG einfach irgendwann "abbricht". Die Verzeichnisse waren identisch. Status steht ja auch auf "abgeschlossen" und es wurde auch keine Fehlermeldung angezeigt oder per E-Mail verschickt.


    Vllt. hatte ja schonmal jemand einen ähnlichen Fehler oder hat eine Idee woran das liegen könnte.



    Folgende "Maßnahmen" habe ich schon ergriffen:


    - NAS neugestartet

    - Firmware aktualisiert

    - Sicherung neu konfiguriert

    Auch mit der aktuellen Firmware von letzter Woche klappt es nicht.


    Habe zwischenzeitlich eine der beiden externen HDDs mal auf ext4 umformatiert. Nach wie vor das Problem, dass der Job einfach ohne Fehler abbricht und das Log mit dem Kopiervorgang.


    Jemand noch eine Idee woran das liegen könnte? Gibt es eine Möglichkeit den Sicherungsjob über die Konsole anzutriggern?

    Habe dasselbe Problem gerade noch bei einem anderen Kunden bemerkt. Beide haben ein TS-431P. Habe nun nochmal ein wenig an der Konfiguration geschraubt und die Option "Dateiinhalte prüfen" deaktiviert. Mal sehen ob es was bringt. Wenn nicht werde ich das ganze Wohl mal an den QNAP Support eskalieren.

    Das Problem mit dem automatischen Auswerfen habe ich schon in mehreren anderen Themen gelesen. Ob und was die Lösung war weiß ich leider nicht mehr. Vielleicht gibt die Suchfunktion des Forums was her.


    Das Problem mit nicht versendeten Benachrichtigungen kenne ich von einer QNAP von mir beim AntiViren-Scan. Leider habe ich hier keine Lösung gefunden. Eigentlich müsste es funktionieren und hat es auch Jahre lang aber nun... *Schulter zuck*.


    Aber dies hilft Dir auch nicht weiter. Deshalb zu möglichen Lösungsansätzen - Workarounds:

    - Zu Sicherung auf das externe Laufwerk: Wieso machst Du die Sicherung am Wochenende nicht als Kopie-Job mit Veeam? Mache ich zwar mit einem Tape-Laufwerk, müsste aber auch mit einer externen Festplatte funktionieren. Dann wird die Benachrichtigung über Veeam gemacht.

    - Das Auswerfen könnte mit einem Script funktionieren, welches nach dem Kopie-Job ausgeführt wird, z.B. mit unmount. Habe auf einer QNAP zwar nie ausprobiert, müsste aber sicher funktionieren.

    - Wenn Du für mehrere Kunden QNAPs betreust und Zugriff auf deren Systeme hast, würde sich für Dich Q'Center für die vereinfachte Verwaltung anbieten.

    Hey :)


    Danke für deine Anregungen.


    Bei den meisten Kunden mache ich die Kopie der Backups mit VEEAM auch über ein Tape Drive direkt über VEEAM. Leider gibt es immer noch Kunden denen eine "ordentliche" DaSi zu teuer ist. Das Tape Drive alleine ist ja schon nicht ganz günstig und VEEAM supportet Bandlaufwerke ja nicht in virtuellen Installationen. Daher die "günstigere" Lösung mit USB Festplatten und virtualisiertem Backup Server. Ich müsste mal sehen ob ich sicherstellen kann, dass eine externe HDD am ESXi Host immer automatisch an den Backupserver durchgeschleust wird. Wobei das wahrscheinlich immer ein potentielles Fehlerrisiko ist.


    Alternativ könnte ich die ext. HDD natürlich auch als zweite Netzwerkfreigabe am Backupserver mounten. Der Job würde dann bei durchschnittlich 2TB Backup-Repository und Gigabit Uplink etwa 12h laufen. Das wäre akzeptabel.


    Q'Center wäre sicher eine feine Lösung. Müsste ich mir mal näher ansehen wie das mit Datenschutz und Sicherheit aussieht.

    Zitat von L0gD4ta

    und VEEAM supportet Bandlaufwerke ja nicht in virtuellen Installationen.

    Doch, inzwischen schon. Seit welcher Version genau kann ich Dir auch nicht sagen, aber bei mir ist der Backup Server inzwischen auch eine VM.

    Zitat von L0gD4ta

    dass eine externe HDD am ESXi Host immer automatisch an den Backupserver durchgeschleust wird.

    Du meist vermutlich in Bezug auf das Auswerfen nach dem Backup und wieder anstecken vor dem Backup. Gute Frage. Zuweisung per ID?

    Zitat von L0gD4ta

    Q'Center wäre sicher eine feine Lösung.

    Verwalte so die QNAPs der Zentrale und der Filiale. Macht es um einiges einfacher, und wenn schon kostenlos dabei, wieso nicht. Dazu bekommt man Daten und Statistiken, die man anders nicht bekommt. Dafür muss man den Festplattenstandby opfern. Kann eben nicht alles haben. :)

    Zitat von Mavalok2

    Doch, inzwischen schon. Seit welcher Version genau kann ich Dir auch nicht sagen, aber bei mir ist der Backup Server inzwischen auch eine VM.

    oh. Gut zu wissen. So lange kann das noch nicht her sein. Habe letztes Jahr im April noch mit meinem Ansprechpartner bei VEEAM darüber diskutiert. Da wurde das noch nicht supported und war auch noch nicht klar ab wann sich das ändert.


    Zitat von Mavalok2

    Du meist vermutlich in Bezug auf das Auswerfen nach dem Backup und wieder anstecken vor dem Backup. Gute Frage. Zuweisung per ID?

    Ja genau. Lösung per ID finde ich nicht so geschickt aber ist vermutlich die einzige. Einige meiner Kunden kaufen gelegentlich auch mal neue ext. HDDs die sie dann "out of box" anstecken für die Datensicherung. Hat den hintergrund, dass einmal im Quartal oder Halbjahr (abhängig von der Größe der Einzelbackups) eine Kopie der Datensicherung archiviert wird. So wird die gesamte Backupchain archiviert. Das habe ich angefangen nachdem bei einem Kunden eine Datei vom Netzlaufwerk verloren gegangen ist, die nach dem Monatsbackup erstellt, aber vor dem nächsten Montagsbackup gelöscht wurde. Leider hatten wir zu dem Zeitpunkt nur die Monatsbackups im Archiv... Seitdem gibt es Kunden die jedes einzelne Backup archivieren wollen.


    Zitat von Mavalok2

    Verwalte so die QNAPs der Zentrale und der Filiale. Macht es um einiges einfacher, und wenn schon kostenlos dabei, wieso nicht. Dazu bekommt man Daten und Statistiken, die man anders nicht bekommt. Dafür muss man den Festplattenstandby opfern. Kann eben nicht alles haben. :)

    Werde ich mir mal anschauen :) Ist halt insofern bei mir ein nicht ganz einfaches Thema weil ich ja die Systeme verschiedener Kunden verwalte. Bin bei so sachen immer etwas vorsichtig.

    Wenn der Festplattenstandby dadurch flöten geht ist das natürlich nicht ganz optimal. Zumal die NASen in der Regel täglich nur 30 Minuten aktiv sind während dem Backup. 1x im Monat zum Active Full etwas länger.




    Achja: Hab das Thema mal an den QNAP Support weitergegeben. Das wird jetzt wieder 1-2 Wochen dauern bis es Rückmeldung gibt...

    Zitat von L0gD4ta

    So lange kann das noch nicht her sein.

    Bei mir im Einsatz so seit November 2017 - Veeam Backup and Replication Version 9.5. In diesem Fall vermutlich die erste Version die dies kann.

    Zitat von L0gD4ta

    So wird die gesamte Backupchain archiviert

    Also anstelle einem teureren Tape-Laufwerk und günstigen Bändern, lieber viele mittelteure USB-Festplatten. So Handgelenk mal Pi ist dann das Bandlaufwerk auch nicht mehr viel teurer. Aber was will man.

    Zitat von L0gD4ta

    Wenn der Festplattenstandby dadurch flöten geht ist das natürlich nicht ganz optimal.

    Stimmt. Aber wie so oft kann man nicht alles haben. Da bei mir die QNAPs mehrfach am Tag und in der Nacht aktiv sind, sehe ich es bei mir nicht so kritisch. Aber schlafende Festplatten lassen sich nun mal nicht überwachen. :)

    Zitat von Mavalok2

    Also anstelle einem teureren Tape-Laufwerk und günstigen Bändern, lieber viele mittelteure USB-Festplatten. So Handgelenk mal Pi ist dann das Bandlaufwerk auch nicht mehr viel teurer. Aber was will man.

    Erklär das mal den Kunden ;) Erlebe das viel zu oft, dass da immer nur auf kurze Sicht gedacht wird...

    Wobei das Tape Drive natürlich deutlich interessanter wird wenn VEEAM das jetzt auch in der VM Supported. Zuvor war es ja nicht nur das Laufwerk was angeschafft werden musste, sondern ein dedizierter Backupserver...

    Ist auch wieder wahr. Deshalb hatten wir bis letztes Jahr auch noch als einziges den Backup-Server als physischen Server. Jetzt ist alles virtualisiert, ok fast alles. Die QNAPs sind noch klassisch. :)

    Also das mit dem Backup Copy Job über VEEAM funktioniert. Das Repository kann ich ja auch als "Rotation Drive" konfigurieren, sodass VEEAM weiß, dass sich die Festplatte regelmäßig ändert.


    Allerdings wird hierbei aus dem Backup Repository zunächst mal ein Syntetisches Full Backup erstellt. Anschließend werden inkrementelle Backups erstellt. Beim wechsel der HDD wird wieder ein syntetisches Full Backup erstellt und dann inkrementelle. Die komplette Backup Chain lässt sich leider nicht damit kopieren.


    Evtl. muss ich es mal mit einem File Copy Job versuchen. So gefällt mir das zur Zeit noch nicht. Ggfs. muss ich die Backup Strategie auch nochmal komplett überdenken. Weil jede Woche erstmal ein Syntetisches Full zu schreiben bringt mich auch nicht vorwärts.

    Zitat von L0gD4ta

    Die komplette Backup Chain lässt sich leider nicht damit kopieren.

    Ist ja eigentlich nur das "Einfrieren" eines Standes. Was jedoch funktioniert sind mehrerer Stände auf dem Medium belassen, z.B. bei einer Wochensicherung die Stände eines Monats, sind aber immer Full-Backups. Somit wird der Platz natürlich ziemlich schnell knapp. Aber die komplette Chain habe ich nie versucht aufs Band zu kriegen. War für mich nie ein Thema. Bis jetzt bin ich immer davon ausgegangen, dass die Server und das primär Backup-Medium - eine QNAP - nicht gleichzeitig abrauchen und dann noch ein alter Stand benötigt wird. Das wäre dann reichlich Pech. In der Praxis hat sich bei mir herausgestellt, dass ich am meisten das primär Backup für ca. 2 bis 3 Wochen alte Dateien, die nicht mehr von der Schattenkopie abgedeckt werden, und die Bänder für ca. 4 bis 6 Monate alte Dateien benötige, die den User auf unerklärliche Weise abhanden gekommen sind. :rolleyes: :)

    In 99% der Fälle ist das auch ausreichend und deckt sich mit meinen Erfahrungen. Und in dem Fall ist die Backupstrategie auch verhältnismäßig einfach zu fahren und man kommt gut mit dem GFS Pool - in seiner eigentlichen Implementierung - zurecht.


    Leider ist es aber nun so, dass ich als Dienstleister damit betraut bin die individuellen Anforderungen der Kunden umzusetzen. In der Regel ist das das was sich der Geschäftsführer einfallen lässt. Und da ich eben schon den Fall hatte, dass eine Datei zwischen zwei Monatssicherungen erstellt und wieder gelöscht wurde, der Verlusst aber erst über 6 Monate später aufgefallen ist war mit den Monatssicherungen nicht mehr viel zu machen. Der Geschäftsführer des Kunden war höchst unerfreut (weil wichtige Daten). Seither will er daher die Backups jedes einzelnen Tages der letzten 3 Jahre aufbewahren.


    Diese Anforderung habe ich nun damit umgesetzt, dass alle 3 Monate die Gesamte Backupchain auf ein externes Medium kopiert wird und extern archiviert wird. Gleichzeitig wird im Wochenrythmus die Chain auf eine ext. HDD kopiert die dann außer Haus geschafft wird, zur Brandabsicherung (Brandabsicherung). Mit dem Backup Copy Job ist das so leider nicht umsetzbar.


    Allerdings auch eine sehr exotische Anforderung... In meinem Fall aber "Lebensrettend". Der Kunde ist König und will von Risiken nichts hören. Und wenn was schief geht, steht man als Dienstleister ziemlich schnell, ziemlich blöd da. Selbst wenn man den Kunden vorher über das potentielle Risiko aufgeklärt hat...

    Aha, das übliche also. Darf nix kosten bei max. Funktionsumfang. „Risiko? Brauch ich nicht.“

    3 Jahre jeden Tagesstand sichern. Wow. Das ist mal eine Ansage. Dann kann es sich aber nicht um große Datenbestände handeln.

    Ist das Medium eine USB Festplatte? Habe leider die Erfahrung gemacht, dass sich diese für längere Archivierung nicht eignen. Nach 3 Jahren Stand würde ich nicht damit rechnen, dass alles noch gelesen werden kann.

    Genau... das übliche.


    Bei dem Kunden, bei dem es zum Datenverlust kam, ist die Umgebung SEHR überschaubar. Zwei Win 2012 R2 Server mit DC, Fileserver, Exchange 2013 und 2-3 andere Anwendungen die über das Netzwerk gestartet werden. Die forward incremental Backup chain für 1 Monat liegt da bei ca 300 GB (mit höchster Kompression)...


    Seit dem kläre ich meine Kunden halt besser über die Möglichkeiten und Risiken einer gängigen Datensicherung auf. Und ein paar Kandidaten sagen dann, dass ihnen das Vorhalten einzelner Monatssicherungen zu "riskant" ist und daher die gesamte Backupchain archiviert werden soll. Über Sinn und Unsinn lässt sich ja bekanntlich streiten.


    Naja... Ich werd jetzt mal abwarten was mir der QNAP Support zurückschreibt. Allzugroße Hoffnungen das ursprüngliche Problem zu lösen mache ich mir jedoch nicht.

    Was wahrscheinlich helfen würde ist das NAS neu aufzusetzen. Ich nehme an, dass bei Dir genauso wie bei mir, irgendwo eine Konfig im argen liegt. Aber genau herauszufinden welche wo wie was...

    Gut Möglich. Ist halt bescheiden, dass das scheinbar öfter passiert. Genau genommen bei den letzten beiden NASen die ich in der Art in Betrieb genommen habe und auf denen fast nix läuft. 1 User für VEEAM, 1 Netzwerk Share und 1 Copyjob

    Wird der durchgeführte Job eigentlich im System-Protokoll aufgeführt?

    Ich nehme an, dass andere Mail-Benachrichtigungen funktionieren. Das Selbe in grün bei mir mit dem Virenscan-Job. :(

    Was ich bis jetzt noch nicht gemacht habe ist die Konfig-Datei (vom Job oder Programm) selbst zu prüfen (hatte bis jetzt keine Zeit und ist für mich nicht so dramatisch). Möglicherweise wird hier auch schon beim neu Erstellen des Jobs was falsch mitgegeben.

    Weißt du zufällig wo die config Dateien für die RTRR Jobs liegen? Habe die bisher leider nicht gefunden...



    Gibt Tage da kotzt mich mein Job echt an :D