1 2 Previous Next 17 Replies Latest reply on Sep 5, 2015 9:36 AM by andy232

    Desaster Recovery einer DSm 7 Umgebung

    erzwodezwo Expert
      Hallo,

      ich mach mir gerade mal gedanken wie eine "zerschossene" Umgebung zu retten ist bei der die Server die die DSM Komponeneten beinhalten nicht mehr funktional sind, was muss man mindestens alles haben um die Umgebung retten zu können.

      Also z.B ein aktuelles backuo der CMDB Datenbank vom SQL, ein aktuelles Backup vom Master Deport usw.

      Habt Ihr da Erfahrung?

      Gruß
      Torsten
        • 1. Re: Desaster Recovery einer DSm 7 Umgebung
          FrankScholer Master
          Hallo Torsten,

          guck mal unter http://support.frontrange.com/Support/TechnicalWhitePapers/Enteo.aspx - dort gibt's ein Whitepaper "Backup und Restore einer DSM Infrastruktur - Disaster Recovery". Das ist ja genau das, was du suchst, oder?

          HTH, Grüße Frank
          • 2. Re: Desaster Recovery einer DSm 7 Umgebung
            erzwodezwo Expert
            Haa das hab ich auch jetzt gefunden, nur würde mich trotzdem interessieren was Ihr zu Erfahrungen gemacht habt, denn zu meinem Primary BLS Umzug hab ich vom Support auch vorher gesagt bekommen sie hättenda normalerweise auf anhieb zu 100 % erfolg, nur ich hab mal wieder die Ausnahme und es geht nicht auf Anbieb und wie ich von euch erfahren musste ging es bei euch auch nicht immer auf Anhieb.....

            Gruß
            Torsten
            • 3. Re: Desaster Recovery einer DSm 7 Umgebung
              NicoS1 Master
              Hallo Torsten,

              wir waren mal bei einem Kunden in der Situation, dass wir ein Desaster Recovery machen mussten, bzw. damit beauftragt wurden. Bei ihm war es so: Datenbank und Windows liefen auf C:, Enteo Share auf D:

              Der Server hatte ein großes Raid-0, dass in 2 Partitionen aufgeteilt war, und eine Platte ging kaputt. (Nein der Server wurde nicht von uns aufgebaut oder betreut, so würde bei uns kein Server aussehen )

              - Alle Frontrange Dienste auf den Management Points stoppen.
              - Server wurde neu installiert (mit gleichem Namen)
              - Share neu eingerichtet
              - Share aus der letzten Sicherung recovered
              - Hier haben wir den Inhalt von Install\Master gelöscht, weil die Backup Software des Kunden Probleme mit den Links hatte.
              - SQL Datenbank zurückgesichert und wieder eingerichtet.
              - Konsole geöffnet und den primären Management Point rausgeschmissen und über die Konsole neu installiert.

              -> Master Server lief wieder.
              -> Install Verzeichnis wurde vom Distributionsdienst wieder hergestellt.
              -> Die neue NCP haben wir von Hand auf alle Depots und in die %ProgramFiles%
              etinst Verzeichnisse kopiert.
              -> Die Frontrange Dienste auf den Depots wurden wieder gestartet.

              Für die Clients haben wir zur Sicherheit für 2 Wochen 2 GPOs eingerichtet, eine die das löschen des DSMDB Caches beim herunterfahren forciert, und eines, welches die aktuelle / neue NCP auf die Clients verteilt.

              Die Umgebung lief wieder einwandfrei und machte keine weiteren Probleme. Sie hat auch einige Updates zwischenzeitlich Erfahren, die Problemlos durch liefen.
              • 4. Re: Desaster Recovery einer DSm 7 Umgebung
                erzwodezwo Expert
                Hallo,

                damit ein Restore richtig funktionieren kann muss die Datenbank, das Depot(s) und der/die BLS zur selben Zeit gesichert werden.

                Ansonsten würde ja die Datenbank älter sein als bzw. das Depot oder der BLS.

                Stimmt das so?

                Was passiert wenn das Depot älter ist als die Datenbank, dann wurden z.B Pakete ausgerollt laut Datenbank wovon dass Depot usw. nichts weiß, bzw. macht es dem Depot und dem BLS überhaupt etwas aus?

                Gruß
                Torsten
                • 5. Re: Desaster Recovery einer DSm 7 Umgebung
                  _Mel_ Master
                  wenn depot und db nicht den gleichen stand haben, dann hast du halt inkonsistenzen. die können mehr oder weniger schlimm sein.
                  ...ich würde das nach möglichkeit vermeiden wollen, denn selbst wenn man die in einfachen fällen noch korrigieren kann, muß man erstmal die betroffenen pakete identifizieren.
                  wenn es sich nicht vermeiden läßt die beiden zu verschiedenen zeitpunkten zu sichern, würde ich wahrscheinlich zuerst die db sichern (d.h. nach dem wiederherstellen, wäre das depto aktueller als die db)
                  • 6. Re: Desaster Recovery einer DSm 7 Umgebung
                    erzwodezwo Expert
                    Ok, ich dachte mir schon dass es das beste ist alles zur selben Zeit zu sichern,
                    mch jetzt mal tests indem ich die Server auf denen DSM läuft auf verschiedene Backup Server verteil und dann zur selben Zeit starten lasse, dann werd ich das ganze mal in einer testumgebung herstellen und schauen ob es passt....

                    Gruß
                    Torsten
                    • 7. Re: Desaster Recovery einer DSm 7 Umgebung
                      JonasB Apprentice
                      Hallo NicoS,

                      wir haben diese Woche unsere DSM7 Infrastruktur auch wiederherstellen müssen, nachdem das Update auf die 2013.2 fehlgeschlagen war.

                      Im Prinzip hat der Restore gut funktioniert und auch das 2013.2 ist mittlerweile installiert, jedoch haben wir jetzt einige Clients, die zwar die neue Clientversion erhalten haben, nun aber nicht mehr mit dem BLS synchronisieren. Wenn ich über die DSMC per "Problembehandlung" den DSMDB Cache lösche, dann synchronisieren die Clients wieder.

                      Du hast geschrieben, dass ihr das Löschen des Caches per GPO initiiert, in der DSM7 Hilfe habe ich keinen Befehl gefunden. Wie hast du das gemacht?

                      Grüße
                      • 8. Re: Desaster Recovery einer DSm 7 Umgebung
                        NicoS1 Master
                        Hallo Jonas,

                        im Prinzip ganz einfach

                        Ich habe eine kleine Batch Datei geschrieben:

                        rd "%ProgramFiles%\Common Files\enteo\cmdbcache" /S /Q

                        Und diese via GPO lokal auf die Clients kopiert und in den COMPUTER Settings der GPO als Script beim Herunterfahren angegeben. Wichtig ist, dass es im Computerteil gemacht wird damit das Script im System Kontext läuft und nicht im Computerkontext. Und beim Herunterfahren deshalb, weil den Cache hart zu löschen während des Betriebs würde erfordern, dass die Dienste neu gestartet werden, und das kann der normale Benutzer ja nicht. Sollte möglichst alles ohne weiteres Eingreifen funktionieren

                        Diese GPO nutzen wir bei einigen wenigen Kandidaten die aufgrund diverser Verhaltensmuster öfters einen defekten Cache haben

                        Das Ganze lässt sich auch einfach als "einmalige Aktion" durchführen, in dem du am Ende des Batch Files irgendwo hin eine Textdatei erstellst und am Anfang des Batch prüfst ob die Textdatei da ist. Wenn ja => Exit, wenn nein => Cache löschen.

                        P.S.: für 64 Bit müssten eventuell die Pfade noch etwas angepasst werden. Aber ansonsten im Prinzip das gleiche.

                        Gruß
                        • 9. Re: Desaster Recovery einer DSm 7 Umgebung
                          _Mel_ Master
                          macht ihr das
                          - um die verwaltungsinformationen für den repositorycache zu löschen ?
                          - oder damit der computer nicht mehr weiß wer er ist ?

                          denn sonst speichert ein client da eigentlich nix

                          auf einem management point würdest du außerdem noch ausstehende jobs killen und auf einem osdproxy die info welche clients nichts zu tun haben (für den kann man einen cache refresh übrigens auch aus der dsmc oder per powertoyz antriggern)
                          • 10. Re: Desaster Recovery einer DSm 7 Umgebung
                            JonasB Apprentice
                            Hallo Nico,

                            danke für die Info. Habe das nun allerdings mal von Hand getestet. Wenn ich den Inhalt vom Ordner "CMDBCache" lösche und die Dienste durchstarte, dann hab ich trotzdem keine synchronisation in der DSMC...
                            sobald ich es aber per "Problembehandlung" über die DSMC mache, dann funktioniert ist.
                            Weiß jemand, was da anders läuft?
                            • 11. Re: Desaster Recovery einer DSm 7 Umgebung
                              ChristophSteckelberg Expert
                              Hallo

                              setze im 32bit Zweig der Registry den Wert CacheReset=1 unter HKLM\Software\NetSupport\NetInstall\CMDBCache  als DWORD und starte den CoreService durch

                              Viele Grüße,
                              Christoph
                              • 12. Re: Desaster Recovery einer DSm 7 Umgebung
                                JonasB Apprentice
                                Hallo Christoph,

                                danke für den Tipp, das wäre eine gute Möglichkeit die Änderung vom Client aus anzustoßen. Leider bleibt mein Problem, dass die Synchronisation nicht funktioniert.
                                • 13. Re: Desaster Recovery einer DSm 7 Umgebung
                                  _Mel_ Master
                                  was steht in den logfiles auf client (performsync, syncresponse) und bls (blsclientwebservice)?
                                  • 14. Re: Desaster Recovery einer DSm 7 Umgebung
                                    JonasB Apprentice
                                    syncresponse:

                                    13:54.10.520  2 syncserv.dll      "Exception":{
                                    13:54.10.520  2 syncserv.dll        "ErrorId":-536608564,
                                    13:54.10.520  2 syncserv.dll        "Message":"LastCommitted SyncCountClient is ahead compared to the one stored in the database (5755 vs 5715), probably a database backup was restored or there is a significant replication backlog. When the database was restored you must change the CmdbGuid to trigger a refresh of the client caches.",
                                    13:54.10.521  2 syncserv.dll        "StackTrace":"   at Enteo.BlServer.Core.ClientManagement.CoreCommands.CheckAndUpdateSynchronizationInfoCommand.CheckAndUpdateSyncCounters(SynchronizationData syncData, IVirtualObject computer)\r
                                       at Enteo.BlServer.Core.ClientManagement.CoreCommands.CheckAndUpdateSynchronizationInfoCommand.Execute(SynchronizationData syncData)\r
                                       at Enteo.BlServer.Base.ClientManagement.CommandInfrastructure.SynchronizationInvoker.ExecuteSingleCommand(ISynchronizationCommand command, SynchronizationData data)\r
                                       at Enteo.BlServer.Base.ClientManagement.CommandInfrastructure.InvokerBase`2.Execute(TData data)\r
                                       at Enteo.BlServer.Orchestration.ClientManagement.ClientManagementOrchestration.<>c__DisplayClass1e.b__1c(IMdsFactory mdsFactory)\r
                                       at Enteo.BlServer.Orchestration.OrchestrationBase.HandleRequestInternal[TReply](String callName, TransactionHandling transactionHandling, ExecuteRequestDelegate`1 exec, Func`1 getClientInfo, Func`1 getRequestServerInfo, Func`2 getReplyServerInfo, OrchestrationCallWr



                                    Er erkennt richtig, dass die DB restored wurde.
                                    Auf dem BLS im log sagt steht zu der passenden Computer ID genau das gleiche.

                                    Nur wie ich es massentauglich beheben kann, weiß ich nicht :/
                                    1 2 Previous Next