Neu Dringende Hilfe benötigt wegen Datensicherung

[mh1]

Alles steht und fällt damit, dass du am Ende doch das Backup (also die eazybusiness.bak) brauchst.
Ich würde nochmal versuchen, mit dem Hoster eine friedliche Einigung zu erzielen. Im Moment sitzt er am längeren Hebel. Weil ER hat das, was DU willst in SEINEN Händen.
Vertragsauflösungen, Reklamationen, böse Worte usw. würd ich mir jetzt erstmal verkneifen bis du das Backup in deinen Händen hast.

Du brauchst den Hoster dazu. Denn nur er kann dir Zugriff auf die DB Backups geben. Auch Drittanbieter Tools wie das angesprochene Backup&FTP können dir keinen Zugriff auf das Backupdir geben, wenn der Hoster, das für deinen User nicht vorgesehen hat.

...Es gibt theoretisch zwei Möglichkeiten die mir einfallen: Man kann die DB rausskripten, das geht aber nur bei "Kleinen" DBs gut

Ich habe mal eine eazybusiness per Skript gesichert und auf einem lokalen System wiederhergestellt, weil wir vor einem ähnlichen Problem standen und "Partner" haben uns keinen Zugriff mehr auf unsere Backups gegeben....
Das ist extrem zeitaufwändig, macht auch nur bedingt Spaß und würd ich absolut nicht weiterepfehlen
...das ist dann auch was anderes, als ein Backup (man baut hier quasi die Datenbank mit den bestehenden Daten nach)

- oder man kann schauen ob der SQL Server schlecht konfiguriert ist und man vielleicht über SQL Befehle die BAK-Dateien auslesen kann...)

Unser erster Hoster hat uns einen sysadmin Zugang zum SQL-Server gegeben. Da hatten wir dann natürlich auch Zugriff auf die Backups. Aber ich denke mal, dass es keinen vernünftigen Hoster gibt, der seinen SQL-Server so konfiguriert...


Soviel ich weiß, wird einem bei Ecomdata automatisch relativ zeitnah ein Backup zur Verfügung gestellt.

 

[Astrid Berends]

Genau so ist es.
Wenn @Astrid Berends den Servernamen so eingibt: XXX.68.118.XX\SQLWAWI21,8260, dann würde das Programm versuchen, sich auf den Port 1433 bei XXX.68.118.XX zu verbinden und wird damit keinen Erfolg haben.

Hallo,

ich muss euch etwas enttäuschen.... war nicht das Problem. Sondern komplett die falsche Adresse, da der Hoster im Backend die ursprünglichen Daten nicht aktuslisiert hat, bis dato sind dort die alten Daten vorhanden.
Das Problem konnte ich damals noch lösen und ein Backup ziehen... die neue Adresse beinhaltet die Domain der Rest ist aber gleich... es handelt sich aber bei 8260 nicht um einen Port sondern der Beginn der SQL-Datenbank bzw. den Namen des Teils. Es ist wie gesagt eine Shared-SQL-Datenbank bei dem Anbieter.

 

[Astrid Berends]

Hey @Astrid Berends,

spannendes Thema.


Offensichtlich besteht das Know-How für einen Inhouse Server-Betrieb nicht.
Das ist unsere regelmäßige Servicepartner-Erfahrung - im Grunde haben wir es ja auch mit Handelsunternehmen im weitesten Sinne zu tun. Und was haben die (in aller Regel) mit IT zu tun?
Daher würde ich die Leistung möglichst auf das Unternehmen abgestimmt "fix" einkaufen.


Exakt. Vergiss es. Oder Museum.

Wenn neuer Server dann neu gut geplant und konfiguriert, ordentlich durchlizenziert, mit Wartung und Plan B für diverse Fälle.

Und das gilt On-Premises (Vor Ort-Serverbetrieb) genauso wie in der Cloud.


Das ist eine wichtige Erkenntnis.
Nicht auskennen ist das Eine.
Es zu wissen das Zweite.
Dritte Erkenntnis: Man braucht Hilfe - und zwar ausschließlich professionell. Steht die Datenbank, steht der Betrieb.
Vierte Erkenntnis: Man ist trotzdem voll in der Haftung. Datenabfluss, "gehackt" werden -> der Verantwortliche (m/w/d) steht im Impressum.


Das klingt entweder nach Datenbank komprimiert oder Filestream aktiviert.

Die Standard-SQL Lizenzen für können unterschiedlich lizenziert werden. Dem Preis nach zu urteilen, soll hier scheinbar die Kernbasierte Lizenzierung gewählt werden.

Utopisch ist dieser Preis nicht.


Nicht nur die Installation. Vorher die Server-Planungsphase und danach noch die Wartungsphase [Entstörung, Update, IT Sicherheit, Plan B, Diebstahl] dazunehmen.

Die Phasen kann man zwar ignorieren, Server kaufen und los gehts - und das hilft auch kurzfristig. Aber eben nur kurzfristig.


Daher sollte man sein Backup-Konzept kennen, auch wenn man 0 Ahnung von der Materie selbst hat.
Im Zweifel sind das alles auch Haftungsfragen - gegenüber der GmbH z. B. als GF. Anderes Thema.

Erste Fragen, die man beantworten können sollte zum Thema Backup:

1. Wo werden meine Backups gespeichert?
2. Wüsste ich JETZT wo meine Backups sind, wenn ich sie bräuchte?
3. Habe ich schonmal mein Backup eingespielt? Und wann zuletzt?
4. Wo sind meine Backups, wenn mein Stamm-Rechenzentrum abfackelt?

Ich würde nicht dazu raten einen Server-Vor-Ort zu betreiben, es sei denn, man möchte sich damit auseinandersetzen und hat jemanden an der Hand, der betreuen kann.

Und "jemanden" heißt mindestens 2 qualifizierte Dienstleister zu haben oder zumindest einen Plan B für den Fall, dass mein (externer) IT Admin im Urlaub oder schwer verliebt ist.

Vielen Dank für den umfangreichen Beitrag. Für Aussenstehende ist es oft nicht leicht im Wirrwarr eines Systems was von dem einen und dem anderen IT-Dienstleister verursacht wurden. Es sind in der vergangenheit Fehler gemacht worden, wir können jetzt nur schauen was wir daraus machen und diese Antwort hat schon so einiges geholfen.

 

[Astrid Berends]

In dem Zusammenhang hier meinte ich damit eine Kombination von On-Premise(s) und Cloud, z.B. als Cluster oder Failover-Cluster. Da kann man ja auf verschiedenen Stufen ansetzen.



Deshalb nach Möglichkeit die Daten verwenden, die aktuell in der Wawi funktionieren / hinterlegt sind bzw. abgleichen.
Wer weiß auf welchen Server mit welchem Datenstand dann sonst verbunden wird.

Genau dadurch sind wir auf die veralteten Zugangsdaten bzw. Pfad beim Hoster Backend mit den Zugangsdaten gekommen... und haben einfach den neuen Pfad der nach dem Umzug der Datenbank nur per Mail / Abrufnachricht mitgeteilt wurde aus der Wawi probiert, mit Erfolg.

 

[Astrid Berends]

Na ja, es gibt drei Komponenten in einem Hosting: Verfügbarkeit des Dienstes, Datensicherung/Recovery und performante und stabile Konfiguration und Wartung.

Verfügbarkeit des Dienstes kriegt man auch alleine gut hin.
Datensicherung / Recovery ist schon deutlich komplexer - je nachdem wie "wichtig" das ist trennt sich hier die Spreu vom Weizen bei Hosting - ich kenne viele SQL Hoster die nur ein VM Backup machen - und am Ende des Tages darauf hoffen, dass der SQL Server schon damit klarkommen wird. Hier solltet ihr in euren Vertrag mit dem Hoster schauen: Wie lange ist der Zeitraum, in dem die Daten maximal verloren sind (bei einem 24h Backup sind das logischerweise dann mindestens 24h) und wie lange dauert es, bis bei einem Schaden der Server wieder online ist. Das sind die für Euch wichtigen Kennzahlen.
Das selber ohne Vorkenntnisse hinzubekommen ist - na ja- es ist kein Hexenwerk, aber man muss technisches Verständnis haben und es auch machen mögen.
Performante und stabile Konfiguration und Wartung ist für einfache Systeme auch kein Hexenwerk - aber auch hier: Man braucht technisches Verständnis und man muss Bock drauf haben. Es bringt nix, wenn Patches nicht eingespielt werden usw.

Beim Hoster liegt eure Geschäftsgrundlage. Er hat Zugriff auf all Eure Geschäftsgeheimnisse, Kundendaten, usw. Insofern sollte man sich hier seinen Partner gut aussuchen und auf viel Transparenz bestehen. Ich z.B. würde darauf bestehen, dass ich auch Zugriff auf die Backups habe - ein Hoster, bei dem das nicht der Fall ist, wäre nichts für mich.

Zum Ursprungspost:
Der SQL-Server kann ein Backup nur auf eine Festplatte spielen auf die er Zugriff hat, d.h. ein Backup über "Netzwerk" ist nicht möglich. Egal mit welchem Programm. Habt ihr also nur die SQL Zugangsdaten ("sa-Passwort"), dann habt ihr keine Chance an die Backups zu kommen. (Es gibt theoretisch zwei Möglichkeiten die mir einfallen: Man kann die DB rausskripten, das geht aber nur bei "Kleinen" DBs gut - oder man kann schauen ob der SQL Server schlecht konfiguriert ist und man vielleicht über SQL Befehle die BAK-Dateien auslesen kann...)

Hallo,

ich stimme Dir völlig zu was die Punkte mit dem Hoster angeht, leider handelt es sich halt auch um einen JTL Partner... es wäre einfach wünschenswert wenn JTL den Partnern bestimmte Grundrichtlinien vorschreibt. Insbesondere wenn man keine Ahnung davon hat und man sich drauf verlässt einen JTL Partner zu haben und glaubt gut aufgehoben zu sein und das was für den einen und anderen selbstverständlich ist und man als Laie erwartet auch von Anfang an gemacht wird. Wir wollen uns nicht mit dem Thema IT auch noch auskennen müssen und wurden leider schon mehrfach von JTL-Partnern enttäuscht und uns was verkauft was nicht notwendig gewesen ist und das ganze halt auch nur durch Zufall als ein JTL-Supportler auf dem System war stuzig wurde aufgeflogen ist und selbst sagte das der Partner das hätte wissen müssen weil es Basics sind. Weshalb nicht mehr verkaufen als nötig... manch ein JTL Partner könnte das sogar im Namen tragen.

 

[Astrid Berends]

Zum Ursprungspost:
Der SQL-Server kann ein Backup nur auf eine Festplatte spielen auf die er Zugriff hat, d.h. ein Backup über "Netzwerk" ist nicht möglich. Egal mit welchem Programm. Habt ihr also nur die SQL Zugangsdaten ("sa-Passwort"), dann habt ihr keine Chance an die Backups zu kommen. (Es gibt theoretisch zwei Möglichkeiten die mir einfallen: Man kann die DB rausskripten, das geht aber nur bei "Kleinen" DBs gut - oder man kann schauen ob der SQL Server schlecht konfiguriert ist und man vielleicht über SQL Befehle die BAK-Dateien auslesen kann...)

Achso wegen dem Backup... mir ist schon was dazu gelungen, das sollte eigentlich mit Ticket 2023040410003439 geprüft werden ob alles so läuft und die Daten mit der methode also mit dem Programm gesichert werden und auch wieder hergestellt werden könnten.