Rücksicherung nach Servertotalschaden

Alle Themen rund um die Rücksicherung der Daten.
Antworten
Kosinus
Beiträge: 5
Registriert: 30.06.2014, 15:47

Rücksicherung nach Servertotalschaden

Beitrag von Kosinus » 30.06.2014, 16:14

Hallo Forum,

ich versuche nun schon seit einige Zeit, eine Rücksicherung meiner Backup-Daten durchzuführen, was mir einfach nicht gelingen will. Ich denke, ich habe schon so einige Zeilen gelesen und auch versucht, leider bisher ohne Erfolg.
Da ich bisher ausschliesslich in Windows-Welten unterwegs gewesen und nun auf Lnux umgestiegen bin, tue ich mir gerade doppelt schwer.

Zu meinem Problem: Im Zuge einer Neuinstallation habe ich mich für den UCS (Univention Corporate Server) entschieden. Da lag es nahe, auch die im App-Center angebotene SESAM Backup-Software zu probieren. Diese war dank der Doku schnell eingerichtet und lief soweit problemlos. Die Daten und Konfiguration des Servers wurden jede Nacht auf eine sep. Festplatte gesichert.

Bis ich durch eine große Dummheit meinerseits den Server komplett zerschossen habe :oops: . Nun gut, blöd gelaufen, aber Du hast ja eine Datensicherung, dachte ich mir. Nur muss ich gerade feststellen, dass die Rücksicherung scheinbar nicht so einfach ist, wie ich mir gedacht habe.

Mein Problem ist, die vorhandenen Sicherungen wieder in die Datenbank zu bekommen, damit ich hiervon dann wieder eine Rücksicherung einleiten kann. Was ich habe sind die eintzelnen Backup-Dateien (".data" und ".info" am Ende) und die ".sds" Datei, welche sich auf der sep. Festplatte befinden.

Wie bekomme ich hieraus wieder meine Daten? Ich habe auch schon versucht, mittels der SEP Live-CD an die Daten ran zu kommen, nur bekomme ich die Sicherungssätze nicht wie beschrieben eingelesen. Evtl. mache ich auch einen Fehler bei dem Einbinden der Festplatte? Wie gesagt, Linux-Neuling!

Kann mir jemand bitte ein wenig auf die Sprünge helfen? Ich benötige keine kompl. Resauration des Servers. Nur der Zugriff auf meine Daten wäre schon schön.


Gruß,
M. Kriegsch

cliogp
Beiträge: 75
Registriert: 18.01.2006, 18:51
Wohnort: Waakirchen
Kontaktdaten:

Re: Rücksicherung nach Servertotalschaden

Beitrag von cliogp » 01.07.2014, 07:52

Hallo,

ich gehe davon aus, das die Sesam Eigensicherung ( SESAM_BACKUP ) gemacht wurde. Wenn die Desaster Schnittstelle eingerichtet war, sollten Sie nach jedem Eigenbackup eine E-Mail mit der Recover Anleitung bekommen haben.

1) Sesam Server neu installieren
2) Festplatte mit Sicherungen wieder einbinden
3) im Verzeichnis des DataStores die *.info Dateien durchsuchen, welche das SESAM_BACKUP betreffen ( "grep SESAM_BACKUP /pfad zu Dateien/*info" )
4) in de Ausgabe sind dann irgendwelche *info Dateien zu sehen, der Dateiname enthält auch das Datum
5) zu jeder *info Datei gibt es im gleichen Verzeichnis eine *data Datei
6) jüngste / letzte Sesam Eigensicherung raussuchen
7) Sesam Dienste beenden ( "/opt/sesam/bin/sesam/sm_main stop" )
8) Befehl "/opt/sesam/bin/sesam/sbc -r -l full -o over -s @/pfad zu data Datei/*.data -R /" schreibt die komplette Sesam Eigensicherung an den originalen Pfad
9) Sesam Dienste starten ( "/opt/sesam/bin/sesam/sm_main start" )

Dann ist der Sesam wieder in dem Zustand, wie er zum Zeitpunkt der Sicherung war. Dann bitte die Sesam Desaster Schnittstelle einrichten, für die Zukunt.

Clio

Kosinus
Beiträge: 5
Registriert: 30.06.2014, 15:47

Re: Rücksicherung nach Servertotalschaden

Beitrag von Kosinus » 02.07.2014, 15:26

Hallo,

vielen Dank für die Antwort! Nach meinen bisherigen Recherchen hätte ich nicht gedacht, dass es so einfach sein könnte.

Ich versuche es und werde berichten.

mfg

Kosinus
Beiträge: 5
Registriert: 30.06.2014, 15:47

Re: Rücksicherung nach Servertotalschaden

Beitrag von Kosinus » 04.07.2014, 14:21

Hallo!

Ok, mit dem Befehl konnte ich zumindest meine Daten in einem anderen Pfad wieder herstellen <hapüüh>. Vielen Dank!

Aktuell scheiter ich allerdings noch daran, Sesam selbst wieder herzustellen. Scheinbar hat mir die Neuinstallation des UCS eine neuere SESAM-Version installiert, als ich zuvor installiert gehabt habe. Zumindest meine ich dies an dem Inhalt der sm.ini-Dateien zu erkennen.

Das konkrete Problem ist: Wenn ich sesam so wie geantwortet wieder herstelle, die Dienste zwar starten, rmi aber kurz darauf wieder "offline" anzeigt und ich mich mit der GUI nicht verbinden kann. Ein sm_main start rmi hilft hier auch nicht weiter.

Im Übrigen habe ich in der Sicherung die von der Desaster-Schnittstelle erzeugte Bootstrap-Datei gefunden. Diese habe ich lt. Beschreibung in der FAQ bzw. im Forum importiert. Hier hatte ich zum. den Teilerfolg, dass ich meine bisherige Konfiugation einsehen konnte. Die Savesets waren aber nicht vorhanden, wodurch auch kein Restore-Job über die GUI möglich ist. Konkrete Frage hierzu: Ich habe beobachtet, dass nach dem Wiederherstellen über die Bootstrap-Datei sesam angefangen hat, das Medienverzeichnis zu purgen (Retention war/ist auf 7 Tage eingestellt, evtl. auch suboptimal; Gott sei Dank habe ich eine Sicherung der Sicherung). Wie kann ich den Purge-Prozeß sofort unterbinden?

VG,
MKr

cliogp
Beiträge: 75
Registriert: 18.01.2006, 18:51
Wohnort: Waakirchen
Kontaktdaten:

Re: Rücksicherung nach Servertotalschaden

Beitrag von cliogp » 07.07.2014, 09:23

Hallo,

wenn Sie mittels der bootstrap Datei und dem wieder eingebundenen DataStore die Rücksicherung des SESAM_BACKUP durchgeführt haben und auch der Haken "desaster restore" im Restore Wizard gesetzt wurde, sollte die Datenbank Versions Differenz "behoben" werden.

Wichtig ist auch, das der Server den gleichen Namen und IP Adresse hat, per DNS oder hosts auflösbar ist. mit "sm_main status" könne Sie nachsehen, welche Dienste nach dem Start wieder offline sind. Danach könne Sie versuchen in /var/opt/sesam/var/log/lgc in den Logdateien nachzusehen, was beim Dienststart schief geht. Die Logs haben im Wesentlichen den Namen des Dienstes mit im Dateinamen, günstig ist, sich das lgc Verzeichnis mit "ls -latr" auflisten zu lassen, dann stehen die jüngsten Dateien ganz unten und man kann die zuletzt genutzten Dateien gut erkennen.

Wenn es wirklich nur die Version ist, können Sie versuchen das Problem mit "sm_db_update update -o 4.2.1.41 -n 4.2.2.40" (o=alte Version, n=installierte Version) zu beheben.

Der Purge des DataStore läßt sich ,generell gesehen, nicht "abschalten". Es wird ja davon ausgegangen, das der Sesam zeitnah nach dem Crash wiederhergestellt wird und damit die ganz normalen Retention Zeiten keine negativen Auswirkungen haben. Als "workaround" kann man (bevor der sesam startet) dem Server das DataStore Verzeichnis entziehen, den Sesam starten und in den Eigenschaften des DataStore auf dem Reiter "Savesets" die EOL der Savesets auf ein Datum in der Zukunft setzen.

Clio

Kosinus
Beiträge: 5
Registriert: 30.06.2014, 15:47

Re: Rücksicherung nach Servertotalschaden

Beitrag von Kosinus » 07.07.2014, 23:17

Hallo,

vielen Dank für die Antworten. Ich komme aber irgendwie nicht weiter.

Ich habe nun dank des UCS-Forums herausgefunden, wie ich die ältere SESAM-Version wieder installiert bekomme. Aber egal wie ich es anstelle: Ich bekomme den RMI-Dienst nicht gestartet :(

In der sm_gui_server.lgc wird protokolliert:
2014-07-08 00:00:56 [main] INFO root - Server logging uses NewdayRollingFileAppender
2014-07-08 00:00:56 [main] INFO root - Logging to /var/opt/sesam/var/log/lgc/sm_gui_server.lgc started.
2014-07-08 00:00:56 [main] INFO root - Overwrite locale from resources to 'en'.
2014-07-08 00:00:56 [main] INFO root - Sesam GUI-Server V4.2 Build 1 A 1.16541 2012-10-24 11:10:52
2014-07-08 00:00:56 [main] INFO root - (C) SEP AG, Weyarn, Germany
2014-07-08 00:00:56 [main] INFO root - java.version 1.6.0_31
2014-07-08 00:00:56 [main] INFO root - java.runtime OpenJDK Runtime Environment (build 1.6.0_31-b31)
2014-07-08 00:00:56 [main] INFO root - java.vm OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
2014-07-08 00:00:56 [main] INFO root - java.vendor Vendor: Sun Microsystems Inc.
2014-07-08 00:00:56 [main] INFO root - java.os OS: Linux (amd64, mixed mode)
2014-07-08 00:00:56 [main] INFO root - Get default charset: UTF-8
2014-07-08 00:00:56 [main] INFO root - Local system file encoding: UTF-8
2014-07-08 00:00:56 [main] INFO root - User root, initial verbose level is null.
2014-07-08 00:00:56 [main] INFO root - RMI working in CAJO mode, using port 11401.
2014-07-08 00:00:56 [main] INFO root - RmiJdbcServer will start, using port 11401.
2014-07-08 00:00:56 [main] INFO root - Get encoding from sm.ini = 'UTF-8'
2014-07-08 00:00:56 [main] INFO root - Resulting encoding: UTF-8
2014-07-08 00:00:56 [main] INFO root - setSecurityManager
2014-07-08 00:00:56 [main] INFO root - bindItemServer serverHost=0.0.0.0 serverPort=11401 clientHost=ucs.kosinus.local clientPort=11401
Versuche ich über sm_rmi_main den Dienst zu starten, erhalte ich folgendes:
root@ucs:/# sm_rmi_main
2014-07-08 00:00:56.419 [main] INFO - setup the server logger...
2014-07-08 00:00:56.421 [main] INFO - set initial verbose level to 'INFO'
2014-07-08 00:00:56.421 [main] INFO - logging to console started.
2014-07-08 00:00:56.424 [main] INFO - Set verbose level from debug.ini to '2' (INFO)
2014-07-08 00:00:56.424 [main] INFO - Parsing argument list...
2014-07-08 00:00:56.455 [main] INFO - Server logging uses NewdayRollingFileAppender
2014-07-08 00:00:56.457 [main] INFO - Logging to /var/opt/sesam/var/log/lgc/sm_gui_server.lgc started.
2014-07-08 00:00:56.458 [main] INFO - Overwrite locale from resources to 'en'.
2014-07-08 00:00:56.464 [main] INFO - Sesam GUI-Server V4.2 Build 1 A 1.16541 2012-10-24 11:10:52
2014-07-08 00:00:56.465 [main] INFO - (C) SEP AG, Weyarn, Germany
2014-07-08 00:00:56.465 [main] INFO - java.version 1.6.0_31
2014-07-08 00:00:56.465 [main] INFO - java.runtime OpenJDK Runtime Environment (build 1.6.0_31-b31)
2014-07-08 00:00:56.466 [main] INFO - java.vm OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
2014-07-08 00:00:56.466 [main] INFO - java.vendor Vendor: Sun Microsystems Inc.
2014-07-08 00:00:56.467 [main] INFO - java.os OS: Linux (amd64, mixed mode)
2014-07-08 00:00:56.467 [main] INFO - Get default charset: UTF-8
2014-07-08 00:00:56.467 [main] INFO - Local system file encoding: UTF-8
2014-07-08 00:00:56.468 [main] INFO - User root, initial verbose level is null.
2014-07-08 00:00:56.468 [main] INFO - RMI working in CAJO mode, using port 11401.
2014-07-08 00:00:56.468 [main] INFO - RmiJdbcServer will start, using port 11401.
2014-07-08 00:00:56.469 [main] INFO - Get encoding from sm.ini = 'UTF-8'
2014-07-08 00:00:56.469 [main] INFO - Resulting encoding: UTF-8
2014-07-08 00:00:56.470 [main] INFO - setSecurityManager
2014-07-08 00:00:56.492 [main] INFO - bindItemServer serverHost=0.0.0.0 serverPort=11401 clientHost=ucs.kosinus.local clientPort=11401
Exception in thread "main" java.security.AccessControlException: access denied (java.net.SocketPermission localhost:11401 listen,resolve)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:399)
at java.security.AccessController.checkPermission(AccessController.java:557)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkListen(SecurityManager.java:1134)
at java.net.ServerSocket.bind(ServerSocket.java:335)
at java.net.ServerSocket.<init>(ServerSocket.java:202)
at gnu.cajo.invoke.Remote$RSSF.createServerSocket(Unknown Source)
at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:667)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:317)
at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:236)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:207)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:122)
at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:98)
at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:239)
at gnu.cajo.utils.ItemServer.bind(Unknown Source)
at de.sep.sesam.gui.server.GUIServer.bindItem(GUIServer.java:648)
at de.sep.sesam.gui.server.GUIServer.bindItemServer(GUIServer.java:611)
at de.sep.sesam.gui.server.GUIServer.bindCajoRmiServices(GUIServer.java:576)
at de.sep.sesam.gui.server.GUIServer.main(GUIServer.java:346)

STATUS=0 MSG=I000-BASICS Could not start RMI server: Please try to start 'sm_rmi_main' manually0
Es wird hier ein "access denied" ausgegeben. Aber wo wäre dies zu beheben?

VG,
Kosinus

cliogp
Beiträge: 75
Registriert: 18.01.2006, 18:51
Wohnort: Waakirchen
Kontaktdaten:

Re: Rücksicherung nach Servertotalschaden

Beitrag von cliogp » 09.07.2014, 13:32

Hallo,

ist in der /var/opt/sesam/var/ini/sm_java.policy im Abschnitt //NET die Zeile

permission java.net.SocketPermission "*:11401", "connect,accept,resolve,listen";

drin ?

Clio

Kosinus
Beiträge: 5
Registriert: 30.06.2014, 15:47

[gelöst] Re: Rücksicherung nach Servertotalschaden

Beitrag von Kosinus » 26.08.2014, 13:04

Hallo,

mit dem zus. Eintrag "listen" hat es dann wieder funktioniert :-)

Den Purge-Prozess konnte ich dann auch unterbinden, indem ich in dem wiederhergestellten DataStore zeitnah den jew. Task mit "Locked on" markiert habe. Die Desaster-Schnittstelle ist nun auch eingerichtet und funktional.

Vielen Dank für die Unterstützung.

VG,
MKr

cliogp
Beiträge: 75
Registriert: 18.01.2006, 18:51
Wohnort: Waakirchen
Kontaktdaten:

Re: Rücksicherung nach Servertotalschaden

Beitrag von cliogp » 26.08.2014, 16:29

Hallo,

danke für das Feedback.

Clio

Antworten