9
Image-Backup
Werden laufende Datenbanken ( SQL, Oracle ) bei einem Imagebackup ( Acronis, Ghost ) mitgesichert ??
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: 178467
Url: https://administrator.de/forum/image-backup-178467.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
9 Kommentare
Neuester Kommentar
Hi Grußloser
Selbst wenn das Programm, wie z.B. Symantec System Recovery (Ghost ist für Homeuser) VSS-Sicherungen ermöglicht, werden doch nur die Dateien (bspw. *.mdf und *.ldf bei MSSQL) gesichert.
Bei einer Rücksicherung des ganzen Systems ist das o.k.
Für alles weitere gibt es spezielle Agenten in anderen Sicherungsprogrammen (wie bspw. den SQL-Agent bei Symantec BE). Oder man nutzt das Management Studio von MS.
Zitat von @dosser:
Werden laufende Datenbanken ( SQL, Oracle ) bei einem Imagebackup ( Acronis, Ghost ) mitgesichert ??
Jein.Werden laufende Datenbanken ( SQL, Oracle ) bei einem Imagebackup ( Acronis, Ghost ) mitgesichert ??
Selbst wenn das Programm, wie z.B. Symantec System Recovery (Ghost ist für Homeuser) VSS-Sicherungen ermöglicht, werden doch nur die Dateien (bspw. *.mdf und *.ldf bei MSSQL) gesichert.
Bei einer Rücksicherung des ganzen Systems ist das o.k.
Für alles weitere gibt es spezielle Agenten in anderen Sicherungsprogrammen (wie bspw. den SQL-Agent bei Symantec BE). Oder man nutzt das Management Studio von MS.
Hi
wie goscho schon schrieb: sind halt reine Blockbasierte Abbilder dann, also ein Hotbackup der reinen DB: ein Recovery würde die DB erstmal auf Überprüfungswürdig setzen. Bei MS SQL (gerade DBE) hatte ich schon tote DBs danach. Im Backupfalle würde ich die DBs geordnet runterfahren, dann ist das Image mit einem BareMetal Recovery gleich und verwende ich auch ab und an so. Ansonsten halt Agenten nutzen, welche einem auch Fehler der DB evtl melden oder aufgeblähte DBs wieder shrinken können (Transaction Log) oder Offline Backup (PE, Linux, zweites OS) was immer noch die Königslösung ist.
Gruß
Sam
wie goscho schon schrieb: sind halt reine Blockbasierte Abbilder dann, also ein Hotbackup der reinen DB: ein Recovery würde die DB erstmal auf Überprüfungswürdig setzen. Bei MS SQL (gerade DBE) hatte ich schon tote DBs danach. Im Backupfalle würde ich die DBs geordnet runterfahren, dann ist das Image mit einem BareMetal Recovery gleich und verwende ich auch ab und an so. Ansonsten halt Agenten nutzen, welche einem auch Fehler der DB evtl melden oder aufgeblähte DBs wieder shrinken können (Transaction Log) oder Offline Backup (PE, Linux, zweites OS) was immer noch die Königslösung ist.
Gruß
Sam
Hallo,
Der Effekt ist der gleiche, wie wenn man bei einem Server einfach das Stromkabel herauszieht: Im allgemeinen laufen die Anwendungen dann nach einem Neustart wieder. Aber so unbedingt drauf verlassen sollte man sich nicht. Außerdem kann es sein, dass der SnapShot für unterschiedliche Volumes zu unterschiedlichen Zeitpunkten erstellt wird. Dann sind die Daten, die auf unterschiedlichen Laufwerken liegen, inkonsistent. Wenn also Logfiles und DB-File auf unterschiedlichen Laufwerken liegen (was sie wiederum Zwecks Datensicherheit sollten) bekommt man die DB nicht mehr hochgefahren.
Außerdem will man bei Datenbanken meist einen Point-In-Time-Restore und keine Wiederherstellung des gesamten Systems zum Zeitpunkt X. Sprich: wenn das DB-Laufwerk "abraucht" stellt man die letzte DB-Sicherung wieder her und wendet darauf alle seither angefallenen Logfiles an - genau deswegen hat man die ja auf einem anderen (physikalischen!) Laufwerk abgelegt.
Also: ja, man kann DBs mit einfachen Image-Programmen sichern, die von der Applikation selber keine Ahnung haben - aber nur, wenn man seine Daten nicht unbedingt wiederhaben will. Legt man Wert auf seine Daten, dann nimmt man immer ein Backup-Programm, was die Anwendung speziell unterstützt (und mit deren Backup-API spricht). Das kann dann ggf. auch VSS nutzen. Exchange (auch nur eine relationale DB) z.B. bringt einen eigenen VSS-Writer mit, mit dem sich konsistente, wiederherstellbare Snapshots erstellen lassen - nur muss die Backup-Anwendung ihn vernünftig ansprechen können.
Gruß
Filipp
Bei einer Rücksicherung des ganzen Systems ist das o.k.
Jein.Der Effekt ist der gleiche, wie wenn man bei einem Server einfach das Stromkabel herauszieht: Im allgemeinen laufen die Anwendungen dann nach einem Neustart wieder. Aber so unbedingt drauf verlassen sollte man sich nicht. Außerdem kann es sein, dass der SnapShot für unterschiedliche Volumes zu unterschiedlichen Zeitpunkten erstellt wird. Dann sind die Daten, die auf unterschiedlichen Laufwerken liegen, inkonsistent. Wenn also Logfiles und DB-File auf unterschiedlichen Laufwerken liegen (was sie wiederum Zwecks Datensicherheit sollten) bekommt man die DB nicht mehr hochgefahren.
Außerdem will man bei Datenbanken meist einen Point-In-Time-Restore und keine Wiederherstellung des gesamten Systems zum Zeitpunkt X. Sprich: wenn das DB-Laufwerk "abraucht" stellt man die letzte DB-Sicherung wieder her und wendet darauf alle seither angefallenen Logfiles an - genau deswegen hat man die ja auf einem anderen (physikalischen!) Laufwerk abgelegt.
Also: ja, man kann DBs mit einfachen Image-Programmen sichern, die von der Applikation selber keine Ahnung haben - aber nur, wenn man seine Daten nicht unbedingt wiederhaben will. Legt man Wert auf seine Daten, dann nimmt man immer ein Backup-Programm, was die Anwendung speziell unterstützt (und mit deren Backup-API spricht). Das kann dann ggf. auch VSS nutzen. Exchange (auch nur eine relationale DB) z.B. bringt einen eigenen VSS-Writer mit, mit dem sich konsistente, wiederherstellbare Snapshots erstellen lassen - nur muss die Backup-Anwendung ihn vernünftig ansprechen können.
Gruß
Filipp
Zitat von @SamvanRatt:
Hi
wie goscho schon schrieb: sind halt reine Blockbasierte Abbilder dann, also ein Hotbackup der reinen DB: ein Recovery würde
die DB erstmal auf Überprüfungswürdig setzen.
Falsch.Hi
wie goscho schon schrieb: sind halt reine Blockbasierte Abbilder dann, also ein Hotbackup der reinen DB: ein Recovery würde
die DB erstmal auf Überprüfungswürdig setzen.
Bei einem Restore mit BESR hat die Datenbank die selbe Konsistenz wie vor der Sicherung, so VSS zum Sichern eingesetzt wird.
Bei MS SQL (gerade DBE) hatte ich schon tote DBs danach.
Dann waren das bestimmt Images, die mit nicht VSS-fähigen Programmen erstellt wurden.Ansonsten halt Agenten nutzen, welche einem auch Fehler der DB evtl melden oder aufgeblähte DBs wieder
shrinken können (Transaction Log) oder Offline Backup (PE, Linux, zweites OS) was immer noch die Königslösung ist.
Gruß
Dafür gibt es doch aber auch die Möglichkeit, Wartungspläne im Management Studio zu erstellen.shrinken können (Transaction Log) oder Offline Backup (PE, Linux, zweites OS) was immer noch die Königslösung ist.
Gruß
Ich empfehle, diese Wartungen mindestens einmal wöchentlich durchzuführen. Wenn man dabei gleich noch die DBs mitsichert, schadet das auch nicht.
Hi goscho
ich rede von den internen msbackup sowie Acronis Server und BE ohne Agents, welche alle VSS nutzen; sobald VS getriggert wird, erhältst du das Filesystem wie es in der Sekunde ist. Die DBs sind ja weiterhin an den Dateien dran und haben auch ihre Logs/Diffs nicht eingepflegt. ICh arbeite seit Jahren mit dem Wissen und sehe auch keine Möglichkeit ohne Stop/start die DBs oder den Zustand sonst zu sichern (ohne passende Dump Agents), so wie auch filippg schrieb. Die DB Wartung ist ein Thema (bei MSSQL ja direkt vorgesehen), ein Dump/restore kann aber so oder so durchaus erleichterung (MB/Backup) bringen, vor allem bei großen Translogs.
Gruß
Sam
ich rede von den internen msbackup sowie Acronis Server und BE ohne Agents, welche alle VSS nutzen; sobald VS getriggert wird, erhältst du das Filesystem wie es in der Sekunde ist. Die DBs sind ja weiterhin an den Dateien dran und haben auch ihre Logs/Diffs nicht eingepflegt. ICh arbeite seit Jahren mit dem Wissen und sehe auch keine Möglichkeit ohne Stop/start die DBs oder den Zustand sonst zu sichern (ohne passende Dump Agents), so wie auch filippg schrieb. Die DB Wartung ist ein Thema (bei MSSQL ja direkt vorgesehen), ein Dump/restore kann aber so oder so durchaus erleichterung (MB/Backup) bringen, vor allem bei großen Translogs.
Gruß
Sam
Erst mal Danke für Eure tolle unterstützung.
Offensichtlich gibt es da - wie fast immer- sehr diferezierte Ansätze.
Um mal klarer zu erklären warum ich diesen thread mit der Fragestellung eröffnet habe:
Ich hab ( als externer Sysadmin ) in einer Windows-Domain eine Datenbank-Mitgliedserver "geerbte". Darauf läuft Oracle ( 9i - soweit ich das als Datenbank-Dummie sehe ) AX/Ware mit einigen vom einander UNABHÄNGIGEN Datenbanken ( Fibu & Auftragsverwaltung )
Das alles wurde von einer Firma Installiert , konfiguriert und gewartet ( inkl. Update, Veritas-Backup 9.04454, .. )
Nun ist die Firma in Konkurs und die Zwei Teile ( Fibu & Auftragsverwaltung ) wurden von zwei verschiedenen Nachfolgern übernommen. ( vom bestehenden System hat niemand eine Ahnung )
Da meint nun jeder nur für seine Anwendung zuständig zu sein und um den Rest kümmert sich ???
Sprich um das System, , das Backup usw. soll sich kümmern wer mag. Werd wohl ich sein. Nur ist bisher alles rund um Databases ( SQL, Oracle, ... ) ein spanisches Dorf ;-((
Ich hab mir nun mal das BE angesehen und so wie ich das sehe, ist da nichts von einem Datenbank Agent zu sehen. Es wird um 00:00 das gesamte System auf mit Veritas-BE auf einem HP DDS4 DAT gesichert.
-- Beim BE ist werder bei SQL noch bei AdvancedOpenFile irgend etwas eingetragen ?? Möglicherweise werden die DB-Server gestoppt - aber wo sehe ich das ??
-- ausserdem hängt sich diese DAT-Klump relativ häufig auf; dann hilft nicht mal ein reboot - dann muss der Server abgedreht und neu gestartet werden ( DAT-SCSi-Bus hängt - aber das ist eine andere , bekannte Baustelle )
-- ist es bei dieser Backupvariante möglich, die Dantenbanken auf ein anderes ( neues ) System zu übertragen ??
Ich will nun im Notfall den Kunden nicht im Regen stehen lassen und suche für den DB-Server eine Backup lösung die
- auf dem heutigen technischen Stand ist - bitte keine DAT Variante mehr
-- eine Variante die es erlaubt die Daten auch auf einem Ersatzsystem zu restoren
- die ein Emergency Restore des Systems erlaubt - ich bevorzuge da Acronis.
PS:
Ich hoffe das war jetzt nicht zu langatmig.
PPS:
Für jeden gefundenen Rechtschreibfehler bitte 1.-€ an Greenpeace spenden)
Offensichtlich gibt es da - wie fast immer- sehr diferezierte Ansätze.
Um mal klarer zu erklären warum ich diesen thread mit der Fragestellung eröffnet habe:
Ich hab ( als externer Sysadmin ) in einer Windows-Domain eine Datenbank-Mitgliedserver "geerbte". Darauf läuft Oracle ( 9i - soweit ich das als Datenbank-Dummie sehe ) AX/Ware mit einigen vom einander UNABHÄNGIGEN Datenbanken ( Fibu & Auftragsverwaltung )
Das alles wurde von einer Firma Installiert , konfiguriert und gewartet ( inkl. Update, Veritas-Backup 9.04454, .. )
Nun ist die Firma in Konkurs und die Zwei Teile ( Fibu & Auftragsverwaltung ) wurden von zwei verschiedenen Nachfolgern übernommen. ( vom bestehenden System hat niemand eine Ahnung )
Da meint nun jeder nur für seine Anwendung zuständig zu sein und um den Rest kümmert sich ???
Sprich um das System, , das Backup usw. soll sich kümmern wer mag. Werd wohl ich sein. Nur ist bisher alles rund um Databases ( SQL, Oracle, ... ) ein spanisches Dorf ;-((
Ich hab mir nun mal das BE angesehen und so wie ich das sehe, ist da nichts von einem Datenbank Agent zu sehen. Es wird um 00:00 das gesamte System auf mit Veritas-BE auf einem HP DDS4 DAT gesichert.
-- Beim BE ist werder bei SQL noch bei AdvancedOpenFile irgend etwas eingetragen ?? Möglicherweise werden die DB-Server gestoppt - aber wo sehe ich das ??
-- ausserdem hängt sich diese DAT-Klump relativ häufig auf; dann hilft nicht mal ein reboot - dann muss der Server abgedreht und neu gestartet werden ( DAT-SCSi-Bus hängt - aber das ist eine andere , bekannte Baustelle )
-- ist es bei dieser Backupvariante möglich, die Dantenbanken auf ein anderes ( neues ) System zu übertragen ??
Ich will nun im Notfall den Kunden nicht im Regen stehen lassen und suche für den DB-Server eine Backup lösung die
- auf dem heutigen technischen Stand ist - bitte keine DAT Variante mehr
-- eine Variante die es erlaubt die Daten auch auf einem Ersatzsystem zu restoren
- die ein Emergency Restore des Systems erlaubt - ich bevorzuge da Acronis.
PS:
Ich hoffe das war jetzt nicht zu langatmig.
PPS:
Für jeden gefundenen Rechtschreibfehler bitte 1.-€ an Greenpeace spenden
)
Hi
wenn du BE schon hast: nutze es!
Die Agenten sind für Live Dumps zuständig von minimal, rekuperierend und incrementell, volll,... nicht für das Stoppen/starten der Dienste.
Als Tipp: lass dir eine Einweisung in BE bezahlen wenn du das Tool voll nutzen willst; es ist mit seinen Richtlinien, Vorlagen recht umfangreich und sollte beherrscht werden; wenn du was wartest solltest du auch bezahlt und geschult werden!
Bau dir zwei einfache Batches und lege sie irgendwo einfach ab c:\Ora_start.cmd und ora_stop.cmd als Beispiel; darin bringst du die Befehle zum Dumpen unter (sql+ ....) ODER du stoppst die Dienste net stop "Oracle_hast_du_nicht_gesehen" der Reihe nach; diese beiden Batches fügst du im BE unter Befehle ausführen vor und nach dem Job passend ein. DANN hast du eine konsistente DB und ein voll lauffähiges System danach. Bei mir stehen meist ganze Litaneien mit drinnen von Hol den Dump a von Maschine A und sql export .... Damit kann man auch ohne Zusatzlizenzen eine Menge Sicherheit erreichen.
Nachteil: es dauert bis die Batches unter allen Umständen laufen und die DBs sind während der Zeit typ down. Sofern du in den Batches dumps ziehen läßt ist keine Downtime drinnen. Da ich aber selbst nur DB2 gut kenne und mit pgsql schon einige Jahre "rummache" schätze ich komplettbackups der DB.
DDS (nicht DAT) sollte keiner (mehr) einsetzen; die Billigkeit geht auf Lasten der Zuverlässigkeit; außerdem verschleißen die Bänder zu schnell und das letzte was man braucht beim Disaster Rec sind nicht wiederherstellbare Lesefehler. Das kann dir aber gerade bei HDs auch passieren. Bei BE ist dann gleich bei einem Lesefehler der ganze Block (=Backupsatz) defekt. Tapes machen da wesentlich mehr mit. Wie lange mußt du die Daten aufheben und wie lange Rücksichern?
Da ich 20-30 Jahre lang habe, habe ich sicher ganz andere Anforderungen als du.
Als Imagesoftware nutze ich auch gerne Acronis, dann aber meist offline und nur von der Boot Part. Der Rest wird ja im Backup angegangen.
Mit BE und der oberen Methode sparst du dir auch alles von Hds sicher zu müssen, sondern nur die Nutzdaten.
Wenn BE was ausgegraut hat, heißt dies: Lizenz fehlt. Gerade das macht BE auch so teuer; zwei parallele Jobs mit Advanced File Option kostet auch zwei Lizenzen. Da die V9 noch nicht gut mit VSS umgehen kann, solltest du Acronis parallel für die wichtigen Verzeichnisse/Volumen nutzen.
Für BareMetal ist goscho's angesprochene Lösung durchaus sinnvoll, Ein gebrauchter ColdStandby ist aber meist billiger als sich in ungeübte Bereiche vorzuwagen. Für Acronis Server kann ich dich vermitteln; wie geschrieben sind ab 150EUR zzgl möglich und sehr zu empfehlen.
Gruß
Sam
wenn du BE schon hast: nutze es!
Die Agenten sind für Live Dumps zuständig von minimal, rekuperierend und incrementell, volll,... nicht für das Stoppen/starten der Dienste.
Als Tipp: lass dir eine Einweisung in BE bezahlen wenn du das Tool voll nutzen willst; es ist mit seinen Richtlinien, Vorlagen recht umfangreich und sollte beherrscht werden; wenn du was wartest solltest du auch bezahlt und geschult werden!
Bau dir zwei einfache Batches und lege sie irgendwo einfach ab c:\Ora_start.cmd und ora_stop.cmd als Beispiel; darin bringst du die Befehle zum Dumpen unter (sql+ ....) ODER du stoppst die Dienste net stop "Oracle_hast_du_nicht_gesehen" der Reihe nach; diese beiden Batches fügst du im BE unter Befehle ausführen vor und nach dem Job passend ein. DANN hast du eine konsistente DB und ein voll lauffähiges System danach. Bei mir stehen meist ganze Litaneien mit drinnen von Hol den Dump a von Maschine A und sql export .... Damit kann man auch ohne Zusatzlizenzen eine Menge Sicherheit erreichen.
Nachteil: es dauert bis die Batches unter allen Umständen laufen und die DBs sind während der Zeit typ down. Sofern du in den Batches dumps ziehen läßt ist keine Downtime drinnen. Da ich aber selbst nur DB2 gut kenne und mit pgsql schon einige Jahre "rummache" schätze ich komplettbackups der DB.
DDS (nicht DAT) sollte keiner (mehr) einsetzen; die Billigkeit geht auf Lasten der Zuverlässigkeit; außerdem verschleißen die Bänder zu schnell und das letzte was man braucht beim Disaster Rec sind nicht wiederherstellbare Lesefehler. Das kann dir aber gerade bei HDs auch passieren. Bei BE ist dann gleich bei einem Lesefehler der ganze Block (=Backupsatz) defekt. Tapes machen da wesentlich mehr mit. Wie lange mußt du die Daten aufheben und wie lange Rücksichern?
Da ich 20-30 Jahre lang habe, habe ich sicher ganz andere Anforderungen als du.
Als Imagesoftware nutze ich auch gerne Acronis, dann aber meist offline und nur von der Boot Part. Der Rest wird ja im Backup angegangen.
Mit BE und der oberen Methode sparst du dir auch alles von Hds sicher zu müssen, sondern nur die Nutzdaten.
Wenn BE was ausgegraut hat, heißt dies: Lizenz fehlt. Gerade das macht BE auch so teuer; zwei parallele Jobs mit Advanced File Option kostet auch zwei Lizenzen. Da die V9 noch nicht gut mit VSS umgehen kann, solltest du Acronis parallel für die wichtigen Verzeichnisse/Volumen nutzen.
Für BareMetal ist goscho's angesprochene Lösung durchaus sinnvoll, Ein gebrauchter ColdStandby ist aber meist billiger als sich in ungeübte Bereiche vorzuwagen. Für Acronis Server kann ich dich vermitteln; wie geschrieben sind ab 150EUR zzgl möglich und sehr zu empfehlen.
Gruß
Sam
Dem stimme ich zu.
Für ein Recovery auf anderer Hardware ist das BE aber nicht zu gebrauchen (auch nicht mit IDR).
Da aber der Start der SQL-Server mit dem Script in BE nicht immer funktionierte, habe ich noch einen zusätzlichen Windows-Task angelegt, der allmorgendlich den gestoppten SQL-Server wieder startete (so er es denn nicht schon war).
Wenn du Advanced Open File Option lizenziert hast, kannst du dies auf jedem Server in deinem Netz nutzen. Seit einiger Zeit ist diese Lizenz Bestandteil des Windows Agents.
Dann muss deine Lösung passen.
Daher habe ich bei einigen Kunden (und bei mir) sowohl BESR als auch BE im Einsatz.
Für ein Recovery auf anderer Hardware ist das BE aber nicht zu gebrauchen (auch nicht mit IDR).
Als Tipp: lass dir eine Einweisung in BE bezahlen wenn du das Tool voll nutzen willst; es ist mit seinen Richtlinien, Vorlagen
recht umfangreich und sollte beherrscht werden; wenn du was wartest solltest du auch bezahlt und geschult werden!
Dem stimme ich zu, aber wer schult ihn heute noch in Veritas BE 9?recht umfangreich und sollte beherrscht werden; wenn du was wartest solltest du auch bezahlt und geschult werden!
Bau dir zwei einfache Batches und lege sie irgendwo einfach ab c:\Ora_start.cmd und ora_stop.cmd als Beispiel; darin bringst du
die Befehle zum Dumpen unter (sql+ ....) ODER du stoppst die Dienste net stop "Oracle_hast_du_nicht_gesehen" der Reihe
nach; diese beiden Batches fügst du im BE unter Befehle ausführen vor und nach dem Job passend ein. DANN hast du eine
konsistente DB und ein voll lauffähiges System danach.
Das kenne ich auch, speziell bei diversen SQL-Server-Instanzen, die nicht durch BE zu sichern sind (bspw. DATEV).die Befehle zum Dumpen unter (sql+ ....) ODER du stoppst die Dienste net stop "Oracle_hast_du_nicht_gesehen" der Reihe
nach; diese beiden Batches fügst du im BE unter Befehle ausführen vor und nach dem Job passend ein. DANN hast du eine
konsistente DB und ein voll lauffähiges System danach.
Da aber der Start der SQL-Server mit dem Script in BE nicht immer funktionierte, habe ich noch einen zusätzlichen Windows-Task angelegt, der allmorgendlich den gestoppten SQL-Server wieder startete (so er es denn nicht schon war).
Mit BE und der oberen Methode sparst du dir auch alles von Hds sicher zu müssen, sondern nur die Nutzdaten.
Wenn BE was ausgegraut hat, heißt dies: Lizenz fehlt. Gerade das macht BE auch so teuer; zwei parallele Jobs mit Advanced
File Option kostet auch zwei Lizenzen.
Das habe ich jetzt nicht verstanden?Wenn BE was ausgegraut hat, heißt dies: Lizenz fehlt. Gerade das macht BE auch so teuer; zwei parallele Jobs mit Advanced
File Option kostet auch zwei Lizenzen.
Wenn du Advanced Open File Option lizenziert hast, kannst du dies auf jedem Server in deinem Netz nutzen. Seit einiger Zeit ist diese Lizenz Bestandteil des Windows Agents.
Da die V9 noch nicht gut mit VSS umgehen kann, solltest du Acronis parallel für die
wichtigen Verzeichnisse/Volumen nutzen.
Für BareMetal ist goscho's angesprochene Lösung durchaus sinnvoll, Ein gebrauchter ColdStandby ist aber meist
billiger als sich in ungeübte Bereiche vorzuwagen.
Im Schadenfall stellt sich nicht die Frage, was mal wie billig war. wichtigen Verzeichnisse/Volumen nutzen.
Für BareMetal ist goscho's angesprochene Lösung durchaus sinnvoll, Ein gebrauchter ColdStandby ist aber meist
billiger als sich in ungeübte Bereiche vorzuwagen.
Dann muss deine Lösung passen.
Daher habe ich bei einigen Kunden (und bei mir) sowohl BESR als auch BE im Einsatz.
Hi
Zitat: Für ein Recovery auf anderer Hardware ist das BE aber nicht zu gebrauchen (auch nicht mit IDR).
klar, aber dafür vertraue ich eher auf mein Wissen als auf eine Software.
Zitat: Dem stimme ich zu, aber wer schult ihn heute noch in Veritas BE 9?
Wenn du BE13 gelernt hast ist BE9 auch nur mit weniger Features versehen; die GUI sieht schon sehr ähnlich und vertraut aus und die Jobs sind erst mit V13 etwas aus der alten Art geraten. Eine Waffe (im Althochdtsch Sinne für Werkzeug) ohne Können ist eine Waffe gegen dich... ich habe BE als V4.20 kennengelernt als Herr Seagate sich dafür gefunden hat, da hat sich nur intern was getan; mit dem Wissen von damals kann ich heute noch die Jobs befüllen (gut damals gab es nur die Textlisten für umfangreiche AUfgaben, aber eine simple Auswahl war schon dabei); Der Artenreichtum ist nur umfangreicher geworden
Zitat: zwei parallele Jobs mit Advanced File Option kostet auch zwei Lizenzen
Damit BE zwei Jobs parallel=zur selben Zeit mit AOFO anstartet will er zwei Lizenzkeys haben. Der zweite steht derweil. Die V13 kenne ich bisher nur sehr ungenügend da sich mein alter Arbeitgeber in der BRD aufgelöst hat und sprich keine Schulungen mehr anstehen. Die V12.5 war noch so.
Das BE recht teuer ist gegenüber Acronis oder wenn du sechs kleine Roboter hast mit je zwei Laufwerken, brauchst du 11 Zusatz Lizenzen je 500EUR. Da ich auch Tivoli betreue ist das zwar Grundrauschen, aber andere wie YSB kosten einfach x und haben alles was man will, egal welche Hardware oder wie viele. Wenn man BE wählt (oder besser Symantec) sollte man dies auch im Blick haben. Meine Kollegen lächeln immer über mein BE da dort Netbackup eingesetzt wird (was als großes Novoum Multi Streaming kann).
Zitat: Im Schadenfall stellt sich nicht die Frage, was mal wie billig war.
dazu muß die Hardware erst mal da sein. Defekte Server und dann mal kurzfristig Hardware bekommen (Server+Array) kann schon eine Herausforderung für sich sein; Ich sichere vorher ab, wenn ich eine Verpflichtung eingehe; du wohl auch.
Bei meinen größeren Kunden habe ich mittlerweile auch Amanda und Baclua im Einsatz, da es Endkunden ermöglicht selbst Backups auszuwählen; mit einfacher FAQ und Howto ist das so das ich alle 4 Monate einmal ran muß, gegen vorher 2 mal täglich. Wartung des Systems übernimmt aber auch eine OpenSource Firma (und verdient damit auch gut Geld)
Gruß
Sam
Zitat: Für ein Recovery auf anderer Hardware ist das BE aber nicht zu gebrauchen (auch nicht mit IDR).
klar, aber dafür vertraue ich eher auf mein Wissen als auf eine Software.
Zitat: Dem stimme ich zu, aber wer schult ihn heute noch in Veritas BE 9?
Wenn du BE13 gelernt hast ist BE9 auch nur mit weniger Features versehen; die GUI sieht schon sehr ähnlich und vertraut aus und die Jobs sind erst mit V13 etwas aus der alten Art geraten. Eine Waffe (im Althochdtsch Sinne für Werkzeug) ohne Können ist eine Waffe gegen dich... ich habe BE als V4.20 kennengelernt als Herr Seagate sich dafür gefunden hat, da hat sich nur intern was getan; mit dem Wissen von damals kann ich heute noch die Jobs befüllen (gut damals gab es nur die Textlisten für umfangreiche AUfgaben, aber eine simple Auswahl war schon dabei); Der Artenreichtum ist nur umfangreicher geworden
Zitat: zwei parallele Jobs mit Advanced File Option kostet auch zwei Lizenzen
Damit BE zwei Jobs parallel=zur selben Zeit mit AOFO anstartet will er zwei Lizenzkeys haben. Der zweite steht derweil. Die V13 kenne ich bisher nur sehr ungenügend da sich mein alter Arbeitgeber in der BRD aufgelöst hat und sprich keine Schulungen mehr anstehen. Die V12.5 war noch so.
Das BE recht teuer ist gegenüber Acronis oder wenn du sechs kleine Roboter hast mit je zwei Laufwerken, brauchst du 11 Zusatz Lizenzen je 500EUR. Da ich auch Tivoli betreue ist das zwar Grundrauschen, aber andere wie YSB kosten einfach x und haben alles was man will, egal welche Hardware oder wie viele. Wenn man BE wählt (oder besser Symantec) sollte man dies auch im Blick haben. Meine Kollegen lächeln immer über mein BE da dort Netbackup eingesetzt wird (was als großes Novoum Multi Streaming kann).
Zitat: Im Schadenfall stellt sich nicht die Frage, was mal wie billig war.
dazu muß die Hardware erst mal da sein. Defekte Server und dann mal kurzfristig Hardware bekommen (Server+Array) kann schon eine Herausforderung für sich sein; Ich sichere vorher ab, wenn ich eine Verpflichtung eingehe; du wohl auch.
Bei meinen größeren Kunden habe ich mittlerweile auch Amanda und Baclua im Einsatz, da es Endkunden ermöglicht selbst Backups auszuwählen; mit einfacher FAQ und Howto ist das so das ich alle 4 Monate einmal ran muß, gegen vorher 2 mal täglich. Wartung des Systems übernimmt aber auch eine OpenSource Firma (und verdient damit auch gut Geld)
Gruß
Sam
