24
Veeam BuR 10, SQL Problem
Tach Digitalfreunde,
da ist ein Server 2012 mit Veeam B&R 10 (kostenlos-Version), der bis eben tadellos Backups auf ein LTO-5 Bandlaufwerk (Kein Wechsler) machte.
Nun erhalte ich folgende Fehlermeldungen: Bilder
Man sieht, trotz Meldung das wohl Speicherplatz fehlt ist noch Platz da.
Bild 1 zeigt den Verlauf den vorherigen, abgeschlossenen Backups (Server_Daten02_6TB). Das dritte Bild zeigt den Startversuch des nächsten Backups (Server_Daten03_6TB) und schlägt fehl.
Server_Daten01_6TB lief noch ohne Probleme durch. Die Backups sollen alle direkt to Tape gemacht werden.
Was sollte ich nun machen?
Kreuzberger
da ist ein Server 2012 mit Veeam B&R 10 (kostenlos-Version), der bis eben tadellos Backups auf ein LTO-5 Bandlaufwerk (Kein Wechsler) machte.
Nun erhalte ich folgende Fehlermeldungen: Bilder
Man sieht, trotz Meldung das wohl Speicherplatz fehlt ist noch Platz da.
Bild 1 zeigt den Verlauf den vorherigen, abgeschlossenen Backups (Server_Daten02_6TB). Das dritte Bild zeigt den Startversuch des nächsten Backups (Server_Daten03_6TB) und schlägt fehl.
Server_Daten01_6TB lief noch ohne Probleme durch. Die Backups sollen alle direkt to Tape gemacht werden.
Was sollte ich nun machen?
Kreuzberger
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: 72089368708
Url: https://administrator.de/contentid/72089368708
Ausgedruckt am: 24.11.2024 um 02:11 Uhr
24 Kommentare
Neuester Kommentar
Moin,
das liegt nicht am Plattenplatz, sondern an der Begrenzung von SQLExpress, dass Du scheinbar nutzt:
https://forums.veeam.com/veeam-backup-replication-f2/sql-database-full-t ...
Gruß
das liegt nicht am Plattenplatz, sondern an der Begrenzung von SQLExpress, dass Du scheinbar nutzt:
https://forums.veeam.com/veeam-backup-replication-f2/sql-database-full-t ...
Gruß
@Coreknabe
Ok, danke für den Hinweis. Das ist ja blöd.
Ich habe kürzlich einige Bänder (in Veeam) gelöscht, so dass ich denke/dachte dass damit auch die Einträge im SQL dazu gelöscht werden. So kam es mir jedenfalls bei der Aktion vor.
Kann man die Datenbank irgendwie reorganisieren?
Kreuzberger
Ok, danke für den Hinweis. Das ist ja blöd.
Ich habe kürzlich einige Bänder (in Veeam) gelöscht, so dass ich denke/dachte dass damit auch die Einträge im SQL dazu gelöscht werden. So kam es mir jedenfalls bei der Aktion vor.
Kann man die Datenbank irgendwie reorganisieren?
Kreuzberger
File to Tape Jobs schreiben sehr viele Informationen in die Konfigurations Datenbank und diese wird hier vermutlich an die 10GB Grenze gekommen sein. Eine Bereinigung wird hier schwierig werden; eventuell kannst du alte Backups aus dem Katalog entfernen. In der Datenbank direkt solltest du nichts verändern, da dies nicht supported ist.
Ein lizenzierter SQL Server wäre natürlich eine einfache Lösung aber kostentechnisch vermutlich für diese Umgebung nicht sinnvoll.
Allgemeine Info noch: Die Version 10 ist zum einem End of Life, zum anderen gibt es hier ungepatchte Sicherheitslücken.
Eigentlich wäre ein Upgrade auf V12 deswegen sinnvoll, auch mit dem Hintergrund, dass hier PostgreSQL als Datenbank genutzt werden könnte.
ABER: Im jetzigen Zustand kann kein Upgrade mehr durchgeführt werden, und mit V12 ändert sich die Lizenzierung von File to Tape und es werden Instanzen belegt; es könnte also sein, dass die Community Edition nicht mehr ausreicht.
Ein lizenzierter SQL Server wäre natürlich eine einfache Lösung aber kostentechnisch vermutlich für diese Umgebung nicht sinnvoll.
Allgemeine Info noch: Die Version 10 ist zum einem End of Life, zum anderen gibt es hier ungepatchte Sicherheitslücken.
Eigentlich wäre ein Upgrade auf V12 deswegen sinnvoll, auch mit dem Hintergrund, dass hier PostgreSQL als Datenbank genutzt werden könnte.
ABER: Im jetzigen Zustand kann kein Upgrade mehr durchgeführt werden, und mit V12 ändert sich die Lizenzierung von File to Tape und es werden Instanzen belegt; es könnte also sein, dass die Community Edition nicht mehr ausreicht.
@regnor
Danke. Ok, auch blöd. Der Server wird nur bei Bedarf genutzt, ist also nicht ständig an.
Das bedeutet also, nach „alten“ Backup-Einträgen suchen und diese löschen?
Und wenn ja, wie mache ich das so, dass es sich auf die SQL-Datenbank wirklich auswirkt?
Kann es sein, dass ich zwar durch das Löschen alter, überflüssiger Bänder und deren Inhalt zwar das Band jeweils gelöscht habe, aber die SQL-Datenbank davon unberührt blieb? Ich hatte die Bänder auf diesem System mit Veeam gelöscht um sie neu für andere Backups zu nutzen.
Kreuzberger
Danke. Ok, auch blöd. Der Server wird nur bei Bedarf genutzt, ist also nicht ständig an.
Das bedeutet also, nach „alten“ Backup-Einträgen suchen und diese löschen?
Und wenn ja, wie mache ich das so, dass es sich auf die SQL-Datenbank wirklich auswirkt?
Kann es sein, dass ich zwar durch das Löschen alter, überflüssiger Bänder und deren Inhalt zwar das Band jeweils gelöscht habe, aber die SQL-Datenbank davon unberührt blieb? Ich hatte die Bänder auf diesem System mit Veeam gelöscht um sie neu für andere Backups zu nutzen.
Kreuzberger
Moin.
Du kannst das DB-File verkleinern. Das Löschen von Daten aus einer Datenbank verkleinert niemals das DB-File selbst, das behält seine Größe und stellt sog. "Whitespace" zur Verfügung. Ein Relikt aus Zeiten, als File-Operationen noch richtig Performance und Zeit gekostet haben....
https://learn.microsoft.com/en-us/sql/relational-databases/databases/shr ...
Cheers,
jsysde
Du kannst das DB-File verkleinern. Das Löschen von Daten aus einer Datenbank verkleinert niemals das DB-File selbst, das behält seine Größe und stellt sog. "Whitespace" zur Verfügung. Ein Relikt aus Zeiten, als File-Operationen noch richtig Performance und Zeit gekostet haben....
https://learn.microsoft.com/en-us/sql/relational-databases/databases/shr ...
Cheers,
jsysde
Per 'remove from catalog' sollten Tapes in inklusive Inhalt aus der Datenbank entfernt werden.
Prüfe am besten mal per Management Studio, wie groß die Datenbank ist, aber auch wieviel Whitespace oder freier Speicher vorhanden ist.
Die Reduzierung der Session History Retention könnte auch nicht etwas bringen:
https://helpcenter.veeam.com/docs/backup/vsphere/history_settings.html?v ...
Prüfe am besten mal per Management Studio, wie groß die Datenbank ist, aber auch wieviel Whitespace oder freier Speicher vorhanden ist.
Die Reduzierung der Session History Retention könnte auch nicht etwas bringen:
https://helpcenter.veeam.com/docs/backup/vsphere/history_settings.html?v ...
https://forums.veeam.com/tape-f29/license-for-tape-backup-t86711.html
Workload kann alles sein. Allerdings wird dann teils via Volumen Schritte abgerechent. Dass muss sich vorher einmal anschauen.
VeeamZip ist davon ausgenommen. Nur du hast hier ja scheinbar nicht nur 1x VM drin.
Liste mal auf, was hier gesichert wird.
Schritte bei NAS sind in 500 GB. Bei über 2 TB wären es 5 Lizenzen, die du konsumierst. Könnte beim Band ähnlich sein. In VM Umgebung kann man es auch einfach testen, in dem man die neue Version installiert und Backup einrichtet. Nach der 1. Sicherung sieht man, wie viele Lizenezn konsumiert wurden.
Wenn es wie bei NAS läuft, wäre es in deinem Fall 5 Stück von 10. Stück. Wäre noch ok.
PS Hat mat sich vertan, kann man die Lizenezn jederzeit wieder revoken! Aber nur via GUI und jede Lizenez einzeln!
Sonst könnte man das ja automatisierne und Veeam be###en. Mit jeder begonnenden Sicherung wird ein Workload berechnet, bzw. mehrere. Und somit die Lizenz abgezogen.
Veeam B&R 12 auch noch so....
Workload kann alles sein. Allerdings wird dann teils via Volumen Schritte abgerechent. Dass muss sich vorher einmal anschauen.
VeeamZip ist davon ausgenommen. Nur du hast hier ja scheinbar nicht nur 1x VM drin.
Liste mal auf, was hier gesichert wird.
Schritte bei NAS sind in 500 GB. Bei über 2 TB wären es 5 Lizenzen, die du konsumierst. Könnte beim Band ähnlich sein. In VM Umgebung kann man es auch einfach testen, in dem man die neue Version installiert und Backup einrichtet. Nach der 1. Sicherung sieht man, wie viele Lizenezn konsumiert wurden.
Wenn es wie bei NAS läuft, wäre es in deinem Fall 5 Stück von 10. Stück. Wäre noch ok.
PS Hat mat sich vertan, kann man die Lizenezn jederzeit wieder revoken! Aber nur via GUI und jede Lizenez einzeln!
Sonst könnte man das ja automatisierne und Veeam be###en. Mit jeder begonnenden Sicherung wird ein Workload berechnet, bzw. mehrere. Und somit die Lizenz abgezogen.
Veeam B&R 12 auch noch so....
Ja, ja. Alles gut. Die 10er ist ja schon älter. Vom Workload her könnte immer noch die Free passen. Bevor man an der DB rumdreht und eh keinen Support hat, wäre vlt. Neuinstallation besser.
@kreuzberger lass dich mal über die Datengröße aus! Da steht was von 6 TB. Da komme ich mit etwas raten und den Angaben für NAS Backup auf 12 Workloads!
Da würdest du oder dein Kunde nicht mehr mit hinkommen. Da alles aufsummiret wird, wären es unterm Strich immer über 10 Workloads für einen Vorgang. Da kann man auch nicht mehr viel tricksen.
Ich weiß aucht nicht, ob es um die Processed Data geht oder allg. die gelesene Quelle. Wenn die 6 TB ausgezreizt sind, kannst du Free vergessen. Sollte aber nun auch schon sein?!? Zumindest bei der 12er sehe ich da ein Problem.
@regnor
Danke, ich will das erstmal probieren, „Remove from Catalog“ reduziert also die maximale Anzahl der Eintrage in der SQL-Datenbank. Klingt einleuchtend. Ich hab angefangen alte, überflüssige Backup-Jobs zu entfernen um mir ein Überblick zu verschaffen.
Es werden hier nur zwei Test-VMs gesichert, die so nicht wirklich wichtig sind. (WSUS und noch was kleines anderes)
Alles andere sind nur Daten von Freigaben aus Windows Servern oder NAS. Hier gibt es auch viel Durcheinander an alten Backups von Daten auf Servern/NAS, die gar nicht mehr existieren bzw. die Daten selbst längst woanders hin „ungezogen“ sind. Sprich: Die Bänder und die Daten auf diesen Bändern können gelöscht werden, die Bänder selbst für andere Backups wiederverwendet werden.
Ich will mal versuchen wenigstens auf diese Weise ein neues Backup laufen zu lassen um zu sehen, ob @regnor’s Vorschlag funktioniert.
Grundsätzlich will ich versuchen bei der Systeminstallation so zu bleiben. Die meisten Daten werden einfach per robocopy gesichert, und eben je nach Bedarf zusätzlich auf die Bänder per Veeam als „doppelter Boden“.
Die Systeminstallationen der Windows-Server werden gelegentlich als Image gesichert per Acronis.
Ein AD (DC) gibt es ja gar nicht. Das Netz wird durch RasPI mit DHCP und DNS „geregelt“.
Kreuzberger
Danke, ich will das erstmal probieren, „Remove from Catalog“ reduziert also die maximale Anzahl der Eintrage in der SQL-Datenbank. Klingt einleuchtend. Ich hab angefangen alte, überflüssige Backup-Jobs zu entfernen um mir ein Überblick zu verschaffen.
Es werden hier nur zwei Test-VMs gesichert, die so nicht wirklich wichtig sind. (WSUS und noch was kleines anderes)
Alles andere sind nur Daten von Freigaben aus Windows Servern oder NAS. Hier gibt es auch viel Durcheinander an alten Backups von Daten auf Servern/NAS, die gar nicht mehr existieren bzw. die Daten selbst längst woanders hin „ungezogen“ sind. Sprich: Die Bänder und die Daten auf diesen Bändern können gelöscht werden, die Bänder selbst für andere Backups wiederverwendet werden.
Ich will mal versuchen wenigstens auf diese Weise ein neues Backup laufen zu lassen um zu sehen, ob @regnor’s Vorschlag funktioniert.
Grundsätzlich will ich versuchen bei der Systeminstallation so zu bleiben. Die meisten Daten werden einfach per robocopy gesichert, und eben je nach Bedarf zusätzlich auf die Bänder per Veeam als „doppelter Boden“.
Die Systeminstallationen der Windows-Server werden gelegentlich als Image gesichert per Acronis.
Ein AD (DC) gibt es ja gar nicht. Das Netz wird durch RasPI mit DHCP und DNS „geregelt“.
Kreuzberger
Sorgen macht mir nur, dass beim Löschen von einigen überflüssigen Backup-Jobs aus den Jobs folgende Fehlermeldung auftauchte.
Andere Jobs liessen sich ohne Fehlermeldung löschen.
Kreuzberger
Andere Jobs liessen sich ohne Fehlermeldung löschen.
Kreuzberger
Moin,
letztlich wird das nur der Veeam-Support bereinigen können, es sei denn, Du bist SQL- / Veeam-Experte. Da Du keinen Veeam-Support in Anspruch nehmen kannst, würde ich Dir empfehlen, das Problem mal im Veeam-Forum zu schildern. Wenn ich keinen Bock hatte, den Ticket-Weg zu nehmen, hatte ich da öfter Glück, da schreiben auch Veeam-Mitarbeiter.
Ich hatte das Problem auch mal, der Support hat die DB bereinigt, mir aber dringend angeraten, einen vollwertigen SQL zu nutzen. Alternativ müsstest Du mal schauen, ob Du mit V12 / PostgreSQL weiterkommst.
Gruß
letztlich wird das nur der Veeam-Support bereinigen können, es sei denn, Du bist SQL- / Veeam-Experte. Da Du keinen Veeam-Support in Anspruch nehmen kannst, würde ich Dir empfehlen, das Problem mal im Veeam-Forum zu schildern. Wenn ich keinen Bock hatte, den Ticket-Weg zu nehmen, hatte ich da öfter Glück, da schreiben auch Veeam-Mitarbeiter.
Ich hatte das Problem auch mal, der Support hat die DB bereinigt, mir aber dringend angeraten, einen vollwertigen SQL zu nutzen. Alternativ müsstest Du mal schauen, ob Du mit V12 / PostgreSQL weiterkommst.
Gruß
@kreuzberger Hat sich denn real durch die Bereinigung etwas am Whitespace der Datenbank verbessert?
Theoretisch könnte man es über einen Supportcase versuchen. Die Community Edition kommt mit best effort Support. Wenn Kapazitäten frei sind und der Support sich nicht an der V10 stört, ware das eine Möglichkeit.
Ansonsten, wenn keine großartige Historie existiert, könnte auch eine neue Konfigurations Datenbank angelegt und Veeam neu eingerichtet werden?
Theoretisch könnte man es über einen Supportcase versuchen. Die Community Edition kommt mit best effort Support. Wenn Kapazitäten frei sind und der Support sich nicht an der V10 stört, ware das eine Möglichkeit.
Ansonsten, wenn keine großartige Historie existiert, könnte auch eine neue Konfigurations Datenbank angelegt und Veeam neu eingerichtet werden?
@regnor
ich bin noch nicht weiter. Neue Backups sind nicht durchführbar. Ich befürchte, ich muss das alles neu aufbauen, was dann bedeutet, ich muss alle Bänder neu einlesen / Inventarisieren ???? ...würde ja Monate dauern.
Ich bin jetzt erst mal ratlos und geplättet, weil ich mit dieser Datenbankgrößengrenze nie gerechnet hatte.
Exkurs: ich komme eigentlich vom Retrospect für Mac, später Windows. Da gibt / gab es immer für jedes Backup eine separate Inhaltsdatei, mit der man auch getrost auf ganz anderen Retrospect-Installationen eine Rücksicherung machen konnte. selbst wenn diese Datei nicht mehr da war konnte man diese anhand der Bände rekonstruieren.
Es gab auch nie irgend wie eine mir bekannte Begrenzung der machbaren Datensicherungen auf einem System.
Auch Datenauslagerungen waren so möglich, man könnte eben Daten auf Bänder auslagern und vom server löschen. Bänder und optional diese Inhaltsdatei waren alles was man brauchte, um die Daten zurück zu holen. das ging so oft so so viel man eben will.
Das scheint mit Veeam alles so nicht zu gehen.
seufz
ich bin noch nicht weiter. Neue Backups sind nicht durchführbar. Ich befürchte, ich muss das alles neu aufbauen, was dann bedeutet, ich muss alle Bänder neu einlesen / Inventarisieren ???? ...würde ja Monate dauern.
Ich bin jetzt erst mal ratlos und geplättet, weil ich mit dieser Datenbankgrößengrenze nie gerechnet hatte.
Exkurs: ich komme eigentlich vom Retrospect für Mac, später Windows. Da gibt / gab es immer für jedes Backup eine separate Inhaltsdatei, mit der man auch getrost auf ganz anderen Retrospect-Installationen eine Rücksicherung machen konnte. selbst wenn diese Datei nicht mehr da war konnte man diese anhand der Bände rekonstruieren.
Es gab auch nie irgend wie eine mir bekannte Begrenzung der machbaren Datensicherungen auf einem System.
Auch Datenauslagerungen waren so möglich, man könnte eben Daten auf Bänder auslagern und vom server löschen. Bänder und optional diese Inhaltsdatei waren alles was man brauchte, um die Daten zurück zu holen. das ging so oft so so viel man eben will.
Das scheint mit Veeam alles so nicht zu gehen.
seufz
Moin,
es ist auch möglich eine bestehende Instanz von Microsoft SQL Express auf PostgreSQL umzuziehen:
https://www.veeam.com/blog/switch-sql-server-postgresql-veeam.html
Gruß,
Dani
es ist auch möglich eine bestehende Instanz von Microsoft SQL Express auf PostgreSQL umzuziehen:
https://www.veeam.com/blog/switch-sql-server-postgresql-veeam.html
Gruß,
Dani
@kreuzberger Ja, eine neue Konfigurations Datenbank heißt auch, dass keine Kataloge mehr vorhanden sind. Im Falle eines Restores müsste ein Band also erst katalogisiert werden. Solange ihr eine Übersicht habt, welche Bänder welche Sicherungen enthalten, ist das bis auf den zeitlichen Aspekt kein Problem.
File to Tape hat schon immer für ein Wachstum der Datenbank gesorgt, wobei das Feature an sich eher selten genutzt wird/wurde. Bei einer lizenzierten Version von Veeam, würde man in der Regel Backup to Tape nutzen und keine einzelne Filesicherung durchführen. Ansonsten ist mit V12 und PostgreSQL das Ganze kein Thema mehr
File to Tape hat schon immer für ein Wachstum der Datenbank gesorgt, wobei das Feature an sich eher selten genutzt wird/wurde. Bei einer lizenzierten Version von Veeam, würde man in der Regel Backup to Tape nutzen und keine einzelne Filesicherung durchführen. Ansonsten ist mit V12 und PostgreSQL das Ganze kein Thema mehr
@regnor
Danke. Ich bin noch nicht weiter weil ich auch noch infos sammle (wie deine) um zu entscheiden, was am besten zu tun ist.
V12 hat wie ich hier und da gelesen hab recht viele Einschränkungen was die Kostenlos-Version angeht. Da geht bei der V10 wohl mehr.
Wie der Zusammenhang von Backup-To-Tape oder File-To-Tape sich auf diese SQL-Datenbank auswirkt erschliesst sich mir nicht. Ggf. hast du da Infos?
Ich bin nun kein SQL- oder Datenbank-Experte. Ich hab das eben als mitlaufendes Feature im Windows-Server mitinstallieren lassen und dachte naiv, das macht eben unter der Haube automatisch, was es eben so soll. Wohl ein blöder Fehler. Das System läuft seit x Jahren so ohne nennenswerte Probleme.
Ob ich in dem Stadium jetzt den Tip von @Dani umsetzen kann ist mir unklar, weil ich nicht weiß ob die SQL-Datenbank in sich korrupt ist. Ist das der Fall nützt mir ja die andere Datenbaksoftware als Umzugsanker erstmal wenig.
...Oder?
Kreuzberger
Danke. Ich bin noch nicht weiter weil ich auch noch infos sammle (wie deine) um zu entscheiden, was am besten zu tun ist.
V12 hat wie ich hier und da gelesen hab recht viele Einschränkungen was die Kostenlos-Version angeht. Da geht bei der V10 wohl mehr.
Wie der Zusammenhang von Backup-To-Tape oder File-To-Tape sich auf diese SQL-Datenbank auswirkt erschliesst sich mir nicht. Ggf. hast du da Infos?
Ich bin nun kein SQL- oder Datenbank-Experte. Ich hab das eben als mitlaufendes Feature im Windows-Server mitinstallieren lassen und dachte naiv, das macht eben unter der Haube automatisch, was es eben so soll. Wohl ein blöder Fehler. Das System läuft seit x Jahren so ohne nennenswerte Probleme.
Ob ich in dem Stadium jetzt den Tip von @Dani umsetzen kann ist mir unklar, weil ich nicht weiß ob die SQL-Datenbank in sich korrupt ist. Ist das der Fall nützt mir ja die andere Datenbaksoftware als Umzugsanker erstmal wenig.
...Oder?
Kreuzberger
In der V12 wurde das File-to-Tape Feature überarbeitet und verbraucht nun auch Instanzen in je 500GB Schritten. Deswegen wäre die Community Edition dann auf 5 TB limitiert (10 Instanzen).
Unterschied zwischen den beiden Job Typen:
Ein File-to-Tape Job sichert Dateien direkt auf Band und schreibt einen File-Katalog in die SQL Datenbank.
Ein Backup-to-Tape Job kopiert eine Image-Sicherung, welche zuvor auf Disk erstellt wurde, auf Tape. Das ist zum einen schneller, zum anderen belegt es nicht viel Speicher in der Datenbank und verbraucht auch keine Lizenzen, wenn das ursprüngliche Image Backup lizenziert wurde (Agent,VM).
Die V10 unterstützt kein PostgreSQL. Deswegen würde eine Migration derzeit nicht in Frage kommen.
Unterschied zwischen den beiden Job Typen:
Ein File-to-Tape Job sichert Dateien direkt auf Band und schreibt einen File-Katalog in die SQL Datenbank.
Ein Backup-to-Tape Job kopiert eine Image-Sicherung, welche zuvor auf Disk erstellt wurde, auf Tape. Das ist zum einen schneller, zum anderen belegt es nicht viel Speicher in der Datenbank und verbraucht auch keine Lizenzen, wenn das ursprüngliche Image Backup lizenziert wurde (Agent,VM).
Die V10 unterstützt kein PostgreSQL. Deswegen würde eine Migration derzeit nicht in Frage kommen.
@regnor
Danke
Also würde ein Backup-To-Tape wie du es beschreibst erst ein Image der Daten von 6TB anlegen, und das dann auf 4 Bänder á 1,5TB (LTO-5) sichern!? Demnach müsste im Backup-Server ein Volume mit mindestens 6TB frei sein?
Was passiert mit dem Image nach dem Backup? Ist das dann gelöscht?
Ich probiere das mal aus, ob es von dem Windows-Server dann so ginge, obwohl das SQL derzeit bockt.
Laut @Dani wäre ein Umstellen auf PostgreSQL möglich, ich weiss aber nicht, ob sied aber berücksichtige, dass hier V10 genutzt wird.
Kreuzberger
Danke
Also würde ein Backup-To-Tape wie du es beschreibst erst ein Image der Daten von 6TB anlegen, und das dann auf 4 Bänder á 1,5TB (LTO-5) sichern!? Demnach müsste im Backup-Server ein Volume mit mindestens 6TB frei sein?
Was passiert mit dem Image nach dem Backup? Ist das dann gelöscht?
Ich probiere das mal aus, ob es von dem Windows-Server dann so ginge, obwohl das SQL derzeit bockt.
Laut @Dani wäre ein Umstellen auf PostgreSQL möglich, ich weiss aber nicht, ob sied aber berücksichtige, dass hier V10 genutzt wird.
Kreuzberger
Im Prinzip ist es einfach ein anderer Backup Ansatz. Anstatt file basierend zu sichern, wird das komplette Systeme oder ein Volume auf Disk gesichert und danach wird sekundär auf Tape ausgelagert. Gesichert wird nur was real belegt ist, und zusätzlich dedupliziert und komprimiert.
Aber dieser Ansatz wird dir leider auch nicht weiterhelfen. Es bräuchte eine lizenzierte Version von Veeam um Backup to Tape nutzen zu können. Ich hatte es in meinem vorigen Post nicht als Alternative zu deinem jetzigen Aufbau erwähnt, sondern wollte nur aufzeigen, wie es sich mit der Datenbank Auslastung verhält.
Leider sehe ich derzeit keine wirklich einfache Lösung, das in den Griff zu bekommen, solange die Datenbank auf 100% läuft.
Aber dieser Ansatz wird dir leider auch nicht weiterhelfen. Es bräuchte eine lizenzierte Version von Veeam um Backup to Tape nutzen zu können. Ich hatte es in meinem vorigen Post nicht als Alternative zu deinem jetzigen Aufbau erwähnt, sondern wollte nur aufzeigen, wie es sich mit der Datenbank Auslastung verhält.
Leider sehe ich derzeit keine wirklich einfache Lösung, das in den Griff zu bekommen, solange die Datenbank auf 100% läuft.
Moin,
Es wird nicht einfacher, da du noch Windows Server 2012 in Verbindung mit Veeam B&R 10. Aus meiner Sicht führt folgender Weg zum Ziel:
Das ist machbar, ist nichts für schwach Nerven und Bedarf einer sehr guten Vorbereitung. Wenn du in SQL und Veeam fit bist, ist das an zwei Tagen durch.
Gruß,
Dani
Ob ich in dem Stadium jetzt den Tip von @Dani umsetzen kann ist mir unklar, weil ich nicht weiß ob die SQL-Datenbank in sich korrupt ist. Ist das der Fall nützt mir ja die andere Datenbaksoftware als Umzugsanker erstmal wenig.
Wieso sollte auf einem die Datenbank korrupt sein? Hast du direkt an den Dateien rumgespielt oder bezieht sich die Meinung auf den letzten Screenshot von dir?Es wird nicht einfacher, da du noch Windows Server 2012 in Verbindung mit Veeam B&R 10. Aus meiner Sicht führt folgender Weg zum Ziel:
- Neuen Windows Server + SQL Server Standard aufsetzen. Beides kann 180 Tage im Test Modus betrieben werden. Wichtig ist hierbei, du solltest schauen, dass der SQL Server Standard die selbe Version (z.B. 2012) entspricht wie die SQL Express. Um so mit die Kompatibilität sicherzustellen.
- https://helpcenter.veeam.com/docs/backup/hyperv/vbr_config_migrate_to_an ...
- Sicht- und Funktionsprüfung.
- Nach und nach auf neuere Veeam B&R Versionen aktualisieren. Damit verbunden musst du auch natürlich Windows Server anheben. Um die Kompatibilitäts Anforderungen zu erfüllen.
- ...
- Am Ende kannst du auf PostgreSQL migrieren
Das ist machbar, ist nichts für schwach Nerven und Bedarf einer sehr guten Vorbereitung. Wenn du in SQL und Veeam fit bist, ist das an zwei Tagen durch.
Gruß,
Dani
@Dani
Danke.
Mir scheint, das ist so nich meine Option, zumindest in Teilen nicht.
Der Windows Serve 2012 Wäre vorhanden und Läuft. Das wäre auch komplett so neu Installierbar.
Veeam B&R V10 ist auch da und so mit den bereits eingespülten Updates wieder installierbar.
Die Konfiguration des Alten könnte dann auf das frisch installierte System geladen werden.
SQL Express könnte dann so dein Vorschlag funktioniert auf PostgreSQL umgestellt werden.
Sofern das dann so lauffähig ist, wäre ein weiteres „Angeben“ von Windows Server als auch Veeam V10 auf neueres nicht vorgesehen, da damit Einschränkungen hinzunehmen wären, was ich nicht will.
Wie gesagt, der Backup-Server läuft nur gelegentlich für Datensicherungen per Bedarf auf Band als „doppelter Boden“ zu bereits anderen Datensicherungen. Hierfür Unsummen an Lizenzgebühren aufzubringen wäre mir nix, sorry.
Ich weiß, das System wäre dann alt, aber so ausreichend. (..sofern PostgreSQL die Beschränkung aufhebt.)
Ich hätte dann nur den Aufwand, alle vorhandenen Datensicherungen entweder neu frisch anzufertigen, oder alle vorhandenen beschriebenen Bänder neu zu Inventarisieren.
Hab ich das richtig verstanden?
Kreuzberger
Danke.
Mir scheint, das ist so nich meine Option, zumindest in Teilen nicht.
Der Windows Serve 2012 Wäre vorhanden und Läuft. Das wäre auch komplett so neu Installierbar.
Veeam B&R V10 ist auch da und so mit den bereits eingespülten Updates wieder installierbar.
Die Konfiguration des Alten könnte dann auf das frisch installierte System geladen werden.
SQL Express könnte dann so dein Vorschlag funktioniert auf PostgreSQL umgestellt werden.
Sofern das dann so lauffähig ist, wäre ein weiteres „Angeben“ von Windows Server als auch Veeam V10 auf neueres nicht vorgesehen, da damit Einschränkungen hinzunehmen wären, was ich nicht will.
Wie gesagt, der Backup-Server läuft nur gelegentlich für Datensicherungen per Bedarf auf Band als „doppelter Boden“ zu bereits anderen Datensicherungen. Hierfür Unsummen an Lizenzgebühren aufzubringen wäre mir nix, sorry.
Ich weiß, das System wäre dann alt, aber so ausreichend. (..sofern PostgreSQL die Beschränkung aufhebt.)
Ich hätte dann nur den Aufwand, alle vorhandenen Datensicherungen entweder neu frisch anzufertigen, oder alle vorhandenen beschriebenen Bänder neu zu Inventarisieren.
Hab ich das richtig verstanden?
Kreuzberger
Moin,
ich halte persönlich nichts von deinem Plan.
Windows Server 2012 seit Oktober 2023 ohne Support und ohne Updates. Veeam B&R 10 (dem enthalten SQL Express möchte ich gar nicht sprechen) ebenfalls End of Support. D.h. für letztes werden evtl. (kritische) Sicherheitslücken nicht mehr behoben. In Kombination mit den angesprochen Daten (evtl. auch personenbezogen) ist es eigentlich nicht tragbar. Ist sicherlich nicht dein Testumgebung, welche du mit einem doppelten Boden sicherst.
Daher hast du folgende Optionen:
Gruß,
Dani
ich halte persönlich nichts von deinem Plan.
Windows Server 2012 seit Oktober 2023 ohne Support und ohne Updates. Veeam B&R 10 (dem enthalten SQL Express möchte ich gar nicht sprechen) ebenfalls End of Support. D.h. für letztes werden evtl. (kritische) Sicherheitslücken nicht mehr behoben. In Kombination mit den angesprochen Daten (evtl. auch personenbezogen) ist es eigentlich nicht tragbar. Ist sicherlich nicht dein Testumgebung, welche du mit einem doppelten Boden sicherst.
Daher hast du folgende Optionen:
- Du bleibst bei deiner aktuellen Lösung, migrierst die Instanz 1:1 und wirst früher oder später wieder an dem Problem stehen.
- Du überlegst dir eine langfristige Lösung (evtl. sogar auf Basis von Linux)
- Den SQL Express durch SQL Standard ersetzen. Woher du de gleiche Version wie SQL Express bekommst, weiß ich nicht. Weil SQL 2012 ist ebenfalls EoS. Somit auch keine Updates und Support.
Gruß,
Dani
Hallo @Dani und die andern,
zunächst erst einmal vielen dank. Ich bin noch nicht so recht Eiter gekommen, weil die Entscheidung wie noch aussteht. Letztlich gab es hier vorschlage, die arg ins geld gehen, was zu vermeiden ist.
Es handelt sich NICHT um eine Produktiv- oder Kunden-Umgebung.
Ich bin bei meiner suche am Wochenende auf diese Seite gestossen:
https://uwe-kernchen.de/phpmyfaq/index.php?action=faq&cat=7&id=1 ...
Im Abschnitt "Veeam SQL Express DB verkleinern / 10GB voll:“ wir hier ja auch noch mal das Thema beschrieben.
Sofern es hier für mich praktikabel Lösungen gibt will ich diese auch erstmal probieren. Als kommenden schritt mache ich vom Stand der Dinge ein Image-Backup des Systems.
Dannwill ich versuchen das umzusetzen, was da beschrieben ist, ich hoffe, dass ich da eure Hilfe bekomme, denn wie genau man das durchführt steht da ja für mich Datenbank-Blödie nicht genau genug.
Kreuzberger
zunächst erst einmal vielen dank. Ich bin noch nicht so recht Eiter gekommen, weil die Entscheidung wie noch aussteht. Letztlich gab es hier vorschlage, die arg ins geld gehen, was zu vermeiden ist.
Es handelt sich NICHT um eine Produktiv- oder Kunden-Umgebung.
Ich bin bei meiner suche am Wochenende auf diese Seite gestossen:
https://uwe-kernchen.de/phpmyfaq/index.php?action=faq&cat=7&id=1 ...
Im Abschnitt "Veeam SQL Express DB verkleinern / 10GB voll:“ wir hier ja auch noch mal das Thema beschrieben.
Sofern es hier für mich praktikabel Lösungen gibt will ich diese auch erstmal probieren. Als kommenden schritt mache ich vom Stand der Dinge ein Image-Backup des Systems.
Dannwill ich versuchen das umzusetzen, was da beschrieben ist, ich hoffe, dass ich da eure Hilfe bekomme, denn wie genau man das durchführt steht da ja für mich Datenbank-Blödie nicht genau genug.
Kreuzberger
