Backup - Datenbankserver
Hallo zusammen,
Ich habe einen Datenbankserver, dieser hat ebenfalls ein Webserver um die Dienste zu erreichen.
Bisher läuft der Backup über einen Dump vom SQL, das ganze neu aufzusetzten, wäre aber auch viel Arbeit.
Deswegen möchte ich zusätzlich noch den gesamten Server backupen.
Ich könnte mir vorstellen das ganze zu virtualisieren und die VM zu backupen -> aber darf man das bei SQL -> sprich Datenfehler?
Und wie kann ich dann das Backup überprüfen ob es nicht fehlerhaft ist?
Gibt es auch andere Möglichkeiten außer VM?
Vielen Dank!
Es soll maximale Sicherheit bieten, vor allem wegen dem Webserver zugriff.
Danke!
Ich habe einen Datenbankserver, dieser hat ebenfalls ein Webserver um die Dienste zu erreichen.
Bisher läuft der Backup über einen Dump vom SQL, das ganze neu aufzusetzten, wäre aber auch viel Arbeit.
Deswegen möchte ich zusätzlich noch den gesamten Server backupen.
Ich könnte mir vorstellen das ganze zu virtualisieren und die VM zu backupen -> aber darf man das bei SQL -> sprich Datenfehler?
Und wie kann ich dann das Backup überprüfen ob es nicht fehlerhaft ist?
Gibt es auch andere Möglichkeiten außer VM?
Vielen Dank!
Es soll maximale Sicherheit bieten, vor allem wegen dem Webserver zugriff.
Danke!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1333389986
Url: https://administrator.de/contentid/1333389986
Ausgedruckt am: 24.11.2024 um 11:11 Uhr
10 Kommentare
Neuester Kommentar
Moin,
Das kommt auf den Server/ Virtuelle Maschine an und das genutzte Betriebssystem. Gib mal ein paar Eckdaten zur Umgebung?
Du kannst mit Veeam z.b. eine Sicherung machen welche Application Awareness unterstützt dann sind die Daten sicher und konsistent gesichert.
Du kannst hierfür die Veeam Community Edition ist kostenfrei für einen physischen Server gibt es den Veeam Agent. Prüfen kannst du backups nur mit regelmäßigen Restore.
Grüße niklas
Das kommt auf den Server/ Virtuelle Maschine an und das genutzte Betriebssystem. Gib mal ein paar Eckdaten zur Umgebung?
Du kannst mit Veeam z.b. eine Sicherung machen welche Application Awareness unterstützt dann sind die Daten sicher und konsistent gesichert.
Du kannst hierfür die Veeam Community Edition ist kostenfrei für einen physischen Server gibt es den Veeam Agent. Prüfen kannst du backups nur mit regelmäßigen Restore.
Grüße niklas
wer sich selbst und den Feind nicht kennt, wird jede Schlacht verlieren. Sprach mal ein Kriegsphilosoph mit dem Namen "Sun Tse" in dem Buch "Die Kunst des Krieges". Also lerne dich selbst kennen... was sind deine SLA Anforderungen?
"Sicher" sind die Sachen so wie der Provider das in seinen Geschäftsbedingungen definiert, aber reicht einem das? Also erstmal Anforderungen analyiseren, so Sachen wie "Wie viel Datenverlust kann ich mir leisten" und "wie lange darf / soll das Wiederherstellen dauern".
Bei Virtualisierungen geht die Tendenz oft mal dahin, die Datenbanken auf einem separaten Laufwerk abzulegen und dann den Datenträger mit einem kontinuierlichen oder inkrementellem Backup auf Basis des Hypervisors oder Storage zu sichern, dessen Frequenz den eigenen Anforderungen entspricht, und man macht dann keine Backups am MS SQL Server mehr. Das wäre dann doppelt gemoppelt.
Und vergiß mal schnell den Begriff "Dump". Sowas gibts in der Microsoft SQL Server Welt nicht. Das ist Oracle oder MySQL. Der MS SQL Server kann des hier:
a) Backup im laufenden Betrieb: Ab dem Zeitpunkt X wird die Datenbank incl Log in eine Backupdatei geschrieben. Diese liegt lokal weil das Backup mit einem Dienstekonto läuft, das an Netzlaufwerke nicht rankommt. Vermutlich kopiert Hetzner das dann noch mal in einem Job weg. Datenwiederherstellung ist so bis zum Zeitpunkt des Backups möglich.
b) Wiederherstellbarkeit zu jedem beliebigen Zeitraum mit dem "vollständigen Wiederherstellugnsmodell". Zusätzlich zu a) wird das Transaktionsprotokoll gesichert, in eine Extradatei... macht man normal in 15 Minutenzyklen. Geht der SQL Server komplett hops hat man maximal 15 Minuten verloren, ist der Storage mit der Logdatei intakt, verliert man garkeine Daten bevor die ganze Platform steht.
c) Backup ohne laufenden Betrieb: Datenbank "offline schalten", "trennen", MDF und LDF DAtei wegkopieren, "anhängen", und "online schalten". Also DAten und Log ohne Automatismus gesichert... aber wer würde denn mutwillig einen produktiven SQL Server stoppen? Eher nicht. Man kann aber zu 99,99% Sicherheit die beiden Daten weiterverwenden, wenn z.B. der Server defekt ist aber der Storage noch intakt... verliert keine Zeit für ein Restore und hat den aktuellsten STand.
Den Begriff "schlau" würde ich nicht verwenden, gausowenig wie "dumm". Irgendeine Datensicherung ist besser als garkeine, und migriert man in eine neue Umgebung, dann sollte man vorher wissen, wieviel "Auszeit" das Ganze vertragen kann.
Man sollte sich eher mal überlegen, ein Cross Cloud Backup zu fahren, sprich hat man seine Daten in AWS, dann wäre ein Notbackup in Google cloud oder Azure der "doppelte Boden", falls einem der Cloud Account gehackt wird, hat man immer noch seine Daten "woanders" zusätzlcih gesichert.
"Sicher" sind die Sachen so wie der Provider das in seinen Geschäftsbedingungen definiert, aber reicht einem das? Also erstmal Anforderungen analyiseren, so Sachen wie "Wie viel Datenverlust kann ich mir leisten" und "wie lange darf / soll das Wiederherstellen dauern".
Bei Virtualisierungen geht die Tendenz oft mal dahin, die Datenbanken auf einem separaten Laufwerk abzulegen und dann den Datenträger mit einem kontinuierlichen oder inkrementellem Backup auf Basis des Hypervisors oder Storage zu sichern, dessen Frequenz den eigenen Anforderungen entspricht, und man macht dann keine Backups am MS SQL Server mehr. Das wäre dann doppelt gemoppelt.
Und vergiß mal schnell den Begriff "Dump". Sowas gibts in der Microsoft SQL Server Welt nicht. Das ist Oracle oder MySQL. Der MS SQL Server kann des hier:
a) Backup im laufenden Betrieb: Ab dem Zeitpunkt X wird die Datenbank incl Log in eine Backupdatei geschrieben. Diese liegt lokal weil das Backup mit einem Dienstekonto läuft, das an Netzlaufwerke nicht rankommt. Vermutlich kopiert Hetzner das dann noch mal in einem Job weg. Datenwiederherstellung ist so bis zum Zeitpunkt des Backups möglich.
b) Wiederherstellbarkeit zu jedem beliebigen Zeitraum mit dem "vollständigen Wiederherstellugnsmodell". Zusätzlich zu a) wird das Transaktionsprotokoll gesichert, in eine Extradatei... macht man normal in 15 Minutenzyklen. Geht der SQL Server komplett hops hat man maximal 15 Minuten verloren, ist der Storage mit der Logdatei intakt, verliert man garkeine Daten bevor die ganze Platform steht.
c) Backup ohne laufenden Betrieb: Datenbank "offline schalten", "trennen", MDF und LDF DAtei wegkopieren, "anhängen", und "online schalten". Also DAten und Log ohne Automatismus gesichert... aber wer würde denn mutwillig einen produktiven SQL Server stoppen? Eher nicht. Man kann aber zu 99,99% Sicherheit die beiden Daten weiterverwenden, wenn z.B. der Server defekt ist aber der Storage noch intakt... verliert keine Zeit für ein Restore und hat den aktuellsten STand.
Den Begriff "schlau" würde ich nicht verwenden, gausowenig wie "dumm". Irgendeine Datensicherung ist besser als garkeine, und migriert man in eine neue Umgebung, dann sollte man vorher wissen, wieviel "Auszeit" das Ganze vertragen kann.
Man sollte sich eher mal überlegen, ein Cross Cloud Backup zu fahren, sprich hat man seine Daten in AWS, dann wäre ein Notbackup in Google cloud oder Azure der "doppelte Boden", falls einem der Cloud Account gehackt wird, hat man immer noch seine Daten "woanders" zusätzlcih gesichert.
Zitat von @ZZaaiiggaa:
Vielen Dank für den Beitrag!
Was wird dann für ein solches Backup für eine Software verwendet?
Und zum Backup von Veeam - kann ich einfach AWS Amazon S3 für die Backups nutzen?
Und eine Verständnisfrage, mal angenommen alles geht hops (Server + Backup Server einfach alles) und das einzige Backup ist bei Amazon. Kann ich mich dann mit einem x beliebigen Veeam Manager zu S3 verbinden und das Backup auf einen x beliebigen Hyper V draufspielen?
Zitat von @GrueneSosseMitSpeck:
Bei Virtualisierungen geht die Tendenz oft mal dahin, die Datenbanken auf einem separaten Laufwerk abzulegen und dann den Datenträger mit einem kontinuierlichen oder inkrementellem Backup auf Basis des Hypervisors oder Storage zu sichern, dessen Frequenz den eigenen Anforderungen entspricht, und man macht dann keine Backups am MS SQL Server mehr. Das wäre dann doppelt gemoppelt.
Bei Virtualisierungen geht die Tendenz oft mal dahin, die Datenbanken auf einem separaten Laufwerk abzulegen und dann den Datenträger mit einem kontinuierlichen oder inkrementellem Backup auf Basis des Hypervisors oder Storage zu sichern, dessen Frequenz den eigenen Anforderungen entspricht, und man macht dann keine Backups am MS SQL Server mehr. Das wäre dann doppelt gemoppelt.
Vielen Dank für den Beitrag!
Was wird dann für ein solches Backup für eine Software verwendet?
Und zum Backup von Veeam - kann ich einfach AWS Amazon S3 für die Backups nutzen?
Und eine Verständnisfrage, mal angenommen alles geht hops (Server + Backup Server einfach alles) und das einzige Backup ist bei Amazon. Kann ich mich dann mit einem x beliebigen Veeam Manager zu S3 verbinden und das Backup auf einen x beliebigen Hyper V draufspielen?
Moin ich nutze hier selber privat ein S3 Bucket, müsste glaube ich S3 glacier sein das ist das preisgünstigte was Amazon hier in Europa anbietet. Du kannst dich mit jedem Veeam verbinden aber du brauchst natürlich auch das Configuration Backup sonst ist das Backup nutzlos.
. Du kannst dich mit jedem Veeam verbinden aber du brauchst natürlich auch das Configuration Backup sonst ist das Backup nutzlos.
Nein, du brauchst im schlimmsten Fall nur die Backup Dateien. Diese kannst du einfach im Veeam importieren… aber selbst das musst du nicht, denn du kannst das letzte Full Bakcup mit Veeam Extract entpacken und manuell die VHDX oder VMDK auf den Host
Importieren
Zitat von @ZZaaiiggaa:
War das früher anders? Oder meinste die Configuration vom Veeam Backup Server ?
Zitat von @niklasschaefer:
Muss gerade gestehen habe es auf einem neuen Veeam Server versucht, funktioniert auch ohne Configuration Backup
Muss gerade gestehen habe es auf einem neuen Veeam Server versucht, funktioniert auch ohne Configuration Backup
War das früher anders? Oder meinste die Configuration vom Veeam Backup Server ?
Ich meine ja, in den neueren Versionen funktioniert das wohl.