91
Defekte SQL-Datenbank reparieren
Hallo,
wir nutzen einen Microsoft SQL-Server 14.0.2052.1.
Dort gibt es 2 aktive Datenbanken.
Nachdem ich eine der beiden Datenbanken manuall sichern wollte, bevor ich ein Update für die entsprechende Software installiere, brach die Sicherung immer wieder bei 70% ab.
Wir haben einen IT-Dienstleister, dem aber bis dahin auch noch nicht aufgefallen war, dass auch die tägliche Sicherung dieser Datenbank über eine Backup-Software schon seit längerer Zeit nicht mehr funktioniert hatte. OK... das ist jedoch jetzt nicht das Hauptthema
Jedenfalls wurden schon sämtliche Methoden ausprobiert, die offensichtlich defekte SQL-Datenbank zu reparieren.
Bisher leider ohne Erfolg.
Auch das Klonen des entspr. virtuellen Servers (auf dem die DB liegt) funktioniert nicht und bricht ab... offenbar ebenfalls aufgrund der defekten Datenbank.
Unser IT-Dienstleister hat nun schon den Microsoft-Support zur Hilfe genommen und mit deren Hilfe verschiedene Reparaturversuche für die SQL-Datenbank durchgeführt.
Wenn ich dann mal wieder eine Email erhalte mit "versuchen Sie jetzt nochmal, die entspr. Datenbank zu sichern", geht es bisher immer so aus, dass diese Sicherung bei 70% abbricht. Das war auch gestern wieder so.
Offenbar sind unser IT-Dienstleister... aber wohl auch der Microsoft-Support... derzeit mit ihrem Latein am Ende.
Daher dachte ich, dass ich diesen Thread mal hier reinstelle, in der Hoffnung, dass vielleicht jemand von Euch noch eine Idee hat, was man machen könnte.
Das Problem ist, dass die letzte Sicherung, die funktioniert hat, von Anfang 2024 ist... und das könnte u.U. katastrophal sein.
Grüße von
Yan
wir nutzen einen Microsoft SQL-Server 14.0.2052.1.
Dort gibt es 2 aktive Datenbanken.
Nachdem ich eine der beiden Datenbanken manuall sichern wollte, bevor ich ein Update für die entsprechende Software installiere, brach die Sicherung immer wieder bei 70% ab.
Wir haben einen IT-Dienstleister, dem aber bis dahin auch noch nicht aufgefallen war, dass auch die tägliche Sicherung dieser Datenbank über eine Backup-Software schon seit längerer Zeit nicht mehr funktioniert hatte. OK... das ist jedoch jetzt nicht das Hauptthema
Jedenfalls wurden schon sämtliche Methoden ausprobiert, die offensichtlich defekte SQL-Datenbank zu reparieren.
Bisher leider ohne Erfolg.
Auch das Klonen des entspr. virtuellen Servers (auf dem die DB liegt) funktioniert nicht und bricht ab... offenbar ebenfalls aufgrund der defekten Datenbank.
Unser IT-Dienstleister hat nun schon den Microsoft-Support zur Hilfe genommen und mit deren Hilfe verschiedene Reparaturversuche für die SQL-Datenbank durchgeführt.
Wenn ich dann mal wieder eine Email erhalte mit "versuchen Sie jetzt nochmal, die entspr. Datenbank zu sichern", geht es bisher immer so aus, dass diese Sicherung bei 70% abbricht. Das war auch gestern wieder so.
Offenbar sind unser IT-Dienstleister... aber wohl auch der Microsoft-Support... derzeit mit ihrem Latein am Ende.
Daher dachte ich, dass ich diesen Thread mal hier reinstelle, in der Hoffnung, dass vielleicht jemand von Euch noch eine Idee hat, was man machen könnte.
Das Problem ist, dass die letzte Sicherung, die funktioniert hat, von Anfang 2024 ist... und das könnte u.U. katastrophal sein.
Grüße von
Yan
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 82382636888
Url: https://administrator.de/contentid/82382636888
Ausgedruckt am: 24.11.2024 um 03:11 Uhr
91 Kommentare
Neuester Kommentar
Kannst du denn auf die Datenbank noch zugreifen? Also zumindest auf bestimmte Inhalte? Du sagst nur das Backup geht nicht und die VM lässt sich nicht Klonen (online?), was eigentlich gar nicht sein kann. Eine defekte Datei kann ich ja auch immer kopieren, macht sie nur nicht heile. Sollte aber natürlich unbedingt VORHER passierten, um nicht am lebenden Patienten zu operieren.
Hallo, was ist mit der Software die die nutzt?
Wie Komplext ist die DB? Hersteller der Software noch verfügbar?
Du kannst auch alles via T-SQL in eine neue DB kopieren. Ist aber nur der Inhalt. Trigger, Views etc. vorhanden? Tabellen Rationen bekannt?
Wenn die Relationen einfach nachzuvollziehen sind und einige Tabellen sogar für sich allein stehen können, dann könnte es mit T-SQL eine Option sein.
Wobei man auch Views, Trigger exportieren und nachbauen kann.
SQL Server ist für Entwickler kostenlos. Man könnte die DB mal in eine gleiche SQL Standard Version hängen oder in eine neuere SQL Version.
Wird wirklich beim Backup abgebrochen oder sind das verbundene Task für Index Neuaufbau u.ä.?
MS zu fragen ist so eine Sache. Was läuft auf der DB? Im Zweifel kann der Author der SQL Snippets bzw. Software, die die DB nutzt, mehr sagen!
Je nach Umfang kann man auch Backup durch einfaches Kopieren von A nach B erzielen. Dazu muss man die DB kennen! Besonders wie gesagt Trigger, Views und Stored Procedures.
Erst dann kann man sagen wie groß der Schaden ist und was genau betroffen ist.
Es gibt auch Authoren die Temp Tabellen anlegen. Oder Tabellen, deren Inhalt diurch Prozeduren oder Programme von Extern wieder gefüllt werden kann.
Hängt von so vielen Dingen ab.
Wichtig ist ggf. dann erstmal mit den Programmieren zu sprechen. Oder erstmal zu klären, was da überhaupt drauf läuft!
Wie Komplext ist die DB? Hersteller der Software noch verfügbar?
Du kannst auch alles via T-SQL in eine neue DB kopieren. Ist aber nur der Inhalt. Trigger, Views etc. vorhanden? Tabellen Rationen bekannt?
Wenn die Relationen einfach nachzuvollziehen sind und einige Tabellen sogar für sich allein stehen können, dann könnte es mit T-SQL eine Option sein.
Wobei man auch Views, Trigger exportieren und nachbauen kann.
SQL Server ist für Entwickler kostenlos. Man könnte die DB mal in eine gleiche SQL Standard Version hängen oder in eine neuere SQL Version.
Wird wirklich beim Backup abgebrochen oder sind das verbundene Task für Index Neuaufbau u.ä.?
MS zu fragen ist so eine Sache. Was läuft auf der DB? Im Zweifel kann der Author der SQL Snippets bzw. Software, die die DB nutzt, mehr sagen!
Je nach Umfang kann man auch Backup durch einfaches Kopieren von A nach B erzielen. Dazu muss man die DB kennen! Besonders wie gesagt Trigger, Views und Stored Procedures.
Erst dann kann man sagen wie groß der Schaden ist und was genau betroffen ist.
Es gibt auch Authoren die Temp Tabellen anlegen. Oder Tabellen, deren Inhalt diurch Prozeduren oder Programme von Extern wieder gefüllt werden kann.
Hängt von so vielen Dingen ab.
Wichtig ist ggf. dann erstmal mit den Programmieren zu sprechen. Oder erstmal zu klären, was da überhaupt drauf läuft!
Backup....
wie genau macht ihr das Backup, per software oder per SQL Server Task oder hast schon mal manuellen dump gemacht?
Per SQL Command:
Datenbankname anpassen und pfad nach belieben.
Und die entscheidenede Frage was für einen Fehler wirft der Server den, Eventlog, SQL Server Log oder sonst wo muss ja im Detail was stehen was sein problem ist.
Das herausfinden und hier posten oder googeln.
und ne andere Frage - läuft die Datenbank so wie sie ist aktuell noch?
dann wie sind die settings z.b. fürs datenbank fiule und log file der datenbank.
eventuell ist das log file begrenzt von der grösse und kann nicht auf die grösse anschwellen was es eigentlich braucht.
wie genau macht ihr das Backup, per software oder per SQL Server Task oder hast schon mal manuellen dump gemacht?
Per SQL Command:
BACKUP DATABASE datenbankname TO DISK='c:\datenbank.bak' Datenbankname anpassen und pfad nach belieben.
Und die entscheidenede Frage was für einen Fehler wirft der Server den, Eventlog, SQL Server Log oder sonst wo muss ja im Detail was stehen was sein problem ist.
Das herausfinden und hier posten oder googeln.
und ne andere Frage - läuft die Datenbank so wie sie ist aktuell noch?
dann wie sind die settings z.b. fürs datenbank fiule und log file der datenbank.
eventuell ist das log file begrenzt von der grösse und kann nicht auf die grösse anschwellen was es eigentlich braucht.
Sollte noch Zugriff auf die DB bestehen, würde ich ein gleichwertiges System aufbauen und dann anfangen, jede Db, Tabelle, Trigger und Functions einzeln von der alten auf die neue DB zu synchronisieren. Tools wie Navicat for SQL Server können das auch automatisiert. Erstens kann man damit den defekten Teil recht einfach finden und zweites weiß man dann, welche Daten verloren sind und welche nicht.
Das hört sich eher nach einem Defekt der gesamten VM an, als ein Fehler der Datenbank. Das Klonen sollte unabhängig von der DB funktionieren.
Gruß
max
Auch das Klonen des entspr. virtuellen Servers (auf dem die DB liegt) funktioniert nicht und bricht ab.
Das hört sich eher nach einem Defekt der gesamten VM an, als ein Fehler der Datenbank. Das Klonen sollte unabhängig von der DB funktionieren.
Gruß
max
1
Erstmal posten ob auf die DB noch zugegriffen werden kann und ob z.B. der Datenbank-Dienst schon mal angehalten und neu gestartet wurde. Wenn das mit Sicherheit geht, kann man den Dienst anhalten und die mdb und ldf weg sichern und mit dem Klon spielen.
Wenn du nicht weißt, ob die Datenbank wieder startet, aktuell aber Zugriff möglich ist, dann würde ich alles händisch klonen, meist sind diese Datenbanken nicht so wahnsinnig komplex. Oder mal mit dem Hersteller der Software brain stormen.
Wenn du nicht weißt, ob die Datenbank wieder startet, aktuell aber Zugriff möglich ist, dann würde ich alles händisch klonen, meist sind diese Datenbanken nicht so wahnsinnig komplex. Oder mal mit dem Hersteller der Software brain stormen.
Puuuuuuuuh, da hab ich ja was losgetreten
Seid mir nicht böse, aber die meisten Fragen (vor allem die sehr spezifischen von @Crusher79) kann ich selbst überhaupt nicht beantworten. Aber ich versuche mal, all die zu beantworten, die ich kann...
Es gibt ja 2 Datenbanken auf diesem SQL-Server.
Man kann mit beiden Programmen arbeiten und es gibt dort auch keine Probleme.
Eine der beiden Datenbanken kann ich auch manuell sichern. Das funktioniert einwandfrei. Das mache ich direkt über das "MS SQL Server Management Studio".
Warum das Klonen dieses virt. Servers nicht funktioniert, kann ich so nicht sagen. Hat mich aber auch gewundert. Hier bekomme ich halt nur die Infos per Email od. Telefon durch unseren IT-Dienstleister.
Der Hersteller der Software, dessen DB nicht gesichert werden kann, war schon in das Procedere eingebunden. Auch die konnten wohl bisher nicht helfen.
Solche Dinge, wie z.B. "via T-SQL in eine neue DB kopieren..." etc. könnte ich selbst nicht durchführen, da ich mich mit SQL-Servern od. -Datenbanken so gut wie nicht auskenne.
Ich werde gleich den Vorschlag von @ThePinky777 mal testen. Also das
...natürlich mit den passenden Einträgen.
Hier mal die übliche Fehlermeldung, die bei der Sicherung der DB auftritt:
Mein eher persönliches Problem:
Vielleicht könnt Ihr verstehen, dass mein pers. Problem im Moment natürlich ist, dass wir ja einen IT-Dienstleister haben, den wir natürlich auch bezahlen (Wartungs-/Servicevertrag).
Da wir aber nicht weiterkommen, war mir heute Morgen eingefallen, einfach mal hier im Forum nachzufragen.
Da ich die meisten Fragen ja nun nicht beantworten kann, müsste ich diese ja eigentlich an den IT-Dienstleister weitergeben... Das ist ja irgendwie auch ein bisschen peinlich (für den, aber für mich auch ein bisschen).
Wie seht Ihr das und wie würdet Ihr da jetzt vorgehen?
Grüße von
Yan
Seid mir nicht böse, aber die meisten Fragen (vor allem die sehr spezifischen von @Crusher79) kann ich selbst überhaupt nicht beantworten. Aber ich versuche mal, all die zu beantworten, die ich kann...
Es gibt ja 2 Datenbanken auf diesem SQL-Server.
Man kann mit beiden Programmen arbeiten und es gibt dort auch keine Probleme.
Eine der beiden Datenbanken kann ich auch manuell sichern. Das funktioniert einwandfrei. Das mache ich direkt über das "MS SQL Server Management Studio".
Warum das Klonen dieses virt. Servers nicht funktioniert, kann ich so nicht sagen. Hat mich aber auch gewundert. Hier bekomme ich halt nur die Infos per Email od. Telefon durch unseren IT-Dienstleister.
Der Hersteller der Software, dessen DB nicht gesichert werden kann, war schon in das Procedere eingebunden. Auch die konnten wohl bisher nicht helfen.
Solche Dinge, wie z.B. "via T-SQL in eine neue DB kopieren..." etc. könnte ich selbst nicht durchführen, da ich mich mit SQL-Servern od. -Datenbanken so gut wie nicht auskenne.
Ich werde gleich den Vorschlag von @ThePinky777 mal testen. Also das
BACKUP DATABASE datenbankname TO DISK='c:\datenbank.bak' ...natürlich mit den passenden Einträgen.
Hier mal die übliche Fehlermeldung, die bei der Sicherung der DB auftritt:
Mein eher persönliches Problem:
Vielleicht könnt Ihr verstehen, dass mein pers. Problem im Moment natürlich ist, dass wir ja einen IT-Dienstleister haben, den wir natürlich auch bezahlen (Wartungs-/Servicevertrag).
Da wir aber nicht weiterkommen, war mir heute Morgen eingefallen, einfach mal hier im Forum nachzufragen.
Da ich die meisten Fragen ja nun nicht beantworten kann, müsste ich diese ja eigentlich an den IT-Dienstleister weitergeben... Das ist ja irgendwie auch ein bisschen peinlich (für den, aber für mich auch ein bisschen).
Wie seht Ihr das und wie würdet Ihr da jetzt vorgehen?
Grüße von
Yan
Zitat von @Yan2021:
Mein eher persönliches Problem:
Vielleicht könnt Ihr verstehen, dass mein pers. Problem im Moment natürlich ist, dass wir ja einen IT-Dienstleister haben, den wir natürlich auch bezahlen (Wartungs-/Servicevertrag).
Da wir aber nicht weiterkommen, war mir heute Morgen eingefallen, einfach mal hier im Forum nachzufragen.
Da ich die meisten Fragen ja nun nicht beantworten kann, müsste ich diese ja eigentlich an den IT-Dienstleister weitergeben... Das ist ja irgendwie auch ein bisschen peinlich (für den, aber für mich auch ein bisschen).
Wie seht Ihr das und wie würdet Ihr da jetzt vorgehen?
Grüße von
Yan
Mein eher persönliches Problem:
Vielleicht könnt Ihr verstehen, dass mein pers. Problem im Moment natürlich ist, dass wir ja einen IT-Dienstleister haben, den wir natürlich auch bezahlen (Wartungs-/Servicevertrag).
Da wir aber nicht weiterkommen, war mir heute Morgen eingefallen, einfach mal hier im Forum nachzufragen.
Da ich die meisten Fragen ja nun nicht beantworten kann, müsste ich diese ja eigentlich an den IT-Dienstleister weitergeben... Das ist ja irgendwie auch ein bisschen peinlich (für den, aber für mich auch ein bisschen).
Wie seht Ihr das und wie würdet Ihr da jetzt vorgehen?
Grüße von
Yan
Moin,
ich sehe es eigentlich ganz unkritisch. Ja klar man bezahlt einen IT Dienstleister damit dieser einen unterstützt. Aber auch das sind am Ende nur Menschen, die sich nicht mit allen Problemen auskennen.
Jedoch sollte man sich als Dienstleister schon irgendwo wissen wie man sich weiterhilft durch andere Personen etc.
Denke mal du solltest deinem Dienstleister die Fragen zukommen lassen. Kann dieser als eine Art Weiterbildung sehen ;)
Letzten Endes soll das Problem gelöst werden und wie ist nicht so entscheidend. Meiner ist auch nicht allwissend, jedoch arbeiten wir dann zusammen an einer Lösung und weiter gehts...
Gruß,
DGI
Hier das Ergebnis der Abfrage über SQL-Command:
Ist ebenso gescheitert. Könnte in diesem Fall aber auch daran liegen, dass MA gerade im Programm arbeiten.
Grüße von
Yan
Ist ebenso gescheitert. Könnte in diesem Fall aber auch daran liegen, dass MA gerade im Programm arbeiten.
Grüße von
Yan
Wie seht Ihr das und wie würdet Ihr da jetzt vorgehen?
Wurde der Server schon mal erfolgreich neu gestartet in der Zeit, wo die DB den CRC Fehler gemacht hat?
Wenn ja: Anwender aus der Anwendung raus, Datenbank-Dienst anhalten, mdf + ldf Datei kopieren, Server neu starten, Zugriff testen.
(Wenn nein bitte nicht weiter machen ohne vorher das Risiko zu bewerten!)
Wenn das klappt kannst du mit den kopierten Dateien testen. Dazu eine VM mit SQL Express (ruhig auch die neueste Version) aufsetzen und die Kopie der mdf im SQL Management Studio dort "anhängen". Dann als erstes mal testen ob sich die Datenbank dort sichern lässt.
...jetzt sind alle MA aus dem Programm ausgestiegen.
Aber die Fehlermeldung bleibt die Gleiche. Hat also nicht funktioniert.
Grüße von
Yan
Aber die Fehlermeldung bleibt die Gleiche. Hat also nicht funktioniert.
Grüße von
Yan
Ja, der Server wurde durch den IT-Dienstleister schon neugestartet. Das war so ziemlich das Erste, was getan wurde.
DB-Dienst anhalten und die mdf + ldf Datei kopieren wurde ganz am Anfang schon gemacht, soweit ich mich erinnere (die Problemsuche läuft schon seit Wochen...).
Ich kann das aber nochmal testen. Wie halte ich den DB-Dienst an?
Und wie kopiere ich die beiden Dateien dann?
Grüße von,
Yan
DB-Dienst anhalten und die mdf + ldf Datei kopieren wurde ganz am Anfang schon gemacht, soweit ich mich erinnere (die Problemsuche läuft schon seit Wochen...).
Ich kann das aber nochmal testen. Wie halte ich den DB-Dienst an?
Und wie kopiere ich die beiden Dateien dann?
Grüße von,
Yan
Hallo
Da die Datenbank sonst noch normal funktioniert und der CRC Fehler nur beim Backup auftritt tippe ich auf defekte Sektoren auf der Platte in einem sonst ungenutzten Datenbereich.
Ich würde so wie oben schon mehrfach erwähnt schnellstens die Tabellen, Trigger, Views, Stored Procedures, usw. manuell in eine neue DB übernehmen.
Denn ich vermute, dass das Problem noch größer werden wird wenn es sich wirklich um defekte Sektoren handelt.
Tom
Da die Datenbank sonst noch normal funktioniert und der CRC Fehler nur beim Backup auftritt tippe ich auf defekte Sektoren auf der Platte in einem sonst ungenutzten Datenbereich.
Ich würde so wie oben schon mehrfach erwähnt schnellstens die Tabellen, Trigger, Views, Stored Procedures, usw. manuell in eine neue DB übernehmen.
Denn ich vermute, dass das Problem noch größer werden wird wenn es sich wirklich um defekte Sektoren handelt.
Tom
2
...ich nehme an, dass mit "DB-Dienst anhalten" entspr. Dienste gemeint sind, die beendet werden müssen.
Welche denn von denen hier?
Grüße von
Yan
Welche denn von denen hier?
Grüße von
Yan
Einfach alle SQL Dienste. Theoretisch reicht auch die (MSSQLSERVER) Instanz oder SFIRM, je nachdem, was kaputt ist.
Die kopierte mdf/ldf in einem ansonsten neu installierten Server einhängen sollte gehen. Wenn die Datei dann wirklich noch eine Macke hat, müsste ja auch hier das Backup scheitern. Wenn das Backup gehen sollte dann könnte man sich das mit Tabellen und Triggern sparen.
Die kopierte mdf/ldf in einem ansonsten neu installierten Server einhängen sollte gehen. Wenn die Datei dann wirklich noch eine Macke hat, müsste ja auch hier das Backup scheitern. Wenn das Backup gehen sollte dann könnte man sich das mit Tabellen und Triggern sparen.
OK und danke.
Wenn ich die SQL Server-Instanz (ich vermute der im obigen Screenshot markierte Eintrag) anhalte, dann ist ja auch die zweite DB nicht mehr nutzbar... richtig?
Dann müsste ich die entspr. Kollegen dann auch zuvor bitten, aus dem entspr. Programm auszusteigen.
Und... wie genau kopiere ich dann die mdf + ldf Datei?
Geht das in SQL über "Tasks >> Datenbank kopieren"?
Grüße von
Yan
Wenn ich die SQL Server-Instanz (ich vermute der im obigen Screenshot markierte Eintrag) anhalte, dann ist ja auch die zweite DB nicht mehr nutzbar... richtig?
Dann müsste ich die entspr. Kollegen dann auch zuvor bitten, aus dem entspr. Programm auszusteigen.
Und... wie genau kopiere ich dann die mdf + ldf Datei?
Geht das in SQL über "Tasks >> Datenbank kopieren"?
Grüße von
Yan
Instanz hält alles an was darunter läuft.
MDF und LDF kann man normal wie DOC oder andere Dateien kopieren und auf neuen System einhängen.
Ohne laufende Instanz sind SQL Werkzeuge still gelegt. Explorer.
MDF und LDF kann man normal wie DOC oder andere Dateien kopieren und auf neuen System einhängen.
Ohne laufende Instanz sind SQL Werkzeuge still gelegt. Explorer.
Die andere Instanz müsste weiter laufen. Aber schaden wird es nicht, muss ja nicht sofort gemacht werden. mdf und lfd liegen auf dem Dateisystem, wo kannst du vorher im Management Studio nachgucken.
Wenn man die umebennnen kann, ist die Instanz unten.
Um sie mit den "kaputten" Server oder auch später wieder zu verwenden, muss man den Namen zurück ändern.
Sonst muss man den explzit beim verbinden in den erweiterten Eigeschaft ggf. korrigieren.
Munter ein "x" davor geschrieben und nix hält die DB momentan fest....
Um sie mit den "kaputten" Server oder auch später wieder zu verwenden, muss man den Namen zurück ändern.
Sonst muss man den explzit beim verbinden in den erweiterten Eigeschaft ggf. korrigieren.
Munter ein "x" davor geschrieben und nix hält die DB momentan fest....
Hmmm... habe es jetzt versucht.
Die im obigen Screenshot markierte Instanz (wenn es denn die Instanz ist) angehalten.
Die darunter sind somit wohl autom. angehalten.
Dann habe ich den Speicherplatz der mdf-Datei ermittelt.
Dann wollte ich die mdf-Datei kopieren, aber erhalte dann die folgende Fehlermeldung, die ich überhaupt nicht verstehe:
Das MS SQL-Management Studio ist definitiv geschlossen.
Und... eine "ldf"-Datei gibt es von der Problem-DB garnicht...
Grüße von
Yan
Die im obigen Screenshot markierte Instanz (wenn es denn die Instanz ist) angehalten.
Die darunter sind somit wohl autom. angehalten.
Dann habe ich den Speicherplatz der mdf-Datei ermittelt.
Dann wollte ich die mdf-Datei kopieren, aber erhalte dann die folgende Fehlermeldung, die ich überhaupt nicht verstehe:
Das MS SQL-Management Studio ist definitiv geschlossen.
Und... eine "ldf"-Datei gibt es von der Problem-DB garnicht...
Grüße von
Yan
Hast du denn schon mal die Platte oder SSD auf Schreib/Lesefehler überprüft? Sieht für mich eher nach einem Hardware defekt der Platte/SSD aus als ein DB Problem (das ist nur die Auswirkung des Defekts).
Das steht letztendlich auch in der Fehlermeldung: "Fehler beim Lesen auf …". Das würde gleichzeitig das Problem mit dem Klonen der VM erklären.
Das steht letztendlich auch in der Fehlermeldung: "Fehler beim Lesen auf …". Das würde gleichzeitig das Problem mit dem Klonen der VM erklären.
...ok und danke für den Tipp.
Werde das mal weitergeben an unseren IT-Dienstleister... ob der darauf auch schon gekommen ist
Grüße von
Yan
Werde das mal weitergeben an unseren IT-Dienstleister... ob der darauf auch schon gekommen ist
Grüße von
Yan
Hallo Yan,
mich wundert gerade ein bisschen, daß beim Stichwort "Defekte Datenbank" noch keiner den Befehl dbcc erwähnt hat. Damit kann man eine Datenbank prüfen und auch reparieren, je nach Schweregrad mit oder ohne Datenverlust.
Um die Datenbank zu prüfen gib mal im Management Studio "dbcc checkdb" ein, das prüft Deine Datenbank auf Schäden hin.
Um die Datenbank zu reparieren gibt es die Befehle
dbcc checkdb (<Datenbank>, repair_rebuild)
und
dbcc checkdb (<Datenbank>, repair_allow_data_loss)
repair_rebuild funktioniert ohne Datenverlust, repair_allow_data_loss kann Datenverlust nach sich ziehen. Ich vermute mal, ohne Datenverlust wirst Du nicht rauskommen.
Vor der DB-Reparatur mußt Du die DB auf Einzelbenutzermodus setzen, wie das geht, kannst Du da nachlesen: SQL DBCC Repair repariert nicht?
Gruß, Mad Max
mich wundert gerade ein bisschen, daß beim Stichwort "Defekte Datenbank" noch keiner den Befehl dbcc erwähnt hat. Damit kann man eine Datenbank prüfen und auch reparieren, je nach Schweregrad mit oder ohne Datenverlust.
Um die Datenbank zu prüfen gib mal im Management Studio "dbcc checkdb" ein, das prüft Deine Datenbank auf Schäden hin.
Um die Datenbank zu reparieren gibt es die Befehle
dbcc checkdb (<Datenbank>, repair_rebuild)
und
dbcc checkdb (<Datenbank>, repair_allow_data_loss)
repair_rebuild funktioniert ohne Datenverlust, repair_allow_data_loss kann Datenverlust nach sich ziehen. Ich vermute mal, ohne Datenverlust wirst Du nicht rauskommen.
Vor der DB-Reparatur mußt Du die DB auf Einzelbenutzermodus setzen, wie das geht, kannst Du da nachlesen: SQL DBCC Repair repariert nicht?
Gruß, Mad Max
Und noch ein Nachtrag zur Sicherung der Datenbank:
Wenn ich davon ausgehe, daß Ihr das Wiederherstellungsmodell "Vollständig" eingestellt habt, dann solltet Ihr auch das Transaktionsprotokoll regelmäßig sichern. Du kannst dann nochmal das letzte Transaktionslog sichern, damit Du den letzten Stand von der Datenbank hast, und dann mit der Datenbanksicherung vom Januar und allen Transaktionslogs danach die Datenbank wiederherstellen.
Das wäre dann sogar ohne Datenverlust.
Gruß, Mad Max
Wenn ich davon ausgehe, daß Ihr das Wiederherstellungsmodell "Vollständig" eingestellt habt, dann solltet Ihr auch das Transaktionsprotokoll regelmäßig sichern. Du kannst dann nochmal das letzte Transaktionslog sichern, damit Du den letzten Stand von der Datenbank hast, und dann mit der Datenbanksicherung vom Januar und allen Transaktionslogs danach die Datenbank wiederherstellen.
Das wäre dann sogar ohne Datenverlust.
Gruß, Mad Max
Wie funktioniert denn deine Software? Denn wenn es (was ich mal vermute) ne Client/Server-Software ist dann sollte die Anwendung auf den Clients ja nicht zwingend direkt auf die DB gehen... Daher würde ich mal _ALLE_ Software beenden (also alle Clients und auch den Serverteil der Software) und die Sicherung dann versuchen. Es kann ja durchaus sein das die im Hintergrund irgendwelche Aktionen macht und du damit Datenbestände hast die sich permanent ändern...
Wobei ich bei der Fehlermeldung auch eher auf nen Hardware-Problem bei den Festplatten tippen würde -> aber wäre ja auch nich die erste Software die Fehlermeldungen wirft die einfach mal völlig sinnlos sind...
Wobei ich bei der Fehlermeldung auch eher auf nen Hardware-Problem bei den Festplatten tippen würde -> aber wäre ja auch nich die erste Software die Fehlermeldungen wirft die einfach mal völlig sinnlos sind...
Moin,
Mein Gedanke beim Lesen des Ausgangspost war im übrigen: „da wird die Festplatte ein Prblem haben“ das bitte unbedingt checken.
Zitat von @Yan2021:
Dann wollte ich die mdf-Datei kopieren, aber erhalte dann die folgende Fehlermeldung, die ich überhaupt nicht verstehe:
Das MS SQL-Management Studio ist definitiv geschlossen.
Das studio ist nur eine GUI zum verwalten. Du musst die SQL-Dienste beenden (findest du unter Dienste)Dann wollte ich die mdf-Datei kopieren, aber erhalte dann die folgende Fehlermeldung, die ich überhaupt nicht verstehe:
Das MS SQL-Management Studio ist definitiv geschlossen.
Und... eine "ldf"-Datei gibt es von der Problem-DB garnicht...
Mein Gedanke beim Lesen des Ausgangspost war im übrigen: „da wird die Festplatte ein Prblem haben“ das bitte unbedingt checken.
Ich bin immer erst für eine Kopie der Dateien. Danach kann man alles versuchen, je nach Server Hardware würde ich eventuell die Hardware + OS + DB Installation komplett neu machen und mich gar nicht mit dem alten ### belasten. Zumindest nicht um eine DB Sicherung zu testen oder die DB zu prüfen.
Die Datei wird nicht als unlesbar gemeldet sondern als geöffnet. Sogar als geöffnet durch "SQL Server (MSSQLSERVER)". Das kann nur ein SQL Dienst sein, auch eine Serveranwendung / Dienst greift nicht direkt auf die mdf zu. MSSQL ist schließlich ein DBMS und nicht nur eine DB.
Zur Not alle Dienste mit SQL auf Deaktiviert setzen und neu starten. Im Anschluss sollte keine Meldung zu geöffnet mehr kommen. Gibt es eventuell einen Task der die Datenbank-Instanz neu startet? Klingt alles nicht unbedingt nach einer Software, die sich groß um ihre Datenbank kümmert. Die haben bestimmt sowas "sinnvolles" eingebaut.
Die Datei wird nicht als unlesbar gemeldet sondern als geöffnet. Sogar als geöffnet durch "SQL Server (MSSQLSERVER)". Das kann nur ein SQL Dienst sein, auch eine Serveranwendung / Dienst greift nicht direkt auf die mdf zu. MSSQL ist schließlich ein DBMS und nicht nur eine DB.
Zur Not alle Dienste mit SQL auf Deaktiviert setzen und neu starten. Im Anschluss sollte keine Meldung zu geöffnet mehr kommen. Gibt es eventuell einen Task der die Datenbank-Instanz neu startet? Klingt alles nicht unbedingt nach einer Software, die sich groß um ihre Datenbank kümmert. Die haben bestimmt sowas "sinnvolles" eingebaut.
Hallo, da es ja einfach sein soll probier mal den SQL Server Migration Assistant von Microsoft ob der den Inhalt der DB auf einen anderen SQL Server kopieren kann.
Reperaturversuche direkt an der Datenbank wie von @MadMax beschrieben würde ich erst machen wenn ich eine Kopie der Datenbanken habe.
Hier erst wie schon geschrieben den Dienst des SQL Servers stoppen, danach kann man normalerweise die Dateien kopieren, ich befürchte hier aber wieder den CRC Fehler
Reperaturversuche direkt an der Datenbank wie von @MadMax beschrieben würde ich erst machen wenn ich eine Kopie der Datenbanken habe.
Hier erst wie schon geschrieben den Dienst des SQL Servers stoppen, danach kann man normalerweise die Dateien kopieren, ich befürchte hier aber wieder den CRC Fehler
1
Hallo und danke für die weiteren Infos und Tipps.
Bei meinen Versuchen gestern hatte ich die Dienste ja beendet (siehe meine entspr. Nachrichten dazu). Und ich hatte auch gecheckt, ob wirklich alle Dienste deaktiviert sind... das war so.
Das mit dem Transaktionsprotokoll ( @MadMax: ) habe ich noch nicht so ganz verstanden. Vielleicht kannst Du mir nochmal genauer erklären, was Du meinst und wie ich das mache.
Bezüglich der DB-Prüfung (Check) bin ich natürlich sicher, dass unser IT-Dienstleister das bereits gemacht hat... und selbst wenn nicht, hätte der Microsoft-Support diesen Vorschlag ganz sicher auch gemacht.
Und es wurden ja bereits mehrere Versuche gemacht, die DB zu reparieren. Daher ist ja dann eigentlich auch klar, dass sie vorher gecheckt wurde.
@maretz:
Die Software war definitiv beendet und nicht mehr aktiv. Ich hatte auch im IIS-Manager die entspr. Webseite angehalten, was ich auch immer mache, bevor ich ein Update installiere, damit wirklich Niemand mehr auf das Programm zugreifen kann.
Ich habe den IT-Dienstleister gestern per Email plus entsp. Screenshots über meine gescheiterten Versuche informiert und dabei auch das Thema "defekte Festplatte..." angesprochen. Bisher kam noch keine Reaktion.
Sobald hier was kommt, würde ich nochmal hier antworten.
Grüße,
Werker
Bei meinen Versuchen gestern hatte ich die Dienste ja beendet (siehe meine entspr. Nachrichten dazu). Und ich hatte auch gecheckt, ob wirklich alle Dienste deaktiviert sind... das war so.
Das mit dem Transaktionsprotokoll ( @MadMax: ) habe ich noch nicht so ganz verstanden. Vielleicht kannst Du mir nochmal genauer erklären, was Du meinst und wie ich das mache.
Bezüglich der DB-Prüfung (Check) bin ich natürlich sicher, dass unser IT-Dienstleister das bereits gemacht hat... und selbst wenn nicht, hätte der Microsoft-Support diesen Vorschlag ganz sicher auch gemacht.
Und es wurden ja bereits mehrere Versuche gemacht, die DB zu reparieren. Daher ist ja dann eigentlich auch klar, dass sie vorher gecheckt wurde.
@maretz:
Die Software war definitiv beendet und nicht mehr aktiv. Ich hatte auch im IIS-Manager die entspr. Webseite angehalten, was ich auch immer mache, bevor ich ein Update installiere, damit wirklich Niemand mehr auf das Programm zugreifen kann.
Ich habe den IT-Dienstleister gestern per Email plus entsp. Screenshots über meine gescheiterten Versuche informiert und dabei auch das Thema "defekte Festplatte..." angesprochen. Bisher kam noch keine Reaktion.
Sobald hier was kommt, würde ich nochmal hier antworten.
Grüße,
Werker
Hallo Yan,
eine Empfehlung von mir:
- Was steht im Log vom SQL-Server bei der fehlerhaften Sicherung ?
- Hat das Datenbankfile / Log-File der Datenbank noch freien Festplattenplatz zur Verfügung ? (Ist die max. Größe
erreicht ?)
- Ist eine Voll-Sicherung der Datenbank mit der Datensicherungssoftware möglich ? -> So kann das Log-File der
Datenbank verkleinert werden.
Nette Grüße
Scout71
eine Empfehlung von mir:
- Was steht im Log vom SQL-Server bei der fehlerhaften Sicherung ?
- Hat das Datenbankfile / Log-File der Datenbank noch freien Festplattenplatz zur Verfügung ? (Ist die max. Größe
erreicht ?)
- Ist eine Voll-Sicherung der Datenbank mit der Datensicherungssoftware möglich ? -> So kann das Log-File der
Datenbank verkleinert werden.
Nette Grüße
Scout71
Bei meinen Versuchen gestern hatte ich die Dienste ja beendet (siehe meine entspr. Nachrichten dazu). Und ich hatte auch gecheckt, ob wirklich alle Dienste deaktiviert sind... das war so.
In welcher Instanz (MSSQLServer oder SFIRM) hängt die oh.mdf?Zudem spricht das Bild deines Screenshots was anderes. Irgendwas hat noch auf die mdf zugegriffen. Du musst folgende Dienste checken:
- SQL Server
- SQL Server Agent
- SQL Server Browser
- SQL Server Reporting Services
- SQL Server VSS Writer
Und dabei auch prüfen, ob die Prozesse wirklich beendet sind.
Am sichersten, wie bereits weiter oben (von @ukulele-7 ?) vorgeschlagen: Dienste alle auf "deaktiviert" setzen und den Server rebooten.
Fernab dessen:
versuch mal, die Sicherung nicht nach D:\MSSQLDaten\BACKUP anlegen zu lassen, sondern (ich weiss gar nicht, ob das geht) auf ein Netzwerkshare (vorher per Net-Use mounten) oder ein anderes Volume.
Schlimmstenfalls eine SSD per USB anschließen und darauf sichern.
Habt ihr eigentlich mal probiert, die mdf per LiveLinux o. ä. wegzukopieren?
Also Server herunterfahren, Knoppix oder was auch immer auf einen Stick packen und dann davon booten...
Hallo,
ich habe jetzt wirklich alle SQL-Dienste DEAKTIVIERT!!
Über den IIS-Manager auch die Webseite (für das eigentliche Programm) beendet.
Dann die "oh.mdf" kopieren wollen und erhielt wieder die gleiche Fehlermeldung, wie weiter oben schon. Also dass die "Datei in SQL-Server (MSSQLSERVER) geöffnet" sei. Siehe hier:
Und natürlich sind alle User aus dem Programm ausgestiegen und können auch nicht damit arbeiten, da die Webseite beendet ist.
Bei 70% kam dann diese Fehlermeldung:
Danach habe ich dann mal "überspringen" ausgewählt. Aber da wurde dann überhaupt nichts kopiert.
Was nun?
Grüße von
Yan
ich habe jetzt wirklich alle SQL-Dienste DEAKTIVIERT!!
Über den IIS-Manager auch die Webseite (für das eigentliche Programm) beendet.
Dann die "oh.mdf" kopieren wollen und erhielt wieder die gleiche Fehlermeldung, wie weiter oben schon. Also dass die "Datei in SQL-Server (MSSQLSERVER) geöffnet" sei. Siehe hier:
Und natürlich sind alle User aus dem Programm ausgestiegen und können auch nicht damit arbeiten, da die Webseite beendet ist.
Bei 70% kam dann diese Fehlermeldung:
Danach habe ich dann mal "überspringen" ausgewählt. Aber da wurde dann überhaupt nichts kopiert.
Was nun?
Grüße von
Yan
ich habe jetzt wirklich alle SQL-Dienste DEAKTIVIERT!!
Deaktiviert heißt nicht, dass die Dienste beendet sind. Laufen die Dienste also noch (Status = ausgeführt)?Die musst du dann noch beenden!
siehe Screenshot. Alle Dienste sind beendet und deaktiviert.
Grüße von
Yan
Grüße von
Yan
...ich würde in ein paar Minuten aber die Dienste wieder starten wollen, damit die Kollegen weiterarbeiten können.
Vielleicht hat aber noch jemand einen Tipp vorher...
Der IT-Dienstleister hat übrigens noch immer nicht auf meine Email von gestern geantwortet mit den Screenshots sowie dem Hinweis auf die evtl. defekte Festplatte
Grüße von
Yan
Vielleicht hat aber noch jemand einen Tipp vorher...
Der IT-Dienstleister hat übrigens noch immer nicht auf meine Email von gestern geantwortet mit den Screenshots sowie dem Hinweis auf die evtl. defekte Festplatte
Grüße von
Yan
der ist zum Zeitpunkt meines Posts noch nicht dagewesen.
Irgendwas greift da noch drauf zu. Hast du, nachdem die Dienste deaktiviert und beendet wurden, den Server einmal neugestartet?
Wenn der schreibt kann nicht gelesen werden, kann der CRC Fehler auch der Grund sein. Im Schlimmsten Fall ne kopie mit Linux DD. Aber probier doch wirklich mal den Migrations Assistent nlvon Microsoft. Wenn du mit der DB arbeiten kannst, vielleicht hast du Glück.
Hallo Yan,
ein Backup ist nur eine Momentaufnahme Deiner Datenbank. Was auf der DB passiert, wird aber ständig mitprotokolliert. Wenn das Wiederherstellungsmodell "Vollständig" ist (DB-Eigenschaften, Seite "Optionen"), dann wird dieses Protokoll erst gelöscht, wenn es gesichert wurde, ansonsten wächst es immer weiter. Dein IT-Dienstleister sollte Dir die Frage beantworten können, wie oft es gesichert wird und ob Eure Protokollsicherungen bis zur letzten Vollsicherung zurückreichen.
Wenn Ihr die Protokollsicherungen alle habt, dann mußt Du nur noch den letzten Teil, der noch nicht gesichert wurde, sichern und kannst dann erst die Vollsicherung und anschließend alle nachfolgenden Protokolle einspielen und hast den aktuellen Stand der DB.
Was die Prüfung angeht: im Prinzip hast Du recht, da sollten sowohl Dein Dienstleister, als auch der MS-Support dran gedacht haben. Aber auch hier hat niemand was dazu gesagt vor mir und hier sind einige fähige Leute versammelt. Und vielleicht hat auch der MS-Support gedacht, daß man einem erfahrenen Admin sowas nicht erzählen muß
Ich muß aber sagen: Die Prüfung dauert ein paar Minuten. Wenn Du einem Admin, der ein halbes Jahr lang nicht bemerkt, daß die Sicherung nicht läuft, so vertraust, daß Du es nicht nochmal selber prüfen willst, dann ok.
Gruß, Mad Max
ein Backup ist nur eine Momentaufnahme Deiner Datenbank. Was auf der DB passiert, wird aber ständig mitprotokolliert. Wenn das Wiederherstellungsmodell "Vollständig" ist (DB-Eigenschaften, Seite "Optionen"), dann wird dieses Protokoll erst gelöscht, wenn es gesichert wurde, ansonsten wächst es immer weiter. Dein IT-Dienstleister sollte Dir die Frage beantworten können, wie oft es gesichert wird und ob Eure Protokollsicherungen bis zur letzten Vollsicherung zurückreichen.
Wenn Ihr die Protokollsicherungen alle habt, dann mußt Du nur noch den letzten Teil, der noch nicht gesichert wurde, sichern und kannst dann erst die Vollsicherung und anschließend alle nachfolgenden Protokolle einspielen und hast den aktuellen Stand der DB.
Was die Prüfung angeht: im Prinzip hast Du recht, da sollten sowohl Dein Dienstleister, als auch der MS-Support dran gedacht haben. Aber auch hier hat niemand was dazu gesagt vor mir und hier sind einige fähige Leute versammelt. Und vielleicht hat auch der MS-Support gedacht, daß man einem erfahrenen Admin sowas nicht erzählen muß
Ich muß aber sagen: Die Prüfung dauert ein paar Minuten. Wenn Du einem Admin, der ein halbes Jahr lang nicht bemerkt, daß die Sicherung nicht läuft, so vertraust, daß Du es nicht nochmal selber prüfen willst, dann ok.
Gruß, Mad Max
Also es macht tatsächlich den Eindruck, das die Meldung "ist noch geöffnet" nicht aufgrund einer geöffneten DB-Datei kommt, vor allem, wenn das erst bei 70% Kopiervorgang erscheint - sonderbar. Du kannst du prüfen, ob die Datei eventuell über das Netzwerk geöffnet wurde
Computerverwaltung \ Freigegebene Ordner \ Geöffnete Dateien
das sollte natürlich bei einer mdf ldf nicht der Fall sein! Ansonsten macht ein Versuch unter Live Linux Sinn.
An einem gewissen Punkt musst du eventuell entscheiden, wie wichtig dir die Daten sind. Wenn sich das nicht kopieren lässt und dein Systemhaus auch nur probiert und du mit unserer Hilfe auch nur probierst kommt vielleicht irgendwann der Moment, wo man etwas verschlimmert. Du könntest die Serverfestplatten (ist das eine VM oder direkt bare metal?) auch z.B. bei Ontrack einschicken und eine Datenrettung machen lassen. Die Kosten dürften sich eventuell im Rahmen halten und eine Cyberversicherung würde das vermutlich bezahlen. Derzeit arbeitest du quasi ohne "Sicherheitsnetz" an der einzigen Kopie, da sollte man schon mal in sich gehen.
Natürlich wäre es nach wie vor eine gute Option, alle Tabellen etc. von einem Verbundenen SQL Server aus händisch zu kopieren oder mit irgendeinem Migrationstool, wie bereits vorgeschlagen, zu versuchen, die Daten umzuziehen oder zu klonen. Das ist aber mit Sicherheit auch viel Aufwand, vor allem, wenn der Software-Hersteller so toll mit wirkt.
Computerverwaltung \ Freigegebene Ordner \ Geöffnete Dateien
das sollte natürlich bei einer mdf ldf nicht der Fall sein! Ansonsten macht ein Versuch unter Live Linux Sinn.
An einem gewissen Punkt musst du eventuell entscheiden, wie wichtig dir die Daten sind. Wenn sich das nicht kopieren lässt und dein Systemhaus auch nur probiert und du mit unserer Hilfe auch nur probierst kommt vielleicht irgendwann der Moment, wo man etwas verschlimmert. Du könntest die Serverfestplatten (ist das eine VM oder direkt bare metal?) auch z.B. bei Ontrack einschicken und eine Datenrettung machen lassen. Die Kosten dürften sich eventuell im Rahmen halten und eine Cyberversicherung würde das vermutlich bezahlen. Derzeit arbeitest du quasi ohne "Sicherheitsnetz" an der einzigen Kopie, da sollte man schon mal in sich gehen.
Natürlich wäre es nach wie vor eine gute Option, alle Tabellen etc. von einem Verbundenen SQL Server aus händisch zu kopieren oder mit irgendeinem Migrationstool, wie bereits vorgeschlagen, zu versuchen, die Daten umzuziehen oder zu klonen. Das ist aber mit Sicherheit auch viel Aufwand, vor allem, wenn der Software-Hersteller so toll mit wirkt.
Weiterarbeiten mit der DB ist semi-optimal.
So oder so muss rasch eine Lösung her, damit der Schade nicht zu groß wird.
https://www.stellarinfo.com/blog/de/sql-datenbank-fehler-bei-der-zyklisc ...
Da nochmal Infos zu CRC Fehlern und möglichen Lösungsansätzen.
So oder so muss rasch eine Lösung her, damit der Schade nicht zu groß wird.
https://www.stellarinfo.com/blog/de/sql-datenbank-fehler-bei-der-zyklisc ...
Da nochmal Infos zu CRC Fehlern und möglichen Lösungsansätzen.
Hallo und ich hoffe, Ihr hattet ein schönes WE...
Ich habe mir eben mal die Eigenschaften / Optionen der Datenbank angeschaut.
Das Wiederherstellungsmodell steht nur auf "Einfach" und unten bei Seitenüberprüfung steht "CHECKSUM".
Eben habe ich mal eine Abfrage ausgeführt mit "dbcc checkdb", wie ja vorgeschlagen wurde.
Auch da kam eine Fehlermeldung mit weiterem Text. Siehe hier:
Ich habe nur die beiden ersten Ergebnis-Zeilen hier einkopiert. Davon gibt es noch eine riesige Menge weiterer Einträge. Ganz unten das ist die letzte Zeile mit einer Art Gesamtergebnis.
Der IT-Dienstleister hat mir auf meine Fragen auch bis jetzt noch nicht geantwortet.... hmmm... ist vielleicht auch ein gewisses Zeichen
Den Link von @Crusher79 gebe ich nun auch mal an unseren IT-Dienstleister weiter.
Ich hoffe, Ihr versteht mich.
Ich tue mich etwas schwer damit, manche der von Euch vorgeschlagenen Prüfungen / Arbeiten an der DB durchzuführen. Falls da etwas schief läuft und die DB dann wirklich im Eimer ist, dann habe ich natürlich den "Schwarzen Peter" und der IT-Dienstleister ist dann fein raus...
Ich werde Eure Tipps aber Stück für Stück an den IT-Dienstleister weitergeben, wenn er mir denn endlich mal antwortet. Falls bis heute Mittag nix gekommen ist, werde ich ihn mal anrufen und fragen.
Also bitte nicht böse sein, dass ich Eure guten Vorschläge nicht gleich umsetze...
Danke jedenfalls für die super Unterstützung bis dahin.
Grüße von
Yan
Ich habe mir eben mal die Eigenschaften / Optionen der Datenbank angeschaut.
Das Wiederherstellungsmodell steht nur auf "Einfach" und unten bei Seitenüberprüfung steht "CHECKSUM".
Eben habe ich mal eine Abfrage ausgeführt mit "dbcc checkdb", wie ja vorgeschlagen wurde.
Auch da kam eine Fehlermeldung mit weiterem Text. Siehe hier:
DBCC-Ergebnis für "ohdas".
Meldung 8921, Ebene 16, Status 1, Zeile 1
Die CHECK-Anweisung wurde beendet. Fehler beim Sammeln von Fakten. Möglicherweise ist kein freier Speicherplatz mehr in "tempdb" vorhanden, oder eine Systemtabelle ist inkonsistent. Überprüfen Sie die vorherigen Fehler.
DBCC-Ergebnis für "sys.sysrscols".
Es sind 10713 Zeilen auf 170 Seiten für das sys.sysrscols-Objekt vorhanden.
DBCC-Ergebnis für "sys.sysrowsets".
Es sind 2133 Zeilen auf 20 Seiten für das sys.sysrowsets-Objekt vorhanden.
...
...
...
Es sind 522652 Zeilen auf 43035 Seiten für das payment-Objekt vorhanden.
Von CHECKDB wurden 0 Zuordnungsfehler und 0 Konsistenzfehler in der ohdas-Datenbank gefunden.Ich habe nur die beiden ersten Ergebnis-Zeilen hier einkopiert. Davon gibt es noch eine riesige Menge weiterer Einträge. Ganz unten das ist die letzte Zeile mit einer Art Gesamtergebnis.
Der IT-Dienstleister hat mir auf meine Fragen auch bis jetzt noch nicht geantwortet.... hmmm... ist vielleicht auch ein gewisses Zeichen
Den Link von @Crusher79 gebe ich nun auch mal an unseren IT-Dienstleister weiter.
Ich hoffe, Ihr versteht mich.
Ich tue mich etwas schwer damit, manche der von Euch vorgeschlagenen Prüfungen / Arbeiten an der DB durchzuführen. Falls da etwas schief läuft und die DB dann wirklich im Eimer ist, dann habe ich natürlich den "Schwarzen Peter" und der IT-Dienstleister ist dann fein raus...
Ich werde Eure Tipps aber Stück für Stück an den IT-Dienstleister weitergeben, wenn er mir denn endlich mal antwortet. Falls bis heute Mittag nix gekommen ist, werde ich ihn mal anrufen und fragen.
Also bitte nicht böse sein, dass ich Eure guten Vorschläge nicht gleich umsetze...
Danke jedenfalls für die super Unterstützung bis dahin.
Grüße von
Yan
UPDATE:
Soeben habe ich eine Antwort des IT-Dienstleisters erhalten.
Er schreibt, dass ich richtig lag mit meiner Vermutung (womit er unwissenderweise natürlich EUCH meint ). Durch den Ausfall der 3 physischen Festplatten, welche kürzlich bei uns gewechselt wurden, ist die „virtuelle“ Festplatte des entspr. Servers beschädigt. Dadurch auch die Abbrüche beim Kopieren der mdf-Datei, dem Klonen des Servers oder dem Erstellen eines Backups mit dem Programm "Altaro".
Er schreibt weiterhin, dass er erst dadurch ja ursprünglich darauf aufmerksam geworden sei, dass die physischen Festplatten beschädigt waren.
Aus diesem Grund fährt er aktuell auch zweigleisig:
- zum einen versucht er, die virtuelle Festplatte bzw. das Dateisystem zu reparieren, und zum anderen
- die Datenbank selbst zu reparieren.
Er schreibt noch, dass er nun auch nochmal Rückmeldung von Microsoft erhalten hat mit weiteren Möglichkeiten, welche er heute Vormittag umsetzen will.
Das als Zwischeninfo...
Grüße von
Yan
Soeben habe ich eine Antwort des IT-Dienstleisters erhalten.
Er schreibt, dass ich richtig lag mit meiner Vermutung (womit er unwissenderweise natürlich EUCH meint
). Durch den Ausfall der 3 physischen Festplatten, welche kürzlich bei uns gewechselt wurden, ist die „virtuelle“ Festplatte des entspr. Servers beschädigt. Dadurch auch die Abbrüche beim Kopieren der mdf-Datei, dem Klonen des Servers oder dem Erstellen eines Backups mit dem Programm "Altaro".Er schreibt weiterhin, dass er erst dadurch ja ursprünglich darauf aufmerksam geworden sei, dass die physischen Festplatten beschädigt waren.
Aus diesem Grund fährt er aktuell auch zweigleisig:
- zum einen versucht er, die virtuelle Festplatte bzw. das Dateisystem zu reparieren, und zum anderen
- die Datenbank selbst zu reparieren.
Er schreibt noch, dass er nun auch nochmal Rückmeldung von Microsoft erhalten hat mit weiteren Möglichkeiten, welche er heute Vormittag umsetzen will.
Das als Zwischeninfo...
Grüße von
Yan
Hallo Yan,
wir hatten mal einen ähnlichen Fall.
Wir hatten ein Problem im SQL-Cluster, dass sich nicht mehr lösen lies.
Ich kann nur soviel sagen. Von Seiten Microsoft kam nichts, WIRKLICH gar nichts. Also richtig uncool.
Sie konnten unsere DB NICHT mehr zum Laufen bringen.
Unser sehr guter Dienstleister, der ausschließlich DB's macht, war ebenfalls an seine Grenzen gekommen.
Wir mussten letztendlich auf einen neuen SQL Server wechseln und das letzte Backup zurück spielen.
War ganz uncool und logischerweise mit Datenverlust verbunden.
Die Datenbank Sicherung sollte UNBEDINGT bei euch überwacht werden, was ein guter SLA Partner eigentlich machen MUSS. Selbst wenn ihr mit Boardmiteln, wie wir, eure Backup's fahrt, ist hier ein Alerting per eMail problemlos einzurichten. Damit erhaltet ihr sofort eMails, wenn das Backup NICHT 100% lief.
Ich wünsche euch viel Glück und unbedingt daraus lernen.
Gruss Roland
wir hatten mal einen ähnlichen Fall.
Wir hatten ein Problem im SQL-Cluster, dass sich nicht mehr lösen lies.
Ich kann nur soviel sagen. Von Seiten Microsoft kam nichts, WIRKLICH gar nichts. Also richtig uncool.
Sie konnten unsere DB NICHT mehr zum Laufen bringen.
Unser sehr guter Dienstleister, der ausschließlich DB's macht, war ebenfalls an seine Grenzen gekommen.
Wir mussten letztendlich auf einen neuen SQL Server wechseln und das letzte Backup zurück spielen.
War ganz uncool und logischerweise mit Datenverlust verbunden.
Die Datenbank Sicherung sollte UNBEDINGT bei euch überwacht werden, was ein guter SLA Partner eigentlich machen MUSS. Selbst wenn ihr mit Boardmiteln, wie wir, eure Backup's fahrt, ist hier ein Alerting per eMail problemlos einzurichten. Damit erhaltet ihr sofort eMails, wenn das Backup NICHT 100% lief.
Ich wünsche euch viel Glück und unbedingt daraus lernen.
Gruss Roland
Hallo nochmal...
Ich wollte nur nochmal kurz mitteilen, dass heute ein weiterer Reparaturversuch durchgeführt wird, wozu auch ein vorheriger Server-Neustart nötig ist. Dieser Versuch wird durch unseren IT-Dienstleister durchgeführt und der Tipp kam erneut vom Microsoft-Support. Ich hoffe, dass er diesmal Erfolg hat
Das nur als Zwischen-Info. Werde weiter berichten...
Grüße von
Yan
Ich wollte nur nochmal kurz mitteilen, dass heute ein weiterer Reparaturversuch durchgeführt wird, wozu auch ein vorheriger Server-Neustart nötig ist. Dieser Versuch wird durch unseren IT-Dienstleister durchgeführt und der Tipp kam erneut vom Microsoft-Support. Ich hoffe, dass er diesmal Erfolg hat
Das nur als Zwischen-Info. Werde weiter berichten...
Grüße von
Yan
1
Hallo mal wieder...
Der neue Reparaturversuch durch unseren IT-Dienstleister hat wohl auch nichts gebracht.
Er bat mich heute Morgen, nochmal die Sicherung der SQL-DB durchzuführen.
Leider brach die Sicherung erneut bei 70% ab
Er will sich das aber nochmal anschauen (was er natürlich schon zig mal getan hat innerhalb der letzten Wochen)...
So langsam befürchte ich, dass wir so nicht mehr weiterkommen und ggf. doch weitere Schritte unternehmen müssen, wie ja hier auch bereits vorgeschlagen. Ich weiß jedoch nicht, welche Schritte im Einzelnen bereits durchgeführt wurden. Vielleicht sollte ich den IT-Dienstleister genau das mal fragen - oder was meint Ihr?
Grüße von
Yan
Der neue Reparaturversuch durch unseren IT-Dienstleister hat wohl auch nichts gebracht.
Er bat mich heute Morgen, nochmal die Sicherung der SQL-DB durchzuführen.
Leider brach die Sicherung erneut bei 70% ab
Er will sich das aber nochmal anschauen (was er natürlich schon zig mal getan hat innerhalb der letzten Wochen)...
So langsam befürchte ich, dass wir so nicht mehr weiterkommen und ggf. doch weitere Schritte unternehmen müssen, wie ja hier auch bereits vorgeschlagen. Ich weiß jedoch nicht, welche Schritte im Einzelnen bereits durchgeführt wurden. Vielleicht sollte ich den IT-Dienstleister genau das mal fragen - oder was meint Ihr?
Grüße von
Yan
Ich weiß jedoch nicht, welche Schritte im Einzelnen bereits durchgeführt wurden. Vielleicht sollte ich den IT-Dienstleister genau das mal fragen - oder was meint Ihr?
Bitte unbedingt.Was du aber weiterhin selbst machen kannst (und oben auch schon mehrfach erwähnt wurde):
- Server herunterfahren
- Server von einem LiveLinux (knoppix, ...) booten
- Speicherort der mdf + ldf "ansteuern"
- Beide Dateien woanders hinkopieren (auf eine andere VHD, oder einen zu mountenden Netzwerkshare)
Und dann mal schauen, ob sich die DB woanders einbinden ließe...
Ich würde auch mal die DB File's (gestoppter Dienst) kopieren und an einen anderen SQL-Server anbinden.
Hier gäbe es sicherlich mehr Spielraum um zu testen und "rumreisen", ohne dass die Produktion davon betroffen wäre, wenn was schief geht bzw. in Mitleidenschaft gezogen würde.
Hier kann der Dienstleister und oder Microsoft sich mal richtig austoben.
Vielleicht gibt es ja wirklich auch "nur" ein Problem mit dem NTFS/Block/Sektor, was dann bei Kopieren vermutlich auch zum Vorschein kommen würde. Dann wüsste man zumindest, dass es kein SQL/DB Problem wäre.
Viel Glück
Hier gäbe es sicherlich mehr Spielraum um zu testen und "rumreisen", ohne dass die Produktion davon betroffen wäre, wenn was schief geht bzw. in Mitleidenschaft gezogen würde.
Hier kann der Dienstleister und oder Microsoft sich mal richtig austoben.
Vielleicht gibt es ja wirklich auch "nur" ein Problem mit dem NTFS/Block/Sektor, was dann bei Kopieren vermutlich auch zum Vorschein kommen würde. Dann wüsste man zumindest, dass es kein SQL/DB Problem wäre.
Viel Glück
es kommt ja beim Kopieren nach 70% auch der Fehler, das die Quelldatei nicht gelesen werden kann.
Scheint dann eher ein Filesystem oder Hardwareproblem zu sein.
Scheint dann eher ein Filesystem oder Hardwareproblem zu sein.
Dann hilft auch der Microsoft SQL Support nichts.
Aber wie oben schon geschrieben.
Verschlimmbessern scheint nicht mehr weit zu sein.
Früher oder später musst du ein Notfallszenario in Betracht ziehen.
Die Produktion stoppen und retten, was zu retten ist und eine neue DB anfangen. (auf einen neuen SQL Server).
Den bestehenden SQL-Server würde ich sooo nicht mehr weiterverwenden.
Ich hoffe du/ihr habt da die Geschäftsleitung schon mal informiert, da sie dies logischerweise mittragen müssen.
Aber wie oben schon geschrieben.
Verschlimmbessern scheint nicht mehr weit zu sein.
Früher oder später musst du ein Notfallszenario in Betracht ziehen.
Die Produktion stoppen und retten, was zu retten ist und eine neue DB anfangen. (auf einen neuen SQL Server).
Den bestehenden SQL-Server würde ich sooo nicht mehr weiterverwenden.
Ich hoffe du/ihr habt da die Geschäftsleitung schon mal informiert, da sie dies logischerweise mittragen müssen.
Meine Rede, irgendwann muss jemand Entscheiden, was diese Daten Wert sind. Niemand sollte da "mal was versuchen" sondern eine Kopie der VM oder des ganzen RAIDs auf dem das ganze liegt oder zumindest der Datenbank-Dateien sollte Priorität A sein, noch über dem laufenden Geschäftsbetrieb. Und das kann auch nur der Verantwortliche entscheiden.
Bei dem, was bisher schon an Aufwand betreiben wurde, um gegen Symptome zu kämpfen, hätte OnTrack vielleicht schon ganz easy eine Bit-Kopie aller intakten Blöcke gezogen und mit weiteren Kopien kann man auf einem anderen Server spielen.
Ihr versucht im Moment immer wieder, den zweiten vor dem ersten Schritt zu gehen und die Datenbank einfach nur irgendwie wieder lauffähig machen zu wollen. Dabei vergeht viel Zeit. Zeit, in der es kein Backup und kein Fallback-Szenario für euren Geschäftsbetrieb gibt. Was passiert denn, wenn weitere Sektoren der HDDs Lesefehler werfen? Was plant ihr denn, auf welche Platten zieht ihr eure VMs um? Wollt ihr wirklich mit dem Server so weiter machen?
Bei dem, was bisher schon an Aufwand betreiben wurde, um gegen Symptome zu kämpfen, hätte OnTrack vielleicht schon ganz easy eine Bit-Kopie aller intakten Blöcke gezogen und mit weiteren Kopien kann man auf einem anderen Server spielen.
Ihr versucht im Moment immer wieder, den zweiten vor dem ersten Schritt zu gehen und die Datenbank einfach nur irgendwie wieder lauffähig machen zu wollen. Dabei vergeht viel Zeit. Zeit, in der es kein Backup und kein Fallback-Szenario für euren Geschäftsbetrieb gibt. Was passiert denn, wenn weitere Sektoren der HDDs Lesefehler werfen? Was plant ihr denn, auf welche Platten zieht ihr eure VMs um? Wollt ihr wirklich mit dem Server so weiter machen?
Hallo Yan,
Ihr habt beim Sichern der DB einen Lesefehler bekommen, also würde ich mal annehmen, daß Ihr die Datei oh.mdf auch im Dateisystem nicht kopieren könnt. Das heißt nicht, daß Ihr das nicht versuchen solltet. Aber vorher die Datenbank beenden oder aber mit Linux starten, wie es ja auch schon oben hieß.
Trotzdem bleibe ich dabei, Du solltest feststellen, was überhaupt kaputt ist in Eurer DB. Das mit dem dbcc checkdb hat ja einen Fehler gebracht. Der läßt sich aber vermeiden: "dbcc checkdb (<Datenbank>) with tablock". Mit dem "with tablock" läßt sich der "Fehler beim Sammeln von Fakten" umgehen, weil er dann die Tabellen und womöglich die ganze DB sperrt. Deswegen solltest Du auch den Befehl von einer anderen DB aus starten und dafür den DB-Namen eintragen.
Wenn Du Glück hast, sind entweder gar keine Tabellen betroffen oder nur irgendwelche unwichtigen. Wenn es wichtige sind, dann solltet Ihr möglicherweise in Erwägung ziehen, die HDD professionell auslesen zu lassen, damit die Daten gerettet werden.
Gruß, Mad Max
Ihr habt beim Sichern der DB einen Lesefehler bekommen, also würde ich mal annehmen, daß Ihr die Datei oh.mdf auch im Dateisystem nicht kopieren könnt. Das heißt nicht, daß Ihr das nicht versuchen solltet. Aber vorher die Datenbank beenden oder aber mit Linux starten, wie es ja auch schon oben hieß.
Trotzdem bleibe ich dabei, Du solltest feststellen, was überhaupt kaputt ist in Eurer DB. Das mit dem dbcc checkdb hat ja einen Fehler gebracht. Der läßt sich aber vermeiden: "dbcc checkdb (<Datenbank>) with tablock". Mit dem "with tablock" läßt sich der "Fehler beim Sammeln von Fakten" umgehen, weil er dann die Tabellen und womöglich die ganze DB sperrt. Deswegen solltest Du auch den Befehl von einer anderen DB aus starten und dafür den DB-Namen eintragen.
Wenn Du Glück hast, sind entweder gar keine Tabellen betroffen oder nur irgendwelche unwichtigen. Wenn es wichtige sind, dann solltet Ihr möglicherweise in Erwägung ziehen, die HDD professionell auslesen zu lassen, damit die Daten gerettet werden.
Gruß, Mad Max
Hallo und danke für die vielen weitere Antworten.
Es wird immer wieder empfohlen, die mdf-Datei zu kopieren.
Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
Den Tipp mit "dbcc checkdb datenbank with tablock" würde ich gerne mal testen.
Gebe ich das so ein, wie hier in den "" geschrieben? Also den Namen der Datenbank einfach so, wie hier geschrieben?
Vorher muss ich die DB wieder beenden... richtig?
Ich habe den IT-Dienstleister schon darum gebeten, mir mal alle Schritte und Versuche mitzuteilen, die bisher unternommen wurden. Bisher weiß ich ja überhaupt nicht, ob einige Eurer Tipps hier längst versucht wurden (z.B. Linux etc.). Das muss ich zunächst mal abwarten. Man hat mir bereits geantwortet, dass ich diese Aufstellung in Kürze bekomme.
Grüße von
Yan
Es wird immer wieder empfohlen, die mdf-Datei zu kopieren.
Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
Den Tipp mit "dbcc checkdb datenbank with tablock" würde ich gerne mal testen.
Gebe ich das so ein, wie hier in den "" geschrieben? Also den Namen der Datenbank einfach so, wie hier geschrieben?
dbcc checkdb db-name with tablockVorher muss ich die DB wieder beenden... richtig?
Ich habe den IT-Dienstleister schon darum gebeten, mir mal alle Schritte und Versuche mitzuteilen, die bisher unternommen wurden. Bisher weiß ich ja überhaupt nicht, ob einige Eurer Tipps hier längst versucht wurden (z.B. Linux etc.). Das muss ich zunächst mal abwarten. Man hat mir bereits geantwortet, dass ich diese Aufstellung in Kürze bekomme.
Grüße von
Yan
Yan vergiss nicht parallel schon anfangen einen Notfallplan zu "stricken".
Wenn das im Desaster endet hast du die Zeit vergeudet.
Du bist schon seit 2 Wochen an dem Problem; und jeden Tag mehr, wo es kein Backup gibt.
Bedeutet alles was jeden Tag neu in die DB hinzukommt, ist nachher auch "verloren", sollte dies ins Unglück laufen.
Ein Entscheidungsträger hätte hier schon LÄNGST die Reisleine gezogen und die "Produktion" gestoppt.
Also entweder ist die DB doch nicht sonderlich kritisch oder du handelst etwas blauäugig (fahrlässig).
Viel Glück (was anderes ist nach 2 Wochen nicht mehr realistisch)
Gruss Roland
Wenn das im Desaster endet hast du die Zeit vergeudet.
Du bist schon seit 2 Wochen an dem Problem; und jeden Tag mehr, wo es kein Backup gibt.
Bedeutet alles was jeden Tag neu in die DB hinzukommt, ist nachher auch "verloren", sollte dies ins Unglück laufen.
Ein Entscheidungsträger hätte hier schon LÄNGST die Reisleine gezogen und die "Produktion" gestoppt.
Also entweder ist die DB doch nicht sonderlich kritisch oder du handelst etwas blauäugig (fahrlässig).
Viel Glück (was anderes ist nach 2 Wochen nicht mehr realistisch)
Gruss Roland
da ja das Sichern und Klonen der VM scheinbar auch nicht geht, würde ich als erstes die VM herunterfahren und die Files der VM irgendwo hin kopieren.
Dann kann man eine Reparatur ausprobieren
Dann kann man eine Reparatur ausprobieren
Den Tipp mit "dbcc checkdb datenbank with tablock" würde ich gerne mal testen.
Am besten du legst den Server noch in die Mikrowelle, vielleicht hilft das ja. Irgendwann isses dann halt soweit.1Es wird immer wieder empfohlen, die mdf-Datei zu kopieren.
Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
und das womit ist was genau?Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
- ct's Notfall-Windows
- ct's desinfect?
- Knoppix?
- Und hast du auch z. B. ein
ddrescueder gesamten virtuellen Disk probiert?
Das alles geht hier nicht draus hervor.
Wir haben jetzt hier schon mehrfach geschrieben, dass du die VM herunterfahren und mit einem anderen System hochfahren bzw. die VHDX/ VMDK irgendwo hinkopieren sollst.
Hast du dies explizit gemacht oder nicht?
Moin @Yan2021,
hast du den die DB respektiven den SQL-Server beendet bevor du begonnen hast die mdf zu kopieren?
Des weiteren, ich kann dir nur empfehlen, den MS-Support auf keinen Fall an euere produktive Datenbank ranzulassen, schon gar nicht, wenn ihr dafür kein Aktuelles Backup habt. Ich habe nach solchen MS-Support-Aktionen, leider schon oft genug nur noch Scherben zusammenkehren können. 😔
Kopiert wie hier schon mehrfach vorgeschlagen wurde, die entsprechende VM auf ein anderes System und exorziert den Fehler bitte zuerst auf dieser heraus!
Und wenn das mit dem Kopieren der VM funktioniert, dann bitte nochmals eine Kopie angelegen und diese in den Tresor legen, dann habt ihr auch wieder ein halbwegs funktionierendes und aktuelles Backup. 😉
Gruss Alex
Es wird immer wieder empfohlen, die mdf-Datei zu kopieren.
Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
hast du den die DB respektiven den SQL-Server beendet bevor du begonnen hast die mdf zu kopieren?
Des weiteren, ich kann dir nur empfehlen, den MS-Support auf keinen Fall an euere produktive Datenbank ranzulassen, schon gar nicht, wenn ihr dafür kein Aktuelles Backup habt. Ich habe nach solchen MS-Support-Aktionen, leider schon oft genug nur noch Scherben zusammenkehren können. 😔
Kopiert wie hier schon mehrfach vorgeschlagen wurde, die entsprechende VM auf ein anderes System und exorziert den Fehler bitte zuerst auf dieser heraus!
Und wenn das mit dem Kopieren der VM funktioniert, dann bitte nochmals eine Kopie angelegen und diese in den Tresor legen, dann habt ihr auch wieder ein halbwegs funktionierendes und aktuelles Backup. 😉
Gruss Alex
Moin @Yan2021,
ähm ...
... das habe ich jetzt erst gesehen und ich kann dir jetzt schon sagen, dass wenn du die VM weder Klonen noch Kopieren kannst, du vor einem sehr grossen Problem stehst, weil die VM nicht von innen, sondern von aussen deffekt ist. 😔
Und das ...
... also bei einem solchen Defekt versuchen die SQL-Datenbank selbst innerhalb der VM zu Reparieren, zeugt einfach nur von absoluter Ahnungslosigkeit (der gilt übrigens hauptsächlich dem MS-Support und auch dem entsprechenden Dienstleister), weil absolut der falsche Schritt!
Denn, Falls du bereits schon die VM im heruntergefahrenen Zustand nicht mehr kopieren kannst, dann liegt der Defekt nicht innerhalb der VM sondern wie schon geschrieben eher ausserhalb. Daher ist jede Aktion in der laufenden VM, schlichtweg sinnlos. Im Gegenteil, damit könnt ihr den bisherigen Schaden, eigentlich nur noch vergrössern. 😔
Daher, falls euch die Daten dieser DB wirklich wichtig sind, dann stoppt bitte augenblicklich jeglichen Rettungsversuch innerhalb der VM! Denn das ist schlichtweg für die Katz, weil bereits schon das Dateisystem auf dem die virtuellen Platten des SQL-Servers liegen, einen Schaden hat und diesen kann man ganz sicher nicht innerhalb einer VM beheben.
Das was du jetzt benötigst ist nicht ein SQL-Spezialist, sondern einer der sich mit dem Dateisystem des entsprechenden Hypervisors 1A auskennt.
Welchen Hypervisor (VMware, Hyper-V, Proxmox) setzt ihr eigentlich ein?
Wenn Hyper-V.
Dann führe mal als nächstes ein "chkdsk" auf dem entsprechenden Volume aus und zwar ohne jeglichen Reparaturparameter ...
Beispiel:
... sprich nur mal scannen.
Gruss Alex
ähm ...
Auch das Klonen des entspr. virtuellen Servers (auf dem die DB liegt) funktioniert nicht und bricht ab... offenbar ebenfalls aufgrund der defekten Datenbank.
... das habe ich jetzt erst gesehen und ich kann dir jetzt schon sagen, dass wenn du die VM weder Klonen noch Kopieren kannst, du vor einem sehr grossen Problem stehst, weil die VM nicht von innen, sondern von aussen deffekt ist. 😔
Und das ...
Unser IT-Dienstleister hat nun schon den Microsoft-Support zur Hilfe genommen und mit deren Hilfe verschiedene Reparaturversuche für die SQL-Datenbank durchgeführt.
... also bei einem solchen Defekt versuchen die SQL-Datenbank selbst innerhalb der VM zu Reparieren, zeugt einfach nur von absoluter Ahnungslosigkeit (der gilt übrigens hauptsächlich dem MS-Support und auch dem entsprechenden Dienstleister), weil absolut der falsche Schritt!
Denn, Falls du bereits schon die VM im heruntergefahrenen Zustand nicht mehr kopieren kannst, dann liegt der Defekt nicht innerhalb der VM sondern wie schon geschrieben eher ausserhalb. Daher ist jede Aktion in der laufenden VM, schlichtweg sinnlos. Im Gegenteil, damit könnt ihr den bisherigen Schaden, eigentlich nur noch vergrössern. 😔
Daher, falls euch die Daten dieser DB wirklich wichtig sind, dann stoppt bitte augenblicklich jeglichen Rettungsversuch innerhalb der VM! Denn das ist schlichtweg für die Katz, weil bereits schon das Dateisystem auf dem die virtuellen Platten des SQL-Servers liegen, einen Schaden hat und diesen kann man ganz sicher nicht innerhalb einer VM beheben.
Das was du jetzt benötigst ist nicht ein SQL-Spezialist, sondern einer der sich mit dem Dateisystem des entsprechenden Hypervisors 1A auskennt.
Welchen Hypervisor (VMware, Hyper-V, Proxmox) setzt ihr eigentlich ein?
Wenn Hyper-V.
Dann führe mal als nächstes ein "chkdsk" auf dem entsprechenden Volume aus und zwar ohne jeglichen Reparaturparameter ...
Beispiel:
chkdsk d:... sprich nur mal scannen.
Gruss Alex
2
Hallo und danke Euch Allen nochmal.
Viele Eurer Fragen kann ich gar nicht beantworten, da die Reparatur etc. ja durch unseren IT-Dienstleister durchgeführt wird. Ich warte noch auf die Aufstellung darüber, was genau schon versucht wurde bisher...
Der SQL-Spezialist, den ich im vorherigen Post genannt hatte, ist der Mitarbeiter des Herstellers der Software der betroffenen Datenbank. Daher fand ich es wichtig, ihn mit ins Boot zu nehmen.
Ich habe nun mal 2 Tests mit "chkdsk" gemacht, wie ja hier vorgeschlagen wurde.
Die Daten liegen auf "d:", aber ich habe Laufwerk "c:" auch noch prüfen lassen.
Es wurden aber offensichtlich keine Fehler gefunden.
Hier die Ergebnisse:
...und hier nochmal mit Laufwerk C:\
Demnach scheint ja auf dem Dateisystem alles OK zu sein.
Ich habe übrigens eben den Inhalt Deines Postes (@MysticFoxDE) mal an meinen IT-Dienstleister weitergeleitet.
Habe ihm dann auch das Ergebnis der beiden "chkdsk"-Tests schon mitgeteilt.
Mal schauen, wie er reagiert...
Grüße von
Yan
Viele Eurer Fragen kann ich gar nicht beantworten, da die Reparatur etc. ja durch unseren IT-Dienstleister durchgeführt wird. Ich warte noch auf die Aufstellung darüber, was genau schon versucht wurde bisher...
Der SQL-Spezialist, den ich im vorherigen Post genannt hatte, ist der Mitarbeiter des Herstellers der Software der betroffenen Datenbank. Daher fand ich es wichtig, ihn mit ins Boot zu nehmen.
Ich habe nun mal 2 Tests mit "chkdsk" gemacht, wie ja hier vorgeschlagen wurde.
Die Daten liegen auf "d:", aber ich habe Laufwerk "c:" auch noch prüfen lassen.
Es wurden aber offensichtlich keine Fehler gefunden.
Hier die Ergebnisse:
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Users\Administrator.xxxxx>chkdsk d:
Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet Daten.
WARNUNG! Der Parameter /F wurde nicht angegeben.
CHKDSK wird im schreibgeschützten Modus ausgeführt.
Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
3072 Datensätze verarbeitet.
Dateiüberprüfung beendet.
0 große Datensätze verarbeitet.
0 ungültige Datensätze verarbeitet.
Phase 2: Die Dateinamenverknüpfung wird untersucht...
3152 Indexeinträge verarbeitet.
Indexüberprüfung beendet.
0 nicht indizierte Dateien überprüft.
0 nicht indizierte Dateien wiederhergestellt.
Phase 3: Sicherheitsbeschreibungen werden untersucht...
Überprüfung der Sicherheitsbeschreibungen beendet.
41 Datendateien verarbeitet.
CHKDSK überprüft USN-Journal...
13723856 USN-Bytes verarbeitet.
Die Überprüfung von USN-Journal ist abgeschlossen.
Dateisystem wurde überprüft, keine Probleme festgestellt.
Keine weiteren Aktionen erforderlich.
314569727 KB Speicherplatz auf dem Datenträger insgesamt
165707156 KB in 87 Dateien
52 KB in 42 Indizes
0 KB in fehlerhaften Sektoren
92463 KB vom System benutzt
65536 KB von der Protokolldatei belegt
148770056 KB auf dem Datenträger verfügbar
4096 Bytes in jeder Zuordnungseinheit
78642431 Zuordnungseinheiten auf dem Datenträger insgesamt
37192514 Zuordnungseinheiten auf dem Datenträger verfügbar...und hier nochmal mit Laufwerk C:\
C:\Users\Administrator.xxxxxxxx>chkdsk c:
Der Typ des Dateisystems ist NTFS.
WARNUNG! Der Parameter /F wurde nicht angegeben.
CHKDSK wird im schreibgeschützten Modus ausgeführt.
Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
1260800 Datensätze verarbeitet.
Dateiüberprüfung beendet.
144139 große Datensätze verarbeitet.
0 ungültige Datensätze verarbeitet.
Phase 2: Die Dateinamenverknüpfung wird untersucht...
1584254 Indexeinträge verarbeitet.
Indexüberprüfung beendet.
0 nicht indizierte Dateien überprüft.
0 nicht indizierte Dateien wiederhergestellt.
Phase 3: Sicherheitsbeschreibungen werden untersucht...
Überprüfung der Sicherheitsbeschreibungen beendet.
161728 Datendateien verarbeitet.
CHKDSK überprüft USN-Journal...
41491184 USN-Bytes verarbeitet.
Die Überprüfung von USN-Journal ist abgeschlossen.
Dateisystem wurde überprüft, keine Probleme festgestellt.
Keine weiteren Aktionen erforderlich.
314057727 KB Speicherplatz auf dem Datenträger insgesamt
169979024 KB in 454365 Dateien
424300 KB in 161729 Indizes
0 KB in fehlerhaften Sektoren
1392275 KB vom System benutzt
65536 KB von der Protokolldatei belegt
142262128 KB auf dem Datenträger verfügbar
4096 Bytes in jeder Zuordnungseinheit
78514431 Zuordnungseinheiten auf dem Datenträger insgesamt
35565532 Zuordnungseinheiten auf dem Datenträger verfügbarDemnach scheint ja auf dem Dateisystem alles OK zu sein.
Ich habe übrigens eben den Inhalt Deines Postes (@MysticFoxDE) mal an meinen IT-Dienstleister weitergeleitet.
Habe ihm dann auch das Ergebnis der beiden "chkdsk"-Tests schon mitgeteilt.
Mal schauen, wie er reagiert...
Grüße von
Yan
So, ich habe jetzt eine Antwort des IT-Dienstleisters erhalten.
Er schreibt, dass sie aktuell zweigleisig fahren:
Überprüfung der VM und Versuch die DB Direkt zu sichern.
Da als Host ein ESXI im Einsatz ist, muss man über einen Wartungszugang per SSH arbeiten
Das Ergebnis:
Somit wird die virtuelle Festplatte eher als Ursache ausgeschlossen oder zumindest zurückgestellt, da sie von außen (vmkfstools) und von innen (chkdsk) geprüft wurde und beide die Fehlerfreiheit bestätigen.
Der Sicherungsversuch per Powershell gibt folgenden Fehler aus:
Das mal als Zwischenantwort.
Der IT-Dienstleister hat mit dem Datenbank-Spezialist bereits Kontakt aufgenommen.
Grüße von
Yan
Er schreibt, dass sie aktuell zweigleisig fahren:
Überprüfung der VM und Versuch die DB Direkt zu sichern.
Da als Host ein ESXI im Einsatz ist, muss man über einen Wartungszugang per SSH arbeiten
Das Ergebnis:
Somit wird die virtuelle Festplatte eher als Ursache ausgeschlossen oder zumindest zurückgestellt, da sie von außen (vmkfstools) und von innen (chkdsk) geprüft wurde und beide die Fehlerfreiheit bestätigen.
Der Sicherungsversuch per Powershell gibt folgenden Fehler aus:
Das mal als Zwischenantwort.
Der IT-Dienstleister hat mit dem Datenbank-Spezialist bereits Kontakt aufgenommen.
Grüße von
Yan
Moin @Yan2021,
leider nein, weil nicht richtiges vorgehen. 😔
https://www.diskinternals.com/vmfs-recovery/check-vmfs-metadata/
https://de.diskinternals.com/vmfs-recovery/fix-vmfs-corruption/
Und der sagt eigentlich genau das aus was ich vermutet habe, sprich dass die Daten korrupt/beschädigt sind. 😬
Welchen Storage-Typ habt ihr am ESXi hängen?
Lasst den SQL-Spezialisten noch in Ruhe, der kann bei diesem Problem nicht wirklich weiterhelfen.
Gruss Alex
Da als Host ein ESXI im Einsatz ist, muss man über einen Wartungszugang per SSH arbeiten
Das Ergebnis:
Somit wird die virtuelle Festplatte eher als Ursache ausgeschlossen oder zumindest zurückgestellt, da sie von außen (vmkfstools) und von innen (chkdsk) geprüft wurde und beide die Fehlerfreiheit bestätigen.
Das Ergebnis:
Somit wird die virtuelle Festplatte eher als Ursache ausgeschlossen oder zumindest zurückgestellt, da sie von außen (vmkfstools) und von innen (chkdsk) geprüft wurde und beide die Fehlerfreiheit bestätigen.
leider nein, weil nicht richtiges vorgehen. 😔
https://www.diskinternals.com/vmfs-recovery/check-vmfs-metadata/
https://de.diskinternals.com/vmfs-recovery/fix-vmfs-corruption/
Der Sicherungsversuch per Powershell gibt folgenden Fehler aus:
Und der sagt eigentlich genau das aus was ich vermutet habe, sprich dass die Daten korrupt/beschädigt sind. 😬
Welchen Storage-Typ habt ihr am ESXi hängen?
Der IT-Dienstleister hat mit dem Datenbank-Spezialist bereits Kontakt aufgenommen.
Lasst den SQL-Spezialisten noch in Ruhe, der kann bei diesem Problem nicht wirklich weiterhelfen.
Gruss Alex
Moin @Yan2021,
kannst du zu dem oberen Punkt vielleicht noch ein paar Takte mehr dazu sagen, denn hier liegt glaube ich der Hund begraben. 😔
Was für ein Speichersystem nutzt ihr an diesem ESXi Host und wie waren die Laufwerke in diesem konfiguriert, sprich, welches RAID Level mit wie vielen Laufwerken?
Denn meine Kristallkugel sagt bisher das Folgende.
Die Daten des ESXi liegen in einem RAID6 Verbund und bei diesem Verbund sind euch ohne das ihr das gemerkt habt nach und nach die HDD's kaputt gegangen und als die dritte rausgeflogen ist, ist das System stehen geblieben.
Dann habt ihr die HDD, die zuletzt herausgeflogen ist wieder Online erzwungen und danach ein Rebuild angestossen.
Ist das bis hierhin korrekt so?
Gruss Alex
Durch den Ausfall der 3 physischen Festplatten, welche kürzlich bei uns gewechselt wurden, ist die „virtuelle“ Festplatte des entspr. Servers beschädigt.
kannst du zu dem oberen Punkt vielleicht noch ein paar Takte mehr dazu sagen, denn hier liegt glaube ich der Hund begraben. 😔
Was für ein Speichersystem nutzt ihr an diesem ESXi Host und wie waren die Laufwerke in diesem konfiguriert, sprich, welches RAID Level mit wie vielen Laufwerken?
Denn meine Kristallkugel sagt bisher das Folgende.
Die Daten des ESXi liegen in einem RAID6 Verbund und bei diesem Verbund sind euch ohne das ihr das gemerkt habt nach und nach die HDD's kaputt gegangen und als die dritte rausgeflogen ist, ist das System stehen geblieben.
Dann habt ihr die HDD, die zuletzt herausgeflogen ist wieder Online erzwungen und danach ein Rebuild angestossen.
Ist das bis hierhin korrekt so?
Gruss Alex
Ich möchte noch einmal an dieser Stelle ganz deutlich sagen das meine hier genannten Ideen alle auf der Annahme basieren das
a) die Verantwortlichen Personen Kenntnis von dem Problem haben und sich der Gewichtigkeit der Situation bewusst sind und das
b) jegliche Rettungsversuche unter der Prämisse stehen, das bei der Datenrettung nur das absolut nötigste am betroffenen System gemacht wird.
Bisher wurde das System ja sogar noch produktiv genutzt, so lese ich das raus. Für mich absolut unverantwortlich, wenn ein Datenverlust mit schweren Konsequenzen einhergeht.
Wenn jetzt eine Kopie der ganzen VM irgendwo auf Dateisystemebene (des VM Storage) oder auf Storage Ebene scheitert, wenn jeglicher Kopierversuch im OS der VM scheitert, dann könnte "der SQL Spezialist" bzw. der Hersteller der Software sehr wohl einen guten Dienst erbringen. Da sich die VM und SQL ja starten lassen könnt ihr einen Defektfreien Server ins Netz stellen und alle SQL Tabellen, Daten, Trigger, Prozeduren, Funktionen, Berechtigungen etc. händisch kopieren. Über einen Verbindungsserver kann man so manuell mit ein wenig Zeit und Geduld sauber alles in eine neue Datenbank auf einer neuen Hardware übernehmen.
Ggf. müssen dann noch Daten von außerhalb des SQL kopiert übernommen werden, das ist klar. Dann wird die Software mit der Kopie der Daten neu aufgebaut - die alte Hardware wird nicht mehr produktiv eingesetzt.
a) die Verantwortlichen Personen Kenntnis von dem Problem haben und sich der Gewichtigkeit der Situation bewusst sind und das
b) jegliche Rettungsversuche unter der Prämisse stehen, das bei der Datenrettung nur das absolut nötigste am betroffenen System gemacht wird.
Bisher wurde das System ja sogar noch produktiv genutzt, so lese ich das raus. Für mich absolut unverantwortlich, wenn ein Datenverlust mit schweren Konsequenzen einhergeht.
Wenn jetzt eine Kopie der ganzen VM irgendwo auf Dateisystemebene (des VM Storage) oder auf Storage Ebene scheitert, wenn jeglicher Kopierversuch im OS der VM scheitert, dann könnte "der SQL Spezialist" bzw. der Hersteller der Software sehr wohl einen guten Dienst erbringen. Da sich die VM und SQL ja starten lassen könnt ihr einen Defektfreien Server ins Netz stellen und alle SQL Tabellen, Daten, Trigger, Prozeduren, Funktionen, Berechtigungen etc. händisch kopieren. Über einen Verbindungsserver kann man so manuell mit ein wenig Zeit und Geduld sauber alles in eine neue Datenbank auf einer neuen Hardware übernehmen.
Ggf. müssen dann noch Daten von außerhalb des SQL kopiert übernommen werden, das ist klar. Dann wird die Software mit der Kopie der Daten neu aufgebaut - die alte Hardware wird nicht mehr produktiv eingesetzt.
1
Moin @ukulele-7,
ja damit hast du absolut recht, aber das kann eine sehr aufwendige Rettungsmethode werden.
Daher habe ich bisher ja auch nur geschrieben, dass der TO den SQL-Spezialisten nicht mit der Lösung des CRC Fehler unnötig beschäftigen soll, weil er hierbei nicht wirklich helfen kann.
Wenn der Defekt auf den übergeordneten Storage-Ebenen jedoch irreparabel ist, dann bleibt das was du beschrieben hast, eh als Einziges noch übrig.
Gruss Alex
dann könnte "der SQL Spezialist" bzw. der Hersteller der Software sehr wohl einen guten Dienst erbringen. Da sich die VM und SQL ja starten lassen könnt ihr einen Defektfreien Server ins Netz stellen und alle SQL Tabellen, Daten, Trigger, Prozeduren, Funktionen, Berechtigungen etc. händisch kopieren. Über einen Verbindungsserver kann man so manuell mit ein wenig Zeit und Geduld sauber alles in eine neue Datenbank auf einer neuen Hardware übernehmen.
Ggf. müssen dann noch Daten von außerhalb des SQL kopiert übernommen werden, das ist klar. Dann wird die Software mit der Kopie der Daten neu aufgebaut - die alte Hardware wird nicht mehr produktiv eingesetzt.
Ggf. müssen dann noch Daten von außerhalb des SQL kopiert übernommen werden, das ist klar. Dann wird die Software mit der Kopie der Daten neu aufgebaut - die alte Hardware wird nicht mehr produktiv eingesetzt.
ja damit hast du absolut recht, aber das kann eine sehr aufwendige Rettungsmethode werden.
Daher habe ich bisher ja auch nur geschrieben, dass der TO den SQL-Spezialisten nicht mit der Lösung des CRC Fehler unnötig beschäftigen soll, weil er hierbei nicht wirklich helfen kann.
Wenn der Defekt auf den übergeordneten Storage-Ebenen jedoch irreparabel ist, dann bleibt das was du beschrieben hast, eh als Einziges noch übrig.
Gruss Alex
Mahlzeit Yan,
hast du mal einen Skript-Export der Datenbank getestet?
Damit könntest du wenigstens die Inhalte in Sicherheit bringen, falls der Export funktioniert. Es scheint ja, dass sich die Daten lesen lassen.
https://docs.telerik.com/devtools/aspnet-ajax/knowledge-base/common-impo ...
In jedem Fall scheint es ja so, als ob euer RAID eine Macke abbekommen hat - da würde ich mittelfristig einen Neuaufbau des RAID-Volumes empfehlen, bei darunterliegenden Hardwaredefekten wie in eurem Fall kann es sonst sein, dass du weitere Probleme in ähnlicher Form mitschleppst, die erst später auffallen.
Viele Grüße
mxrecord
hast du mal einen Skript-Export der Datenbank getestet?
Damit könntest du wenigstens die Inhalte in Sicherheit bringen, falls der Export funktioniert. Es scheint ja, dass sich die Daten lesen lassen.
https://docs.telerik.com/devtools/aspnet-ajax/knowledge-base/common-impo ...
In jedem Fall scheint es ja so, als ob euer RAID eine Macke abbekommen hat - da würde ich mittelfristig einen Neuaufbau des RAID-Volumes empfehlen, bei darunterliegenden Hardwaredefekten wie in eurem Fall kann es sonst sein, dass du weitere Probleme in ähnlicher Form mitschleppst, die erst später auffallen.
Viele Grüße
mxrecord
Es ist sehr ruhig geworden hier.
Entweder ist das "Kind nun in den Brunnen gefallen", oder unsere guten Ratschläge sind zu nervig geworden.
Entweder ist das "Kind nun in den Brunnen gefallen", oder unsere guten Ratschläge sind zu nervig geworden.
2
Moin @Roland567,
das Kind war glaube ich schon im Brunnen, noch bevor der TO diesen Beitrag geschrieben hat.
Die spannende Frage ist daher eher, ob der TO das Kind wenigstens halbwegs heil wieder herausbekommen hat. 😔
Gruss Alex
Entweder ist das "Kind nun in den Brunnen gefallen"
das Kind war glaube ich schon im Brunnen, noch bevor der TO diesen Beitrag geschrieben hat.
Die spannende Frage ist daher eher, ob der TO das Kind wenigstens halbwegs heil wieder herausbekommen hat. 😔
Gruss Alex
Hallo liebe Admins,
ja, es war sehr ruhig hier.
Das lag an Urlauben beim IT-Dienstleister, bei unserer GF und an Zeiten, während denen sich 2 Dienstleister gegenseitig beschuldigt haben, verantwortlich zu sein.
Fakt ist, dass unsere GF den IT-Dienstleister nun angeschrieben und um schnellstmögliche Behebung des Problems gebeten hat, da wir ja nun seit Monaten keine funktionierende Sicherung dieser SQL-Datenbank mehr haben.
Dann kam die Antwort des IT-Dienstleisters:
Er schreibt, dass die Server-Hardware nicht durch ihn beschafft worden sei und dass diese keinen
Herstellersupport mehr habe. Weiterhin habe diese Hardware keine funktionierenden Management-Schnittstellen und könne somit nicht melden, wenn es Probleme gebe. Daher wäre der Vorwurf, der Defekt hätte vorher erkannt werden müssen, nicht haltbar.
Er schreibt auch, dass die Software, deren Daten in dieser SQL-Datenbank liegen, nicht von ihnen installiert worden sei und dass es auch keine Abmachung gebe, dass er (der IT-Dienstleister) diese Software betreue. Bei Individualsoftware sei der Kunde angehalten entsprechende Abkommen / Supportverträge mit den Herstellern dieser Software abzuschließen... so schreibt er weiterhin.
Nochmal meine Meinung dazu und ein paar Anmerkungen:
Also ich muss dazu nochmal wiederholen, dass der IT-Dienstleister meiner Meinung nach doch verantwortlich dafür ist, wenn auf einem virtuellen Server, den er betreut, die tägliche Sicherung seit langer Zeit nicht mehr funktioniert... oder? Er muss doch kontrollieren, ob diese Sicherungen auch korrekt durchgeführt wurden.
Und ich denke auch, dass hier wohl kaum der Hersteller der Software in die Verantwortung genommen werden kann, der das Programm erstellt hat, dessen Daten in dieser SQL-Datenbank liegen. Ich finde diese Denkweise sehr schräg und übrigens der Hersteller dieser Software ebenso.
Wie seht Ihr das?
Für mich fühlt es sich im Moment so an, dass der IT-Dienstleister sich hier rausreden will und jede Verantwortung abwälzen will... verrückter Weise auf den Hersteller der Software und offenbar auch auf uns.
Aber für was hat man dann einen IT-Dienstleister, wenn man sich nicht darauf verlassen kann, dass die täglichen Sicherungen auch funktionieren, auf die man sich ja verlässt. Für diese Sicherheit holt man sich ja einen IT-Dienstleister.
Grüße von
Yan
ja, es war sehr ruhig hier.
Das lag an Urlauben beim IT-Dienstleister, bei unserer GF und an Zeiten, während denen sich 2 Dienstleister gegenseitig beschuldigt haben, verantwortlich zu sein.
Fakt ist, dass unsere GF den IT-Dienstleister nun angeschrieben und um schnellstmögliche Behebung des Problems gebeten hat, da wir ja nun seit Monaten keine funktionierende Sicherung dieser SQL-Datenbank mehr haben.
Dann kam die Antwort des IT-Dienstleisters:
Er schreibt, dass die Server-Hardware nicht durch ihn beschafft worden sei und dass diese keinen
Herstellersupport mehr habe. Weiterhin habe diese Hardware keine funktionierenden Management-Schnittstellen und könne somit nicht melden, wenn es Probleme gebe. Daher wäre der Vorwurf, der Defekt hätte vorher erkannt werden müssen, nicht haltbar.
Er schreibt auch, dass die Software, deren Daten in dieser SQL-Datenbank liegen, nicht von ihnen installiert worden sei und dass es auch keine Abmachung gebe, dass er (der IT-Dienstleister) diese Software betreue. Bei Individualsoftware sei der Kunde angehalten entsprechende Abkommen / Supportverträge mit den Herstellern dieser Software abzuschließen... so schreibt er weiterhin.
Nochmal meine Meinung dazu und ein paar Anmerkungen:
Also ich muss dazu nochmal wiederholen, dass der IT-Dienstleister meiner Meinung nach doch verantwortlich dafür ist, wenn auf einem virtuellen Server, den er betreut, die tägliche Sicherung seit langer Zeit nicht mehr funktioniert... oder? Er muss doch kontrollieren, ob diese Sicherungen auch korrekt durchgeführt wurden.
Und ich denke auch, dass hier wohl kaum der Hersteller der Software in die Verantwortung genommen werden kann, der das Programm erstellt hat, dessen Daten in dieser SQL-Datenbank liegen. Ich finde diese Denkweise sehr schräg und übrigens der Hersteller dieser Software ebenso.
Wie seht Ihr das?
Für mich fühlt es sich im Moment so an, dass der IT-Dienstleister sich hier rausreden will und jede Verantwortung abwälzen will... verrückter Weise auf den Hersteller der Software und offenbar auch auf uns.
Aber für was hat man dann einen IT-Dienstleister, wenn man sich nicht darauf verlassen kann, dass die täglichen Sicherungen auch funktionieren, auf die man sich ja verlässt. Für diese Sicherheit holt man sich ja einen IT-Dienstleister.
Grüße von
Yan
1
Das können wir nicht beurteilen, ohne euren Dienstleistungsvertrag zu kennen. Grundsätzlich wäre da eher beim IT-Dienstleister, weil es vermutlich keinen wirklichen Vertrag gibt sondern immer nur Aufträge dies oder das umzusetzen, aber nicht, regelmäßige Backups aller VMs durchzuführen und das zu überwachen.
Du kannst ja nicht beim Dienstleister einen Server bestellen, dir das einrichten lassen und dann kommt eine Software, die du oder ein anderer Anbieter installierst und wo du keine Datensicherung für einrichtest (oder diese nicht kontrollierst / testest) und dem IT-Dienstleister soll das dann auffallen.
Man könnte ihm jetzt höchstens eine Art Fahrlässigkeit unterstellen, wenn er einen Server ausliefert und keine Maßnahmen trifft, die dich bei z.B. Hardware-Fehlern (z.B. SMART) oder CRC Fehlern benachrichtigt oder wenn der RAID irgendwie falsch konfiguriert war. Aber viel Spaß das juristisch als Fahrlässigkeit nachzuweisen.
Verantwortlich für den Geschäftsbetrieb ist die Geschäftsführung. Verantwortung kann man vertraglich deligieren.
Du kannst ja nicht beim Dienstleister einen Server bestellen, dir das einrichten lassen und dann kommt eine Software, die du oder ein anderer Anbieter installierst und wo du keine Datensicherung für einrichtest (oder diese nicht kontrollierst / testest) und dem IT-Dienstleister soll das dann auffallen.
Man könnte ihm jetzt höchstens eine Art Fahrlässigkeit unterstellen, wenn er einen Server ausliefert und keine Maßnahmen trifft, die dich bei z.B. Hardware-Fehlern (z.B. SMART) oder CRC Fehlern benachrichtigt oder wenn der RAID irgendwie falsch konfiguriert war. Aber viel Spaß das juristisch als Fahrlässigkeit nachzuweisen.
Verantwortlich für den Geschäftsbetrieb ist die Geschäftsführung. Verantwortung kann man vertraglich deligieren.
ihr habt doch einen Vertrag - den einfach mal lesen und/oder prüfen lassen. Denn ganz ehrlich - wie sollte euer Dienstleister zB. meine Software sichern - bei der er ja gar nicht wissen KANN wie die funktioniert (da es eben auch individual-software ist)? Der könnte höchstens die komplette VM sichern, aber nicht den Inhalt.
Andersrum kannst du in nem Vertrag auch reinschreiben das der alle 4 Wochen rumkommt und den Serverraum ausfegt und mal feucht über die Geräte wischt. Gegen Einwurf von Münzen und Scheinen wird der dir dann jemanden schicken der das macht. Und wenn du noch mehr Münzen und Scheine einwirfst wird der auch glücklich sein sich mit euren Software-Dienstleistern zu unterhalten und die Sicherung übernehmen.
DAFÜR habt ihr ja mal nen Vertrag gemacht - und da sollte drin stehen was der zu tun (und ggf. zu lassen) hat. Da braucht es keine "Meinung" für. Wenn du meine Meinung wissen willst: Er macht das korrekt zu sagen das er für individuelle Software, für Hardware die er nich geliefert hat,... nicht verantwortlich ist. Und warum sollte der nen Backup prüfen wenns nicht SEINE Systeme sind? DAS ist eben der Unterschied zwischen "eigenen Leuten" und "Dienstleister": Die EIGENEN Leute können auch mal rund-rum gucken aber sind eben bei Urlaub auch nicht da... Der Dienstleister ist prinzipiell immer verfügbar (ist nicht dein Problem wie der das löst) ABER hat eben dafür genau festgelegte Aufgaben. Wie würdest du denn reagieren wenn der morgen ne Rechnung übern Zaun wirft für 5000 Euro weil der Azubi dort grad mal gedacht hat das der Bildschirmhintergrund ja doof aussieht und das einfach mal gemacht hat? Soll der nicht? Nun - wenn im Vertrag nicht drin steht "Backup für Software xyz prüfen" sollte der das ja auch nicht.
Andersrum kannst du in nem Vertrag auch reinschreiben das der alle 4 Wochen rumkommt und den Serverraum ausfegt und mal feucht über die Geräte wischt. Gegen Einwurf von Münzen und Scheinen wird der dir dann jemanden schicken der das macht. Und wenn du noch mehr Münzen und Scheine einwirfst wird der auch glücklich sein sich mit euren Software-Dienstleistern zu unterhalten und die Sicherung übernehmen.
DAFÜR habt ihr ja mal nen Vertrag gemacht - und da sollte drin stehen was der zu tun (und ggf. zu lassen) hat. Da braucht es keine "Meinung" für. Wenn du meine Meinung wissen willst: Er macht das korrekt zu sagen das er für individuelle Software, für Hardware die er nich geliefert hat,... nicht verantwortlich ist. Und warum sollte der nen Backup prüfen wenns nicht SEINE Systeme sind? DAS ist eben der Unterschied zwischen "eigenen Leuten" und "Dienstleister": Die EIGENEN Leute können auch mal rund-rum gucken aber sind eben bei Urlaub auch nicht da... Der Dienstleister ist prinzipiell immer verfügbar (ist nicht dein Problem wie der das löst) ABER hat eben dafür genau festgelegte Aufgaben. Wie würdest du denn reagieren wenn der morgen ne Rechnung übern Zaun wirft für 5000 Euro weil der Azubi dort grad mal gedacht hat das der Bildschirmhintergrund ja doof aussieht und das einfach mal gemacht hat? Soll der nicht? Nun - wenn im Vertrag nicht drin steht "Backup für Software xyz prüfen" sollte der das ja auch nicht.
Moin,
Sehe das wie @ukulele-7
Können wir nicht beurteilen:
Wir haben u.a. Einen DL, den wir explizit für die Kontrolle der DaSi beauftragt haben, wenngleich wir selbst mit drüber schauen. Aber 4 Augen sehen mehr, als 2 und wir können den wegen allen DaSi-Themen „nerven“.
Darüber hinaus hat unser ERP-Hersteller noch Jobs für die Sicherung des SQLs hinterlegt. Hat im Wartungsvertrag aber festgelegt, dass die grundsätzliche Sicherung der Daten in der Verantwortung des Kunden liegt.
Sehe das wie @ukulele-7
Können wir nicht beurteilen:
Aber für was hat man dann einen IT-Dienstleister, wenn man sich nicht darauf verlassen kann, dass die täglichen Sicherungen auch funktionieren, auf die man sich ja verlässt.
Der IT-Dienstleister macht genau das, für das ihr ihn (vertraglich) beauftragt habt. Wenn ihr den nur für „onDemand“ Einsätze bestellt habt, macht er auch nur das. Wenn da auch die DaSi vertraglich reguliert ist, dann hättet ihr einen Ansatz.Wir haben u.a. Einen DL, den wir explizit für die Kontrolle der DaSi beauftragt haben, wenngleich wir selbst mit drüber schauen. Aber 4 Augen sehen mehr, als 2 und wir können den wegen allen DaSi-Themen „nerven“.
Darüber hinaus hat unser ERP-Hersteller noch Jobs für die Sicherung des SQLs hinterlegt. Hat im Wartungsvertrag aber festgelegt, dass die grundsätzliche Sicherung der Daten in der Verantwortung des Kunden liegt.
...danke Euch für die Hinweise.
Nun ja. Der IT-Dienstleister hat ja ein Monitoring-System installiert, mit welchem er die Server überwacht.
Und er hat auch tägliche Sicherungen über "Altaro" eingerichtet, worüber alle Server täglich gesichert werden.
Wie passt es dann zusammen, dass er sich hier nicht verantwortlich dafür fühlt, wenn auf einem dieser von ihm überwachten Server eine der Sicherungen nicht mehr funktioniert, da das Dateisystem des virtuellen Servers durch einen Defekt von physischen Serverplatten beschädigt wurde?
Das kann ich jedenfalls nur schwer nachvollziehen.
Wer sonst müsste das kontrollieren? Vor allem, da er ja diese täglichen Sicherungen mit "Altaro" eingerichtet hat und nicht jemand von Uns.
Grüße von
Yan
Nun ja. Der IT-Dienstleister hat ja ein Monitoring-System installiert, mit welchem er die Server überwacht.
Und er hat auch tägliche Sicherungen über "Altaro" eingerichtet, worüber alle Server täglich gesichert werden.
Wie passt es dann zusammen, dass er sich hier nicht verantwortlich dafür fühlt, wenn auf einem dieser von ihm überwachten Server eine der Sicherungen nicht mehr funktioniert, da das Dateisystem des virtuellen Servers durch einen Defekt von physischen Serverplatten beschädigt wurde?
Das kann ich jedenfalls nur schwer nachvollziehen.
Wer sonst müsste das kontrollieren? Vor allem, da er ja diese täglichen Sicherungen mit "Altaro" eingerichtet hat und nicht jemand von Uns.
Grüße von
Yan
Zitat von @Yan2021:
Der IT-Dienstleister hat ja ein Monitoring-System installiert, mit welchem er die Server überwacht.
Und was genau überwacht das Monitoring bzw. was genau wurde nicht überwacht, steht aber in dem Angebot oder dem Vertrag zum Monitoring System? Von wo genau kommt jetzt der Fehler, defekte Platte, defekter Controller, Konfigurationsfehler?Der IT-Dienstleister hat ja ein Monitoring-System installiert, mit welchem er die Server überwacht.
Zitat von @Yan2021:
Und er hat auch tägliche Sicherungen über "Altaro" eingerichtet, worüber alle Server täglich gesichert werden.
Ich meine mich zu erinnern das hier Eingangs davon die Rede war das es keine Sicherung gibt. Das passt nicht zusammen.Und er hat auch tägliche Sicherungen über "Altaro" eingerichtet, worüber alle Server täglich gesichert werden.
Insgesamt schilderst du den Sachverhalt nur grob, nicht im Detail. Wenn es hier wirklich ein Versagen bzw. eine Vertragsverletzung seitens des DL gibt dann kann das am Ende sowieso ein Anwalt aufbereiten, und nicht ein Forum. Dann mahnt euren DL an und stellt ihm eine Schadenersatzforderung. Wenn der das anders sieht, wird das in einem Verfahren entschieden.
Nun - es ist das eine was der ggf. installiert hat -> monitoring, backup, remote-hands, god-mode,.... Und das andere was im Vertrag STEHT was er machen muss. Es ist doch am Ende ganz einfach: Du hast doch auch mit deiner Firma nen Vertrag geschlossen -> da drin steht am Ende das du denen so um 40h Arbeit/Woche schuldest und die dir am Ende des Monats dafür X Euro geben. Wenn du jetzt zB. Morgens den Kaffee kochst weil du der erste im Office bist dann ist das Nett das du das tust - dennoch würdest du vermutlich mit deinem Chef diskutieren müssen wenn der dein Gehalt kürzt weil du 2x im Monat den Kaffee eben NICHT gekocht hast. Und du würdest vermutlich auch deinen Vertrag, Arbeitsplatzbeschreibung usw. holen (und vermutlich steht Kaffeekochen nicht drin). Du machst es ggf. weil es deinen Job auch einfacher macht (wäre ja blöd zu warten bis irgendwer kommt um das zu tun und so lang keinen Kaffee zu haben), du machst es ggf. aus freundlichkeit -> aber du würdest eben auch nicht zwingend daraus ableiten das es zu deiner Arbeit gehört, oder?
Warum sollte also ein Dienstleister anders arbeiten? Solang ihr damit einverstanden seid das der zB. Monitoring mit macht (habt ihr ja auch ggf. was von) - schön... macht auch seine Arbeit ggf. leichter. Aber im VERTRAG wird halt geregelt was er machen muss, nicht daraus was der nebenbei noch gratis dazu gibt.
Warum sollte also ein Dienstleister anders arbeiten? Solang ihr damit einverstanden seid das der zB. Monitoring mit macht (habt ihr ja auch ggf. was von) - schön... macht auch seine Arbeit ggf. leichter. Aber im VERTRAG wird halt geregelt was er machen muss, nicht daraus was der nebenbei noch gratis dazu gibt.
@ukulele-7:
Du wirfst hier etwas durcheinander.
Ja, es gibt keine Sicherung... aber damit ist die Sicherung der SQL-Datenbank gemeint, die seit Wochen nicht mehr funktioniert. Grundsätzlich gab es diese Sicherungen ja. Und zwar hat der IT-Dienstleister es so eingerichtet, dass über das Programm "Altaro" täglich ein Backup sämtlicher Server erstellt wird. Das hat der IT-Dienstleister gemacht und nicht wir und natürlich war er dazu auch beauftragt.
@maretz:
Ich verstehe das nicht!!
Wenn ich als IT-Dienstleister für einen Kunden eine Sicherung einrichte und gleichzeitig die Server überwache... gehört es dann nicht auch zu meinen Aufgaben als IT-Dienstleister, zu checken, ob diese Sicherungen überhaupt funktionieren? Ich denke schon!!
Hier war es so, dass es einen Defekt an mehreren physischen Server-Festplatten gab. Dieser Defekt ist dem IT-Dienstleister nicht aufgefallen, obwohl er ja ein Monitoring-System installiert hat. Er schiebt es jetzt darauf, dass wir ja noch veraltete Hardwäre einsetzen würden, die ihm nicht solche Fehler zurückmeldet... naja... kann ich nicht beurteilen.
Und dann ist - angeblich durch diesen Defekt an den physischen Festplatten, auch die virtuelle Festplatte des Servers beschädigt worden, auf dem die SQL-Datenbanken liegen. Das hat dann die Abbrüche beim Backup der SQL-Datenbank verursacht, was noch immer nicht behoben ist.
Auch hier sage ich, dass es dem IT-Dienstleister m.E. doch hätte auffallen müssen, dass diese Sicherungen schon über einen Zeitraum von mehreren Wochen!!! überhaupt nicht mehr funktioniert haben. ER überwacht per Monitoring unsere Server und auch die Backups.
Noch verrückter ist für mich jedoch die Tatsache, dass der IT-Dienstleister nun den Hersteller der Software in der Pflicht sieht, den Fehler zu beheben. Damit ist die Software gemeint, deren Daten in dieser SQL-Datenbank liegen. Da kann ich nur sagen......... hallooooooooo?
Was hat der Software-Hersteller mit unserer Datenbank-Sicherung zu tun und wieso soll er für einen Defekt an unserer SQL-Datenbank verantwortlich sein und nun eine Lösung finden? Das ist doch Sache unseres IT-Dienstleisters... oder?
Vielleicht ist das Ganze jetzt etwas klarer geworden.
Ich hoffe nur, dass wir bald eine Lösung finden.
Grüße von
Yan
Du wirfst hier etwas durcheinander.
Ja, es gibt keine Sicherung... aber damit ist die Sicherung der SQL-Datenbank gemeint, die seit Wochen nicht mehr funktioniert. Grundsätzlich gab es diese Sicherungen ja. Und zwar hat der IT-Dienstleister es so eingerichtet, dass über das Programm "Altaro" täglich ein Backup sämtlicher Server erstellt wird. Das hat der IT-Dienstleister gemacht und nicht wir und natürlich war er dazu auch beauftragt.
@maretz:
Ich verstehe das nicht!!
Wenn ich als IT-Dienstleister für einen Kunden eine Sicherung einrichte und gleichzeitig die Server überwache... gehört es dann nicht auch zu meinen Aufgaben als IT-Dienstleister, zu checken, ob diese Sicherungen überhaupt funktionieren? Ich denke schon!!
Hier war es so, dass es einen Defekt an mehreren physischen Server-Festplatten gab. Dieser Defekt ist dem IT-Dienstleister nicht aufgefallen, obwohl er ja ein Monitoring-System installiert hat. Er schiebt es jetzt darauf, dass wir ja noch veraltete Hardwäre einsetzen würden, die ihm nicht solche Fehler zurückmeldet... naja... kann ich nicht beurteilen.
Und dann ist - angeblich durch diesen Defekt an den physischen Festplatten, auch die virtuelle Festplatte des Servers beschädigt worden, auf dem die SQL-Datenbanken liegen. Das hat dann die Abbrüche beim Backup der SQL-Datenbank verursacht, was noch immer nicht behoben ist.
Auch hier sage ich, dass es dem IT-Dienstleister m.E. doch hätte auffallen müssen, dass diese Sicherungen schon über einen Zeitraum von mehreren Wochen!!! überhaupt nicht mehr funktioniert haben. ER überwacht per Monitoring unsere Server und auch die Backups.
Noch verrückter ist für mich jedoch die Tatsache, dass der IT-Dienstleister nun den Hersteller der Software in der Pflicht sieht, den Fehler zu beheben. Damit ist die Software gemeint, deren Daten in dieser SQL-Datenbank liegen. Da kann ich nur sagen......... hallooooooooo?
Was hat der Software-Hersteller mit unserer Datenbank-Sicherung zu tun und wieso soll er für einen Defekt an unserer SQL-Datenbank verantwortlich sein und nun eine Lösung finden? Das ist doch Sache unseres IT-Dienstleisters... oder?
Vielleicht ist das Ganze jetzt etwas klarer geworden.
Ich hoffe nur, dass wir bald eine Lösung finden.
Grüße von
Yan
Moin,
Warum beantwortet ihr beide nicht einfach die Frage, was im gegenseitig unterzeichneten Wartungsvertrag vereinbart wurde?
Wenn es keinen Wartungsvertrag gibt, wird auch vermutlich kein Anwalt der Welt dem DL den Peter zuschieben, da es keinerlei Geschäftsgrundlage gibt.
Und vielleicht hat der DL euch ja auch damals schon per Mail hingewiesen, dass er nur im gewissen Rahmen die Systeme überwacht/ überwachen kann, weil ihr, als Kunde einen Wartungsstau habt und den nicht angegangen seid.
Und bei unserem DL für die DaSi ist auch geregelt, dass er sich (im Rahmen von Veeam) auf die Sicherung der Systeme konzentriert, aber auch Datenbanken, das AD und den Exchange entsprechend berücksichtigt. Für die Sicherung der einzelnen Anwendungen sind wir aber verantwortlich. Und das haben wir teilweise an die Hersteller „abgetreten“, zumindest in sofern, dass die uns sagen müssen, wie die Anwendungen zu sichern sind. Und zwar so, dass auch ein fehlerfreies Recovery möglich ist.
Aber all das ist einseitig geregelt. Macht einer der Vertragsparteien mehr, ist das good will.
Also noch Mals die Frage:
Was habt ihr mit den Partnern/ dem Partner vertraglich vereinbart?
Warum beantwortet ihr beide nicht einfach die Frage, was im gegenseitig unterzeichneten Wartungsvertrag vereinbart wurde?
Wenn es keinen Wartungsvertrag gibt, wird auch vermutlich kein Anwalt der Welt dem DL den Peter zuschieben, da es keinerlei Geschäftsgrundlage gibt.
Und vielleicht hat der DL euch ja auch damals schon per Mail hingewiesen, dass er nur im gewissen Rahmen die Systeme überwacht/ überwachen kann, weil ihr, als Kunde einen Wartungsstau habt und den nicht angegangen seid.
Und bei unserem DL für die DaSi ist auch geregelt, dass er sich (im Rahmen von Veeam) auf die Sicherung der Systeme konzentriert, aber auch Datenbanken, das AD und den Exchange entsprechend berücksichtigt. Für die Sicherung der einzelnen Anwendungen sind wir aber verantwortlich. Und das haben wir teilweise an die Hersteller „abgetreten“, zumindest in sofern, dass die uns sagen müssen, wie die Anwendungen zu sichern sind. Und zwar so, dass auch ein fehlerfreies Recovery möglich ist.
Aber all das ist einseitig geregelt. Macht einer der Vertragsparteien mehr, ist das good will.
Also noch Mals die Frage:
Was habt ihr mit den Partnern/ dem Partner vertraglich vereinbart?
So deutlich hast du das bisher nicht geschildert; du verwebst aber auch immer noch diverse Umstände mit einander.
1) Datensicherung
Euer DL hatte offensichtlich den Auftrag eine Datensicherung einzurichten und zu überwachen. Damit hat er aus meiner Sicht in dem Punkt versagt. Da ich die Software auch nicht kenne wäre es dann sehr wichtig zu wissen, was hier schief gelaufen ist. Es gibt ein Backup der VM aber die Datenbank in der VM läuft nicht? So ganz klar ist mir das noch nicht.
Eine eigene SQL Sicherung ist nicht zwingend nötig, wohl aber das dann die Backup Software in der Lage ist, SQL Datenbanken application aware zu sichern. Alternativ muss eben eine eigene Sicherung eingerichtet werden. Hier hat vermutlich die Kommunikation versagt, der Datensicherungs DL wusste nichts von der DB. Hätte ihm auffallen sollen aber müssen ist eine andere Frage.
Wie er die Sicherung auf Erfolg prüft ist auch so eine Frage. Die meisten Backup Lösungen prüfen aber so eine Prüfung muss nicht bedeuten, das es zwingend fehlerfrei ist. Rücksicherungstests sind sehr aufwendig aber zu empfehlen. Angenommen, die Backups sind okay und nur die DB in dem Backup nicht und hier wurde nichts konkretes vereinbart, wird es schwer, dem DL das wirklich anzulasten. Er hat nicht gut gearbeitet aber Schuld ist er (vermutlich) nicht allein.
2) Server Monitoring
Wir wissen nicht, welche Software zum Einsatz kommt und mit welchem Ziel die arbeitet. Auch wissen wir nicht, ob es dazu ein Pflichtenheft oder Vertrag gibt, der fest hält, was überwacht wird. Es gibt wahnsinnig viele Parameter die überwacht werden könnten, das wird sicherlich nirgends zu 100% geschehen. Also auch hier stellt sich die Frage, was war der Fehler und hätte er auffallen müssen.
Vom Gefühl her würde ich sagen ja, HDDs sind zu überwachen. Warum ist das nicht geschehen und wer wusste davon? Wollte man die überwachen aber konnte nicht? Wurde das beauftragt? Alles Spekulation, wir kennen die Details nicht. Ein schlechtes Bild gibt der DL auch hier ab weil HDDs nun mal kaputt gehen und man sich dessen sicherlich bewusst ist. Wenn aber das Monitoring nur so ein gratis Service des DL ist und der DL vielleicht wirklich bereits auf Probleme mit der Hardware hingewiesen haben sollte in der Vergangenheit?
3) Der Schaden ist da und seitens der Hardware vermutlich irreparabel. Aus deiner Sicht ist der DL Schuld und daher sollte der das auch fixen - Das ist ein Trugschluss. Wenn er es nicht fixen kann dann muss es jemand tun, der es kann. Da kommt durchaus der Software Hersteller in Frage.
Wenn ein Bagger deine Glasfaser Leitung kappt, dann sitzt auch nicht der Baggerfahrer mit Tesafilm im Loch und klebt das wieder, das geht halt nicht. Du brauchst eine Art Datenrettung oder eine andere Lösung, wer für den Schaden verantwortlich ist und ggf. die Kosten zu tragen hat, ist unabhängig davon.
1) Datensicherung
Euer DL hatte offensichtlich den Auftrag eine Datensicherung einzurichten und zu überwachen. Damit hat er aus meiner Sicht in dem Punkt versagt. Da ich die Software auch nicht kenne wäre es dann sehr wichtig zu wissen, was hier schief gelaufen ist. Es gibt ein Backup der VM aber die Datenbank in der VM läuft nicht? So ganz klar ist mir das noch nicht.
Eine eigene SQL Sicherung ist nicht zwingend nötig, wohl aber das dann die Backup Software in der Lage ist, SQL Datenbanken application aware zu sichern. Alternativ muss eben eine eigene Sicherung eingerichtet werden. Hier hat vermutlich die Kommunikation versagt, der Datensicherungs DL wusste nichts von der DB. Hätte ihm auffallen sollen aber müssen ist eine andere Frage.
Wie er die Sicherung auf Erfolg prüft ist auch so eine Frage. Die meisten Backup Lösungen prüfen aber so eine Prüfung muss nicht bedeuten, das es zwingend fehlerfrei ist. Rücksicherungstests sind sehr aufwendig aber zu empfehlen. Angenommen, die Backups sind okay und nur die DB in dem Backup nicht und hier wurde nichts konkretes vereinbart, wird es schwer, dem DL das wirklich anzulasten. Er hat nicht gut gearbeitet aber Schuld ist er (vermutlich) nicht allein.
2) Server Monitoring
Wir wissen nicht, welche Software zum Einsatz kommt und mit welchem Ziel die arbeitet. Auch wissen wir nicht, ob es dazu ein Pflichtenheft oder Vertrag gibt, der fest hält, was überwacht wird. Es gibt wahnsinnig viele Parameter die überwacht werden könnten, das wird sicherlich nirgends zu 100% geschehen. Also auch hier stellt sich die Frage, was war der Fehler und hätte er auffallen müssen.
Vom Gefühl her würde ich sagen ja, HDDs sind zu überwachen. Warum ist das nicht geschehen und wer wusste davon? Wollte man die überwachen aber konnte nicht? Wurde das beauftragt? Alles Spekulation, wir kennen die Details nicht. Ein schlechtes Bild gibt der DL auch hier ab weil HDDs nun mal kaputt gehen und man sich dessen sicherlich bewusst ist. Wenn aber das Monitoring nur so ein gratis Service des DL ist und der DL vielleicht wirklich bereits auf Probleme mit der Hardware hingewiesen haben sollte in der Vergangenheit?
3) Der Schaden ist da und seitens der Hardware vermutlich irreparabel. Aus deiner Sicht ist der DL Schuld und daher sollte der das auch fixen - Das ist ein Trugschluss. Wenn er es nicht fixen kann dann muss es jemand tun, der es kann. Da kommt durchaus der Software Hersteller in Frage.
Wenn ein Bagger deine Glasfaser Leitung kappt, dann sitzt auch nicht der Baggerfahrer mit Tesafilm im Loch und klebt das wieder, das geht halt nicht. Du brauchst eine Art Datenrettung oder eine andere Lösung, wer für den Schaden verantwortlich ist und ggf. die Kosten zu tragen hat, ist unabhängig davon.
OK und ich danke Euch für die weiteren detaillierten Antworten und Tipps sowie Hinweise.
Ich denke, der Fehler läßt sich in diesem Fall nur schwer Jemandem zuschieben, denn das größte Problem ist, dass unsere vorherige GF keinen detaillierten Vertrag mit dem IT-Dienstleister abgeschlossen hatte.
Da wurde nur das Monitoring vereinbart, sowie Patchmanagement, Virenscanner und eben die täglichen Sicherungen.
Aber eben keine Details darüber, was genau im Einzelnen gemacht werden muss und was nicht.
Nun haben wir den berühmten "Salat" und müssen sehen, wie wir die SQL-DB wieder ans Laufen bekommen.
Den Software-Hersteller sehe ich jedenfalls hier NULL in der Pflicht.
Es handelt sich um keine bekannte Groß-Software, sondern um eine für uns angepaßte Spezialsoftware.
Diese wurde vor vielen Jahren installiert (keine Ahnung von wem damals...) und es wurde dann (von wem auch immer) so eingerichtet, dass die Daten eben in eine SQL-DB laufen, was ja üblich ist.
Für die regelmäßigen Sicherungen kann also dieses Unternehmen ja nun kaum verantwortlich gemacht werden.
Sie betreuen uns nur, wenn es mal Probleme gibt, wenn Updates mal nicht funktionieren etc.
Aber mit den Sicherungen hatten sie nie etwas zu tun... haben im hiesigen Fall aber ja doch mit ihrer Expertise weitergeholfen, was am Ende jedoch nichts gebracht hat bisher.
Nun sagt der IT-Dienstleister jedoch, dass er sich nur als "der verlängerte Arm" sieht und dass er die Lösungspflicht bei diesem Unternehmen sieht, was aus meiner Sicht absolut absurd ist.
Grüße von
Yan
Ich denke, der Fehler läßt sich in diesem Fall nur schwer Jemandem zuschieben, denn das größte Problem ist, dass unsere vorherige GF keinen detaillierten Vertrag mit dem IT-Dienstleister abgeschlossen hatte.
Da wurde nur das Monitoring vereinbart, sowie Patchmanagement, Virenscanner und eben die täglichen Sicherungen.
Aber eben keine Details darüber, was genau im Einzelnen gemacht werden muss und was nicht.
Nun haben wir den berühmten "Salat" und müssen sehen, wie wir die SQL-DB wieder ans Laufen bekommen.
Den Software-Hersteller sehe ich jedenfalls hier NULL in der Pflicht.
Es handelt sich um keine bekannte Groß-Software, sondern um eine für uns angepaßte Spezialsoftware.
Diese wurde vor vielen Jahren installiert (keine Ahnung von wem damals...) und es wurde dann (von wem auch immer) so eingerichtet, dass die Daten eben in eine SQL-DB laufen, was ja üblich ist.
Für die regelmäßigen Sicherungen kann also dieses Unternehmen ja nun kaum verantwortlich gemacht werden.
Sie betreuen uns nur, wenn es mal Probleme gibt, wenn Updates mal nicht funktionieren etc.
Aber mit den Sicherungen hatten sie nie etwas zu tun... haben im hiesigen Fall aber ja doch mit ihrer Expertise weitergeholfen, was am Ende jedoch nichts gebracht hat bisher.
Nun sagt der IT-Dienstleister jedoch, dass er sich nur als "der verlängerte Arm" sieht und dass er die Lösungspflicht bei diesem Unternehmen sieht, was aus meiner Sicht absolut absurd ist.
Grüße von
Yan
Vermutlich will er darauf hinaus das der Software Hersteller einfach eine neue Datenbank auf einem neuen Server aufsetzt und, soweit wie möglich, alle Objekte aus der alten Datenbank händisch übernimmt. Das kann theoretisch jeder mit Zugriff auf die DB aber der Hersteller kennt eben seine Software und weiß, welche Abhängigkeiten in der Datenbank bestehen.
Der Software Hersteller muss das nicht tun und will das vermutlich auch nicht tun. Schlecht wäre das nicht, die Software muss ja zumindest einmal eh neu aufgesetzt werden auf einer neuen, fehlerfreien VM auf idealerweise neuer Hardware. An der Kopie der ganzen Tabellen kannst du dich auch selbst versuchen, von der Sache her ist das erstmal nicht schwer sondern Fleißarbeit. Natürlich kann es Fallstricke geben und da wäre die Unterstützung durch den Hersteller schon sehr sinnvoll.
Das muss ja auch alles in einem entsprechenden Zeitfenster durchgeführt werden. Du willst ja nicht zich Aktuallisierungen nachziehen, das ist so schon viel Arbeit.
Der Software Hersteller muss das nicht tun und will das vermutlich auch nicht tun. Schlecht wäre das nicht, die Software muss ja zumindest einmal eh neu aufgesetzt werden auf einer neuen, fehlerfreien VM auf idealerweise neuer Hardware. An der Kopie der ganzen Tabellen kannst du dich auch selbst versuchen, von der Sache her ist das erstmal nicht schwer sondern Fleißarbeit. Natürlich kann es Fallstricke geben und da wäre die Unterstützung durch den Hersteller schon sehr sinnvoll.
Das muss ja auch alles in einem entsprechenden Zeitfenster durchgeführt werden. Du willst ja nicht zich Aktuallisierungen nachziehen, das ist so schon viel Arbeit.
Nun - es ist aber eben auch einfach: Unabhängig wer jetzt am Ende ggf. wo was hätte tun sollen oder nicht sollen -> es wäre ja ggf. sinnvoll erstmal das Problem selbst zu lösen. Und DA kann dir der SW-Hersteller ja ggf. helfen, GRADE wenns keine "08/15-Stangensoftware" ist. Denn der weiss ja welche Tabellen der wirklich braucht und wo ggf. nur irgendwelche Daten stehen die ggf. nicht mehr sooo relevant sind. Der kann dir auch ggf. nen Script zusammenlöten was dir da helfen kann -> zB. das man irgendwelche Tabellen aus nem uralt-backup ziehen kann (zB. Stammdaten deiner Firma ändern sich ja recht selten, Mitarbeiter-Logins,...) und noch einige so wiederherstellen kann... Natürlich wird so eine Aktion nen halbes Schwein und ne Kuhherde kosten -> ist aber nicht zu ändern. Wenn ihr eben keinen klaren Vertrag habt kann man sich zwar schon vorstellen wer was tun SOLLTE - aber die Vorstellung hat eben nicht zwingend mit der wirklichkeit zu tun...
@ukulele-7:
Danke nochmals für die guten Tipps. Da kann ich einiges von verwerten und habe mir ein paar Dinge davon nun auch notiert für das weitere Vorgehen...
@maretz:
Auch Dir nochmal Danke.
Deine Beschreibung paßt genau. Denn der Software-Hersteller hatte tatsächlich bereits vor 3 Wochen ein Script geschrieben, was er dem IT-Dienstleister übersendet hat, damit er die Datenbank auf einem externen SQL-Server wiederherstellen kann.
Nach einer Woche hat der Software-Hersteller dann mal gefragt, ob schon versucht worden sei, die Datenbank auf einem externen SQL-Server wiederherzustellen... und genau daraufhin kam dann die Antwort des IT-Dienstleisters, dass er das noch nicht versucht habe und dass er die Expertise hier bei ihm (dem Software-Hersteller) sehe. Der IT-Dienstleister selbst sehe sich hier nur als der "verlängerte Arm". Darauf meldete sich dann der Vorstand des Software-Herstellers bei mir mit großem Unverständnis dieser Äußerung gegenüber... was ich auch gut verstehen kann.
Grüße von
Yan
Danke nochmals für die guten Tipps. Da kann ich einiges von verwerten und habe mir ein paar Dinge davon nun auch notiert für das weitere Vorgehen...
@maretz:
Auch Dir nochmal Danke.
Deine Beschreibung paßt genau. Denn der Software-Hersteller hatte tatsächlich bereits vor 3 Wochen ein Script geschrieben, was er dem IT-Dienstleister übersendet hat, damit er die Datenbank auf einem externen SQL-Server wiederherstellen kann.
Nach einer Woche hat der Software-Hersteller dann mal gefragt, ob schon versucht worden sei, die Datenbank auf einem externen SQL-Server wiederherzustellen... und genau daraufhin kam dann die Antwort des IT-Dienstleisters, dass er das noch nicht versucht habe und dass er die Expertise hier bei ihm (dem Software-Hersteller) sehe. Der IT-Dienstleister selbst sehe sich hier nur als der "verlängerte Arm". Darauf meldete sich dann der Vorstand des Software-Herstellers bei mir mit großem Unverständnis dieser Äußerung gegenüber... was ich auch gut verstehen kann.
Grüße von
Yan
So ein SQL Script ist eine feine Sache und eigentlich ist vermutlich nicht wirklich eine Hürde in deiner DB versteckt. Die meisten Software-Lösungen packen die ganze Logik in die Software, nicht in die DB. Vermutlich müssen nur Tabellen und Inhalte kopiert werden, eventuell noch ein DB Benutzer angelegt werden, irgendwas so in der Art.
Aber für jemanden, der bisher noch keine Berührungspunkte mit SQL hatte, ist das eine gewisse Schwelle. So ein kleinerer DL hat dann vielleicht niemanden und der möchte sich jetzt vermutlich auch nicht nochmal die Finger verbrennen, der hat vermutlich Schiss.
Ich würde dir raten, es eventuell selbst zu versuchen. Du schreibst ja nicht in die alte DB, nur in eine neue DB, da kann nicht so viel passieren. Schau dir das Script an, gerne auch per PM an mich. Vom Grundsatz her würde ich es so machen: Neuen Server installieren, Management Studio verbinden, "Linked Server" bzw. "Verbindungsserver auf dem neuen SQL Server anlegen der auf den alten SQL Server zeigt. Dann die Tabellen auf dem alten Server per Rechtsklick CREATE Script holen und gegen das neue System ausführen. Dann kannst du vermutlich mit dem Script den Inhalt kopieren, vielleicht haben die aber sogar die CREATE TABLE Statements schon eingebaut.
Aber für jemanden, der bisher noch keine Berührungspunkte mit SQL hatte, ist das eine gewisse Schwelle. So ein kleinerer DL hat dann vielleicht niemanden und der möchte sich jetzt vermutlich auch nicht nochmal die Finger verbrennen, der hat vermutlich Schiss.
Ich würde dir raten, es eventuell selbst zu versuchen. Du schreibst ja nicht in die alte DB, nur in eine neue DB, da kann nicht so viel passieren. Schau dir das Script an, gerne auch per PM an mich. Vom Grundsatz her würde ich es so machen: Neuen Server installieren, Management Studio verbinden, "Linked Server" bzw. "Verbindungsserver auf dem neuen SQL Server anlegen der auf den alten SQL Server zeigt. Dann die Tabellen auf dem alten Server per Rechtsklick CREATE Script holen und gegen das neue System ausführen. Dann kannst du vermutlich mit dem Script den Inhalt kopieren, vielleicht haben die aber sogar die CREATE TABLE Statements schon eingebaut.
Danke Dir für das nette Angebot @ukulele-7
Der IT-Dienstleister ist ja schon dabei - bzw. hat bereits - versucht, einen neuen SQL-Server anzulegen.
Ich will da jetzt auch nicht dazwischen funken und habe auch keine Ahnung von der Materie.
Ich denke, dass es am Ende darauf hinauslaufen wird, dass der IT-Dienstleister dann doch mit dem Software-Hersteller zusammenarbeiten muss... nur dass wir Letzterem dann den entspr. Aufwand auch bezahlen müssen. Dann sehen wir weiter, ob Daten verloren sind oder nicht.
Grüße von
Yan
Der IT-Dienstleister ist ja schon dabei - bzw. hat bereits - versucht, einen neuen SQL-Server anzulegen.
Ich will da jetzt auch nicht dazwischen funken und habe auch keine Ahnung von der Materie.
Ich denke, dass es am Ende darauf hinauslaufen wird, dass der IT-Dienstleister dann doch mit dem Software-Hersteller zusammenarbeiten muss... nur dass wir Letzterem dann den entspr. Aufwand auch bezahlen müssen. Dann sehen wir weiter, ob Daten verloren sind oder nicht.
Grüße von
Yan
Moin @Yan2021,
wenn eure GF einen Schuldigen haben möchte, dann soll sie sich als aller erstes selber an der Nase ziehen!
Denn gemäss z.B. AktG § 93 oder GmbHG §43 hat in erster Linie die GF die Pflicht sicherzustellen, dass das Unternehmen gegen keine rechtlichen Bestimmungen verstößt, wie z.B. DSGVO Art. 32.
Die Hardware kommt nicht von dem entsprechenden Dienstleister und ist auch schon ausserhalb des Supports und ihr möchtet trotzdem ernsthaft eurem Dienstleister deshalb ans Bein pissen?
Ähm, das ist glaube ich keine gute Idee, weder zwischenmenschlich noch rechtlich. 😔
Die Hardware kommt nicht von dem entsprechenden Dienstleister, die DB und auch die Applikation wurde nicht von ihm aufgesetzt und es gibt auch keine Abmachung, dass er explizit diese Software, mitsupporten muss. Sprich, euer Dienstleister, zumindest der, der nicht für die Software verantwortlich ist, ist dadurch zu 100% aus seiner Verantwortung raus.
So ist das vor allem bei Individualsoftware auch, denn die Software-Hersteller sollten eigentlich am Besten wissen, wie ihre Software richtig zu sichern ist und wie man die Sicherung im Nachgang auch prüfen kann.
Wir helfen so gesehen den Admins unserer Kunden bei der Betreuung von hunderten von Windows VM, jedoch sind wir ganz sicher nicht für jegliche Anwendung die auf diesen installiert wird, auch automatisch mitverantwortlich.
Wurde den der Dienstleister durch irgendeinen Vertrag jemals dazu verpflichtet, die Sicherung auf Funktionalität zu prüfen und habt ihr überhaupt die Ressourcen dazu, die Sicherungen testweise auch mal zurückzuspielen?
Es sind eure Daten die gesichert werden, also müsst ihr in erster Linie auch sicherstellen, dass das Backup ordnungsgemäss läuft und nicht der Dienstleister, der es eventuell nur einrichten sollte.
Diese Denkweise ist nicht schräg sondern eher marktüblich.
Und damit hat er meiner Ansicht nach auch nicht ganz unrecht!
By the Way, ich habe die Hälfte meines IT-Lebens bei Softwarehersteller verbracht. 🙃
Yan, wir IT-Dienstleister sind auch nur Menschen, die meistens auch nur das machen was von uns verlangt wird. Sprich, wenn ihr eurem Dienstleister die Aufgabe gestellt habt, die Backups nicht nur einzurichten, sondern auch zu überwachen und sicherzustellen, dass diese einwandfrei erstellt werden und ihn auch dafür bezahlt habt, dann könnte euer bisheriger DL vielleicht auch etwas Mitschuld haben. Ansonsten sehe ich bisher keinen Anhaltspunkt dafür, dass er irgendetwas falsch gemacht hat.
OK und was genau wird mit diesem Monitoring überwacht, ist das vertraglich irgendwie geregelt?
Einrichtung ist nicht gleich Dauerbetreuung!
Weil das Monitoring wahrscheinlich das Backup nicht umfasst, sondern eher so Dinge wie vollgelaufenen Festplatten und den RAID-Defekt hätte es mit einer sehr hohen Wahrscheinlichkeit im Vorfeld auch nicht erkennen können, da das nicht ganz so einfach ist.
Ganz einfach, ihr selbst und dazu seid ihr im Sinne der Prüfplicht auch gesetzlich verpflichtet!
Übrigens gilt dies auch dann, wenn die entsprechende Leistung vollständig outgesourct ist, denn die Prüfplicht des Unternehmers/der GL selbst, lässt sich nicht wirklich outsourcen.
Ausserdem sollte im eigenen Interesse selbst wissen wie euere Backups funktioniert, vor allem bei einem kleinen Dienstleister, der auch mal länger krankwerden oder gar vollständig ausfallen kann.
Gruss Alex
Das lag an Urlauben beim IT-Dienstleister, bei unserer GF und an Zeiten, während denen sich 2 Dienstleister gegenseitig beschuldigt haben, verantwortlich zu sein.
wenn eure GF einen Schuldigen haben möchte, dann soll sie sich als aller erstes selber an der Nase ziehen!
Denn gemäss z.B. AktG § 93 oder GmbHG §43 hat in erster Linie die GF die Pflicht sicherzustellen, dass das Unternehmen gegen keine rechtlichen Bestimmungen verstößt, wie z.B. DSGVO Art. 32.
Er schreibt, dass die Server-Hardware nicht durch ihn beschafft worden sei und dass diese keinen
Herstellersupport mehr habe. Weiterhin habe diese Hardware keine funktionierenden Management-Schnittstellen und könne somit nicht melden, wenn es Probleme gebe. Daher wäre der Vorwurf, der Defekt hätte vorher erkannt werden müssen, nicht haltbar.
Herstellersupport mehr habe. Weiterhin habe diese Hardware keine funktionierenden Management-Schnittstellen und könne somit nicht melden, wenn es Probleme gebe. Daher wäre der Vorwurf, der Defekt hätte vorher erkannt werden müssen, nicht haltbar.
Die Hardware kommt nicht von dem entsprechenden Dienstleister und ist auch schon ausserhalb des Supports und ihr möchtet trotzdem ernsthaft eurem Dienstleister deshalb ans Bein pissen?
Ähm, das ist glaube ich keine gute Idee, weder zwischenmenschlich noch rechtlich. 😔
Er schreibt auch, dass die Software, deren Daten in dieser SQL-Datenbank liegen, nicht von ihnen installiert worden sei und dass es auch keine Abmachung gebe, dass er (der IT-Dienstleister) diese Software betreue.
Die Hardware kommt nicht von dem entsprechenden Dienstleister, die DB und auch die Applikation wurde nicht von ihm aufgesetzt und es gibt auch keine Abmachung, dass er explizit diese Software, mitsupporten muss. Sprich, euer Dienstleister, zumindest der, der nicht für die Software verantwortlich ist, ist dadurch zu 100% aus seiner Verantwortung raus.
Bei Individualsoftware sei der Kunde angehalten entsprechende Abkommen / Supportverträge mit den Herstellern dieser Software abzuschließen...
So ist das vor allem bei Individualsoftware auch, denn die Software-Hersteller sollten eigentlich am Besten wissen, wie ihre Software richtig zu sichern ist und wie man die Sicherung im Nachgang auch prüfen kann.
Also ich muss dazu nochmal wiederholen, dass der IT-Dienstleister meiner Meinung nach doch verantwortlich dafür ist, wenn auf einem virtuellen Server, den er betreut, die tägliche Sicherung seit langer Zeit nicht mehr funktioniert... oder?
Wir helfen so gesehen den Admins unserer Kunden bei der Betreuung von hunderten von Windows VM, jedoch sind wir ganz sicher nicht für jegliche Anwendung die auf diesen installiert wird, auch automatisch mitverantwortlich.
die tägliche Sicherung seit langer Zeit nicht mehr funktioniert... oder?
Wurde den der Dienstleister durch irgendeinen Vertrag jemals dazu verpflichtet, die Sicherung auf Funktionalität zu prüfen und habt ihr überhaupt die Ressourcen dazu, die Sicherungen testweise auch mal zurückzuspielen?
Er muss doch kontrollieren, ob diese Sicherungen auch korrekt durchgeführt wurden.
Es sind eure Daten die gesichert werden, also müsst ihr in erster Linie auch sicherstellen, dass das Backup ordnungsgemäss läuft und nicht der Dienstleister, der es eventuell nur einrichten sollte.
Und ich denke auch, dass hier wohl kaum der Hersteller der Software in die Verantwortung genommen werden kann, der das Programm erstellt hat, dessen Daten in dieser SQL-Datenbank liegen. Ich finde diese Denkweise sehr schräg und übrigens der Hersteller dieser Software ebenso.
Diese Denkweise ist nicht schräg sondern eher marktüblich.
Für mich fühlt es sich im Moment so an, dass der IT-Dienstleister sich hier rausreden will und jede Verantwortung abwälzen will... verrückter Weise auf den Hersteller der Software und offenbar auch auf uns.
Und damit hat er meiner Ansicht nach auch nicht ganz unrecht!
By the Way, ich habe die Hälfte meines IT-Lebens bei Softwarehersteller verbracht. 🙃
Aber für was hat man dann einen IT-Dienstleister, wenn man sich nicht darauf verlassen kann, dass die täglichen Sicherungen auch funktionieren, auf die man sich ja verlässt. Für diese Sicherheit holt man sich ja einen IT-Dienstleister.
Yan, wir IT-Dienstleister sind auch nur Menschen, die meistens auch nur das machen was von uns verlangt wird. Sprich, wenn ihr eurem Dienstleister die Aufgabe gestellt habt, die Backups nicht nur einzurichten, sondern auch zu überwachen und sicherzustellen, dass diese einwandfrei erstellt werden und ihn auch dafür bezahlt habt, dann könnte euer bisheriger DL vielleicht auch etwas Mitschuld haben. Ansonsten sehe ich bisher keinen Anhaltspunkt dafür, dass er irgendetwas falsch gemacht hat.
Nun ja. Der IT-Dienstleister hat ja ein Monitoring-System installiert, mit welchem er die Server überwacht.
OK und was genau wird mit diesem Monitoring überwacht, ist das vertraglich irgendwie geregelt?
Und er hat auch tägliche Sicherungen über "Altaro" eingerichtet, worüber alle Server täglich gesichert werden.
Einrichtung ist nicht gleich Dauerbetreuung!
Wie passt es dann zusammen, dass er sich hier nicht verantwortlich dafür fühlt, wenn auf einem dieser von ihm überwachten Server eine der Sicherungen nicht mehr funktioniert, da das Dateisystem des virtuellen Servers durch einen Defekt von physischen Serverplatten beschädigt wurde?
Weil das Monitoring wahrscheinlich das Backup nicht umfasst, sondern eher so Dinge wie vollgelaufenen Festplatten und den RAID-Defekt hätte es mit einer sehr hohen Wahrscheinlichkeit im Vorfeld auch nicht erkennen können, da das nicht ganz so einfach ist.
Wer sonst müsste das kontrollieren?
Vor allem, da er ja diese täglichen Sicherungen mit "Altaro" eingerichtet hat und nicht jemand von Uns.
Vor allem, da er ja diese täglichen Sicherungen mit "Altaro" eingerichtet hat und nicht jemand von Uns.
Ganz einfach, ihr selbst und dazu seid ihr im Sinne der Prüfplicht auch gesetzlich verpflichtet!
Übrigens gilt dies auch dann, wenn die entsprechende Leistung vollständig outgesourct ist, denn die Prüfplicht des Unternehmers/der GL selbst, lässt sich nicht wirklich outsourcen.
Ausserdem sollte im eigenen Interesse selbst wissen wie euere Backups funktioniert, vor allem bei einem kleinen Dienstleister, der auch mal länger krankwerden oder gar vollständig ausfallen kann.
Gruss Alex
Moin @BN2023,
ähm, bitte was, ihr habt eine auf Blockebene korrumpierte DB und der Softwarehersteller möchte nun, dass ein Systemintegrator, der schon offen zugegeben hat, dass er von der entsprechenden DB überhaupt keine Ahnung hat, nun die Rettung/Wiederherstellung dieser übernimmt, was durchaus sehr komplex werden kann und auch viel Vorerfahrung mit Datenbanken erfordert.
Sprich, wenn ich das alles richtig verstanden habe, dann hat meiner Ansicht nach definitiv nicht euer Dienstleister einen Schaden, sondern eher euer Software-Hersteller und zwar einen ganz gewaltigen!
Also, bevor das Theater noch Wochen so weiter geht und ihr euch in dieser Zeit nur noch weiter unnötig zerfleischt und dazwischen die DB noch vollends den Geist aufgibt, sucht euch bitte lieber ASAP einen Dienstleister der auch Ahnung von SQL Datenbanken hat, danke.
Gruss Alex
Denn der Software-Hersteller hatte tatsächlich bereits vor 3 Wochen ein Script geschrieben, was er dem IT-Dienstleister übersendet hat, damit er die Datenbank auf einem externen SQL-Server wiederherstellen kann.
Nach einer Woche hat der Software-Hersteller dann mal gefragt, ob schon versucht worden sei, die Datenbank auf einem externen SQL-Server wiederherzustellen... und genau daraufhin kam dann die Antwort des IT-Dienstleisters, dass er das noch nicht versucht habe und dass er die Expertise hier bei ihm (dem Software-Hersteller) sehe. Der IT-Dienstleister selbst sehe sich hier nur als der "verlängerte Arm". Darauf meldete sich dann der Vorstand des Software-Herstellers bei mir mit großem Unverständnis dieser Äußerung gegenüber... was ich auch gut verstehen kann.
Nach einer Woche hat der Software-Hersteller dann mal gefragt, ob schon versucht worden sei, die Datenbank auf einem externen SQL-Server wiederherzustellen... und genau daraufhin kam dann die Antwort des IT-Dienstleisters, dass er das noch nicht versucht habe und dass er die Expertise hier bei ihm (dem Software-Hersteller) sehe. Der IT-Dienstleister selbst sehe sich hier nur als der "verlängerte Arm". Darauf meldete sich dann der Vorstand des Software-Herstellers bei mir mit großem Unverständnis dieser Äußerung gegenüber... was ich auch gut verstehen kann.
ähm, bitte was, ihr habt eine auf Blockebene korrumpierte DB und der Softwarehersteller möchte nun, dass ein Systemintegrator, der schon offen zugegeben hat, dass er von der entsprechenden DB überhaupt keine Ahnung hat, nun die Rettung/Wiederherstellung dieser übernimmt, was durchaus sehr komplex werden kann und auch viel Vorerfahrung mit Datenbanken erfordert.
Sprich, wenn ich das alles richtig verstanden habe, dann hat meiner Ansicht nach definitiv nicht euer Dienstleister einen Schaden, sondern eher euer Software-Hersteller und zwar einen ganz gewaltigen!
Also, bevor das Theater noch Wochen so weiter geht und ihr euch in dieser Zeit nur noch weiter unnötig zerfleischt und dazwischen die DB noch vollends den Geist aufgibt, sucht euch bitte lieber ASAP einen Dienstleister der auch Ahnung von SQL Datenbanken hat, danke.
Gruss Alex
Moin @ukulele-7,
ich habe seit ich 15 bin mit mittlerweile diversesten ERP, CRM, DMS & Co DB's zu tun gehabt und glaub mir, eine Datenübertragung von einer noch vollständig intakten DB, kann zumindest auf die Art und weise die du sie beschrieben hast schon ein ziemliches Abenteuer werden, bei einer DB die jedoch schon offensichtlich einen Schaden hat, ist es sicher nicht damit getan, dass man einfach nur ein SQL-Skript startet und gut ist.
Denn dieses Skript wird sobald es auf die korrupten Daten trifft, höchstwahrscheinlich auch den Dienst quittieren und spätestens dann, benötigst du einen SQL Spezialisten, der das Skript so umschreibt, dass es die korrupten Daten überspringt. Die übersprungenen/korrupten Daten kann man aber nicht so einfach weglassen, weil sonst eventuell die Integrität der Tabellen untereinander nicht mehr gegeben ist, sprich, diese muss man dann irgendwie von Hand wieder rekonstruieren.
Die wenigsten Systemintegratoren sind zugleich auch DB-Experten, daher ist es auch vollkommen OK, wenn der entsprechende DL diese Aufgabe nicht machen möchte.
Wenn der TO keine Erfahrung mit DB's hat, dann würde ich davon eher abraten, da er ratz fatz auch in die falsche DB schreiben könnte.
Gruss Alex
So ein SQL Script ist eine feine Sache und eigentlich ist vermutlich nicht wirklich eine Hürde in deiner DB versteckt. Die meisten Software-Lösungen packen die ganze Logik in die Software, nicht in die DB. Vermutlich müssen nur Tabellen und Inhalte kopiert werden, eventuell noch ein DB Benutzer angelegt werden, irgendwas so in der Art.
ich habe seit ich 15 bin mit mittlerweile diversesten ERP, CRM, DMS & Co DB's zu tun gehabt und glaub mir, eine Datenübertragung von einer noch vollständig intakten DB, kann zumindest auf die Art und weise die du sie beschrieben hast schon ein ziemliches Abenteuer werden, bei einer DB die jedoch schon offensichtlich einen Schaden hat, ist es sicher nicht damit getan, dass man einfach nur ein SQL-Skript startet und gut ist.
Denn dieses Skript wird sobald es auf die korrupten Daten trifft, höchstwahrscheinlich auch den Dienst quittieren und spätestens dann, benötigst du einen SQL Spezialisten, der das Skript so umschreibt, dass es die korrupten Daten überspringt. Die übersprungenen/korrupten Daten kann man aber nicht so einfach weglassen, weil sonst eventuell die Integrität der Tabellen untereinander nicht mehr gegeben ist, sprich, diese muss man dann irgendwie von Hand wieder rekonstruieren.
Aber für jemanden, der bisher noch keine Berührungspunkte mit SQL hatte, ist das eine gewisse Schwelle. So ein kleinerer DL hat dann vielleicht niemanden und der möchte sich jetzt vermutlich auch nicht nochmal die Finger verbrennen, der hat vermutlich Schiss.
Die wenigsten Systemintegratoren sind zugleich auch DB-Experten, daher ist es auch vollkommen OK, wenn der entsprechende DL diese Aufgabe nicht machen möchte.
Ich würde dir raten, es eventuell selbst zu versuchen.
Wenn der TO keine Erfahrung mit DB's hat, dann würde ich davon eher abraten, da er ratz fatz auch in die falsche DB schreiben könnte.
Gruss Alex
So ein SQL Script ist eine feine Sache und eigentlich ist vermutlich nicht wirklich eine Hürde in deiner DB versteckt. Die meisten Software-Lösungen packen die ganze Logik in die Software, nicht in die DB. Vermutlich müssen nur Tabellen und Inhalte kopiert werden, eventuell noch ein DB Benutzer angelegt werden, irgendwas so in der Art.
Und deshalb gibt es auch "Stored Procedures" für Abfragen/Aufräumaufgaben/Statistik-Erstellungen die auf dem Server explizit laufen können. Wieviele Softwarelösungen kennst du denn eigentlich so in dem Detail-Level das du von "den meisten" sprechen kannst? Ich kenne ggf. so ne gute Hand voll - bei mehreren Millionen von Applikationen die es so in der freien Wildbahn gibt die mit irgendwelchen SQL-Datenbanken arbeiten würde ich da nich "von den meisten" sprechen.
Aber für jemanden, der bisher noch keine Berührungspunkte mit SQL hatte, ist das eine gewisse Schwelle. So ein kleinerer DL hat dann vielleicht niemanden und der möchte sich jetzt vermutlich auch nicht nochmal die Finger verbrennen, der hat vermutlich Schiss.
Ich würde dir raten, es eventuell selbst zu versuchen. Du schreibst ja nicht in die alte DB, nur in eine neue DB, da kann nicht so viel passieren. Schau dir das Script an, gerne auch per PM an mich. Vom Grundsatz her würde ich es so machen: Neuen Server installieren, Management Studio verbinden, "Linked Server" bzw. "Verbindungsserver auf dem neuen SQL Server anlegen der auf den alten SQL Server zeigt. Dann die Tabellen auf dem alten Server per Rechtsklick CREATE Script holen und gegen das neue System ausführen. Dann kannst du vermutlich mit dem Script den Inhalt kopieren, vielleicht haben die aber sogar die CREATE TABLE Statements schon eingebaut.
Ich würde dir raten, es eventuell selbst zu versuchen. Du schreibst ja nicht in die alte DB, nur in eine neue DB, da kann nicht so viel passieren. Schau dir das Script an, gerne auch per PM an mich. Vom Grundsatz her würde ich es so machen: Neuen Server installieren, Management Studio verbinden, "Linked Server" bzw. "Verbindungsserver auf dem neuen SQL Server anlegen der auf den alten SQL Server zeigt. Dann die Tabellen auf dem alten Server per Rechtsklick CREATE Script holen und gegen das neue System ausführen. Dann kannst du vermutlich mit dem Script den Inhalt kopieren, vielleicht haben die aber sogar die CREATE TABLE Statements schon eingebaut.
Spätestens ab hier wird es abenteuerlich - und der TO macht es (um es vorweg zu nehmen!) genau richtig: Ich weiss nicht sicher was ich tue, ich lasse es bleiben. Es finden bereits Repa-Versuche statt und da noch rumzufummeln ist so ziemlich das beste was man machen kann - ich für meinen Teil bin nämlich dann idR. der erste der sagt "Leute, ich hab genug zu tun, wenn 5 Leute am selben Problem rumfummeln lass ich euch machen und nehm nen anderes...". Blöd wenn der TO dann alleine da steht.
Dazu kommt: Wenn die DB bereits so beschädigt ist das der Export nicht funktioniert wird auch das mit dem Create-Table und der "hoffnung" das der Content dann irgendwie mitkommt nicht funktionieren. Die DB kann ja nicht mehr ausgelesen werden weil irgendwelche Blöcke zerlegt sind. Was ich zB. im ersten Go machen würde (als Entwickler):
- ich kenne ja die Tabellenstrukture, also tabellen leer anlegen lassen. DAS kann ich mir notfalls aus jedem alten Backup ziehen
- mittels row-count die grösse jeder Tabelle ermitteln
- danach Zeile für Zeile versuchen mit nem Select und Insert die Daten von A nach B übertragen -> im script notfalls mittels "brutaler" Methode: Jede Abfrage baut die Verbindung auf, liest, baut ab, geht auf db 2, verbindet, schreibt, baut ab und macht nen logging wo es klappt und wo es in nen fehler läuft
- am ende wird das fehler-log geprüft und geschaut ob die Einträge relevant waren, ob ich die ggf. aus nem alten Backup ziehen kann oder ob ich die Tabelle manuell angucken kann und manuell übertragen kann (wenn nen Feld dann nur Sonderzeichen enthält weil ich das Glück habe -> dann muss da halt irgendwas manuell rein).
--> das wäre nur mein erster Ansatz in so nem Fall aber eben schon etwas mehr als nur nen bisserl "create script".
- Der SW-Hersteller weiss ja auch ob der irgendwelche servergespeicherten Sachen drin hat, welche Tabellen ggf. eh schon irrelevant sind (das übliche - in Version 1.0 wars noch drin, danach wurde es ersetzt nur nie aufgeräumt...),...
Von daher - wenn ich lese das jemand schon in der Wortwahl davon redet das jemand "vermutlich nur schiss" hat und in nem Forum direkt mal per PN Hilfe anbietet (für nen System in dem vermutlich sämtliche Geschäftsdaten liegen) ist das für mich fragwürdig. Wenn ich dann solche Aussagen dazu lese würde ich mir schon harte Gedanken machen. Am ENDE ist es nämlich der TO der ggf. riskiert morgen ganz blöd da zu stehen -> ich bin nämlich nicht sicher ob die meisten GF's, Auditoren,... der Meinung sind das so ein Vorgehen mit "ich schick einfach mal Daten ins Internet" ganz den Unternehmensrichtlinien entspricht... Für MICH hat das eher den Charakter des in der IT leider oft üblichen "Ich bin der einzig wissende und alle anderen haben keine Ahnung" Systems - was wissen schon der Hersteller der Software und andere Dienstleister wenn man selbst schon ggf. ein paar mal in ne DB geguckt hat. Übrigens macht aus denselben Gründen der DL nunmal erstmal alles richtig. Natürlich hätte der gucken können ob die Sicherung komplett ist - ob der INHALT der Sicherung korrekt ist kann der DL fachlich nunmal nicht. Das hat nichts mit "Schiss" zu tun sondern damit das es nicht dessen Software ist. Die hälfte meiner DB würde auch ein Dienstleister nicht prüfen können - weil der Inhalt oft verschlüsselt da drin ist und der Schlüssel in meiner Software hängt (DAMIT eben ein Export nicht gleich alle Daten freilegt). Wenn man soweit gehen will wie es der TO ja möchte und den DL das Backup zuschieben will hätte man höchstens sagen können "Prüfung ob die Sicherung bei 100% ist" - aber WAS gesichert ist und ob es hinhaut kann der DL nicht wissen (und ob man das Backup dann brauchen kann - weil zB. die DB mitten in ner Aufräumaktion war und das Backup entsprechend noch ne menge Müll enthält). Hier würde ich eben auch sagen: Die erste Person die in dem ganzen eben versagt hat war der GF vom TO -> wenns unklar definiert ist sich danach beschweren wenns nicht hinhaut...
Die Erfahrungen, die ich mit Trivialsoftware (alles von der Stange) gemacht habe sind die, das grade ältere Anwendungen auf die Nutzung von Datenbank-Features eher verzichten. Da gibt es Tabellen und Indexe, nicht immer Primary Keys, selten Foreign Keys, wenig Funktionen, vielleicht mal die eine oder andere Prozedur und keine Trigger. Manchmal wird z.B. MSSQL TIMESTAMP verwendet, das wäre so ein Stolperstein.
Grade bei einer individual Software wie hier gibt es eigentlich nur zwei Varianten, die ich mir vorstellen kann.
a) Das Unternehmen hat absolute Datenbank-Cracks die die ganze BI in die Datenbank gepackt haben.
b) Das Unternehmen hat einfach nur ~ein Dutzend Tabellen in einer Datenbank liegen, Index drauf und fertig.
Ein Blick im SSMS genügt um die Anzahl der DBs zu sehen und ein paar Klicks werden zeigen, woran man ist - die ganze technische Diskussion ist überflüssig. Da der Anbieter bereits ein Script hat musste hier ja vermutlich nicht sehr lange entwickelt werden. Wäre interessant zu wissen ob das Script dynamisch arbeitet oder statisch einfach CREATE TABLE Statements liefert - das Script kann er mir gerne per PM schicken oder hier posten.
Verantwortung:
Ich habe von Anfang an gesagt das der TO am besten zu einem Datenretter a la Ontrack geht und nichts an dem System selber macht. Ich habe auch immer wieder auf die Verantwortung der GL und des TO gegenüber der GL hingewiesen. Die GL trägt die Verantwortung, bestimmt, welchen Wert die Daten haben bevor sie etwas veranlasst. Und die GL muss über jeden Vorgang entscheiden. Nach meinem Verständnis wird aber mit dem System defacto zwischendurch noch gearbeitet! - G E A R B E I T E T - Viel von dem try and error, was schon gelaufen, ist kann man hier nachlesen und das ist nicht mal Alles denn der DL hat ja auch schon Dinge versucht.
Also ich bitte vielmals um Entschuldigung wenn ich vorschlage, auf ein Livesystem lesend zuzugreifen. Das geht natürlich gar nicht und zeugt offenbar von meiner Verantwortungslosigkeit...
Das Beste wäre nach wie vor - System ausschalten, Auftrag zur Datenrettung erteilen. Das scheint aber nicht gewollt und unter der Prämisse muss meine Empfehlung gelesen werden.
Ich denke nicht, das einer der beiden involvierten Anbieter jetzt daher gehen wird, sich die Verantwortung umschnallt, und Datenrettung so betreibt das der TO nichts selber tun muss. Die wissen genau wenn die jetzt den finalen Vorgang am System ausführen und danach ist alles unwiederbringlich verloren dann haben die vielleicht die Arschkarte. Die verlieren lieber den Kunden als sich jetzt ins Risiko zu begeben. In sofern stehe ich zu meiner Aussage der TO sollte sich schonmal mit der DB und dem Script vertraut machen und unbedingt einen neuen Server mit SQL bereit stellen. Mit viel Glück kann der TO auf alle Tabellen lesend zugreifen und die Fehlerhaften Blöcke liegen irgendwo im White Space. Das kann sich mit fortschreitendem Betrieb allerdings auch ändern.
PS: Und, falls das auch wieder undeutlich ist, der TO muss die GL über alles in Kenntnis setzen, denn er trägt keine Verantwortung, wenn er nicht eigenmächtig handelt. Wenn die GL informiert ist und sagt, mach mal, kann ihm da keiner einen Strick draus drehen.
Grade bei einer individual Software wie hier gibt es eigentlich nur zwei Varianten, die ich mir vorstellen kann.
a) Das Unternehmen hat absolute Datenbank-Cracks die die ganze BI in die Datenbank gepackt haben.
b) Das Unternehmen hat einfach nur ~ein Dutzend Tabellen in einer Datenbank liegen, Index drauf und fertig.
Ein Blick im SSMS genügt um die Anzahl der DBs zu sehen und ein paar Klicks werden zeigen, woran man ist - die ganze technische Diskussion ist überflüssig. Da der Anbieter bereits ein Script hat musste hier ja vermutlich nicht sehr lange entwickelt werden. Wäre interessant zu wissen ob das Script dynamisch arbeitet oder statisch einfach CREATE TABLE Statements liefert - das Script kann er mir gerne per PM schicken oder hier posten.
Verantwortung:
Ich habe von Anfang an gesagt das der TO am besten zu einem Datenretter a la Ontrack geht und nichts an dem System selber macht. Ich habe auch immer wieder auf die Verantwortung der GL und des TO gegenüber der GL hingewiesen. Die GL trägt die Verantwortung, bestimmt, welchen Wert die Daten haben bevor sie etwas veranlasst. Und die GL muss über jeden Vorgang entscheiden. Nach meinem Verständnis wird aber mit dem System defacto zwischendurch noch gearbeitet! - G E A R B E I T E T - Viel von dem try and error, was schon gelaufen, ist kann man hier nachlesen und das ist nicht mal Alles denn der DL hat ja auch schon Dinge versucht.
Also ich bitte vielmals um Entschuldigung wenn ich vorschlage, auf ein Livesystem lesend zuzugreifen. Das geht natürlich gar nicht und zeugt offenbar von meiner Verantwortungslosigkeit...
Das Beste wäre nach wie vor - System ausschalten, Auftrag zur Datenrettung erteilen. Das scheint aber nicht gewollt und unter der Prämisse muss meine Empfehlung gelesen werden.
Ich denke nicht, das einer der beiden involvierten Anbieter jetzt daher gehen wird, sich die Verantwortung umschnallt, und Datenrettung so betreibt das der TO nichts selber tun muss. Die wissen genau wenn die jetzt den finalen Vorgang am System ausführen und danach ist alles unwiederbringlich verloren dann haben die vielleicht die Arschkarte. Die verlieren lieber den Kunden als sich jetzt ins Risiko zu begeben. In sofern stehe ich zu meiner Aussage der TO sollte sich schonmal mit der DB und dem Script vertraut machen und unbedingt einen neuen Server mit SQL bereit stellen. Mit viel Glück kann der TO auf alle Tabellen lesend zugreifen und die Fehlerhaften Blöcke liegen irgendwo im White Space. Das kann sich mit fortschreitendem Betrieb allerdings auch ändern.
PS: Und, falls das auch wieder undeutlich ist, der TO muss die GL über alles in Kenntnis setzen, denn er trägt keine Verantwortung, wenn er nicht eigenmächtig handelt. Wenn die GL informiert ist und sagt, mach mal, kann ihm da keiner einen Strick draus drehen.
1
Yan was macht die Datenbank?
Hallo nochmal an Euch Alle.
Sorry, dass ich mich nicht mehr gemeldet hatte. Aber es war ein riesiger Aufwand um diese defekte SQL-Datenbank herum. Es war unser IT-Dienstleister jetzt involviert, ein weiteres Unternehmen, von dem die Software stammt, die in dieser SQL-Datenbank liegt sowie ein Datenbankspezialist von Microsoft.
Das Ergebnis war, dass wir die SQL-Datenbank komplett neu aufsetzen müssen... und werden.
Da unser physischer Server eh schon sehr alt ist und dieser auch noch auf Win Server 2016 läuft, bekommen wir jetzt einen komplett neuen, physischen Server mit aktuellem Betriebssystem, der dann den alten Server ersetzen wird.
Da müssen dann zunächst sämtliche weiteren Programme drauf installiert werden (z.B. auch DATEV), was eh schon aufwendig werden wird. Erst dann wird eine neue SQL-DB darauf erstellt, die dann mit den Daten gefüllt wird und zwar so, dass nach Möglichkeit Datenverlust verhindert wird (was nicht ganz gelingen wird... das wissen wir bereits).
Das ist der momentane Stand und ich denke, diese Vorgehensweise ist die Vernünftigste und Sinnvollste.
Danke Euch jedenfalls für Eure Hilfe & Unterstützung, die hier und da gute Ideen und Argumente erbracht hat.
Grüße von
Yan
Sorry, dass ich mich nicht mehr gemeldet hatte. Aber es war ein riesiger Aufwand um diese defekte SQL-Datenbank herum. Es war unser IT-Dienstleister jetzt involviert, ein weiteres Unternehmen, von dem die Software stammt, die in dieser SQL-Datenbank liegt sowie ein Datenbankspezialist von Microsoft.
Das Ergebnis war, dass wir die SQL-Datenbank komplett neu aufsetzen müssen... und werden.
Da unser physischer Server eh schon sehr alt ist und dieser auch noch auf Win Server 2016 läuft, bekommen wir jetzt einen komplett neuen, physischen Server mit aktuellem Betriebssystem, der dann den alten Server ersetzen wird.
Da müssen dann zunächst sämtliche weiteren Programme drauf installiert werden (z.B. auch DATEV), was eh schon aufwendig werden wird. Erst dann wird eine neue SQL-DB darauf erstellt, die dann mit den Daten gefüllt wird und zwar so, dass nach Möglichkeit Datenverlust verhindert wird (was nicht ganz gelingen wird... das wissen wir bereits).
Das ist der momentane Stand und ich denke, diese Vorgehensweise ist die Vernünftigste und Sinnvollste.
Danke Euch jedenfalls für Eure Hilfe & Unterstützung, die hier und da gute Ideen und Argumente erbracht hat.
Grüße von
Yan
Hm hat eure DATEV Instanz eine eigene SQL DB? DATEV sichert seine DB ja gegen Fremdzugriffe (und damit auch Fremdnutzung) sehr stark ab. Die Lizenz deckt auch nur DATEV als Software ab. Am Besten, ihr installiert das in separate VMs, dann ist auch die Reihenfolge egal.
1
Hallo und danke für die Info...
All das wird unser IT-Dienstleister übernehmen in Absprache mit unserer Finanzabteilung.
Wir haben jetzt endlich einen Vertrag mit einem IT-Dienstleister gemacht, der sich dann um solche Dinge kümmern muss und der auch den neuen Server komplett konfigurieren wird. Ich stelle dazu lediglich die Remote-Zugriffsmöglichkeiten bereit, da ich ja kein gelernter Admin bin, sondern bisher immer eher die "billige Aushilfe" bei Problemchen...
Grüße von
Yan
All das wird unser IT-Dienstleister übernehmen in Absprache mit unserer Finanzabteilung.
Wir haben jetzt endlich einen Vertrag mit einem IT-Dienstleister gemacht, der sich dann um solche Dinge kümmern muss und der auch den neuen Server komplett konfigurieren wird. Ich stelle dazu lediglich die Remote-Zugriffsmöglichkeiten bereit, da ich ja kein gelernter Admin bin, sondern bisher immer eher die "billige Aushilfe" bei Problemchen...
Grüße von
Yan
