18
Symantec Backup Exec 2010 R3 sehr langsame Sicherung
Windows Server 2003 Standard SP2, Symantec Backup Exec 2010 R2 Version 13.0 mit allen Updates und Hotfixes
Hallo zusammen,
aktuell sieht unser Backup-Konzept so aus, dass wir jeden Tag eine Vollsicherung erstellen. Dadurch, dass damit sehr viel Zeit und Festplattenkapazität beansprucht wird, will ich dies nun auf ein Differential-Backup umstellen.
Nun gibt es hier die Möglichkeit, für einen Vergleich mit dem Archivbit zu arbeiten. Dies ist meine favorisierte Option, wenn sie denn funktionieren würde.
Bei einer Vollsicherung beträgt die Auftragsrate im Durchschnitt >800 MB/Min. Wenn ich die Differentialsicherung ausführe, beträgt die Auftragsrate <100 MB/Min. Von der Geschwindigkeit ist die Differentialsicherung also 8x so langsam wie eine Vollsicherung.
Ist dieses Verhalten normal, da hier geprüft werden muss, ob das Archivbit gesetzt ist?
Ich habe mal testhalber die Option "Mit geänderter Uhrzeit" anstelle der Verwendung des Archivbits eingestellt. Hier beträgt die Auftragsrate wieder zwischen 300 und 400 MB/Min (die obige Durchschnittsauftragsrate kommt so hoch, da mit sehr hoher Geschwindigkeit das Backup geprüft wird), was so dem Normalfall beschreibt.
Kann mir jemand sagen, warum die Verwendung des Archivbits solche Performanceprobleme mit sich zieht?
Hallo zusammen,
aktuell sieht unser Backup-Konzept so aus, dass wir jeden Tag eine Vollsicherung erstellen. Dadurch, dass damit sehr viel Zeit und Festplattenkapazität beansprucht wird, will ich dies nun auf ein Differential-Backup umstellen.
Nun gibt es hier die Möglichkeit, für einen Vergleich mit dem Archivbit zu arbeiten. Dies ist meine favorisierte Option, wenn sie denn funktionieren würde.
Bei einer Vollsicherung beträgt die Auftragsrate im Durchschnitt >800 MB/Min. Wenn ich die Differentialsicherung ausführe, beträgt die Auftragsrate <100 MB/Min. Von der Geschwindigkeit ist die Differentialsicherung also 8x so langsam wie eine Vollsicherung.
Ist dieses Verhalten normal, da hier geprüft werden muss, ob das Archivbit gesetzt ist?
Ich habe mal testhalber die Option "Mit geänderter Uhrzeit" anstelle der Verwendung des Archivbits eingestellt. Hier beträgt die Auftragsrate wieder zwischen 300 und 400 MB/Min (die obige Durchschnittsauftragsrate kommt so hoch, da mit sehr hoher Geschwindigkeit das Backup geprüft wird), was so dem Normalfall beschreibt.
Kann mir jemand sagen, warum die Verwendung des Archivbits solche Performanceprobleme mit sich zieht?
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: 170059
Url: https://administrator.de/forum/symantec-backup-exec-2010-r3-sehr-langsame-sicherung-170059.html
Ausgedruckt am: 23.12.2024 um 10:12 Uhr
18 Kommentare
Neuester Kommentar
Hi,
wir machen das wie folgt: benutzen auch sbs 2003 aber Acronis Serverversion zur Sicherung. einmal im Monat Vollsicherung am Wochenende, Mo-Fr jeweils abends ab 20:00 Uhr Differential_Backup. Ich lasse die Backups immer ausserhalb der Produktivzeiten laufen um eine Netzwerkbelastung zu vermeiden.
Eigentlich läuft das Differential_Backup wesentlich schneller als das Vollbackup weil ja nur veränderte Daten gesichert werden ??
Vielleicht ist zuviel Betrieb in Eurem Netzwerk ? Denn das Differential mus ja nach geänderten Daten schauen und wenn mehrere 100 User arbeiten kann das dauern. Mann nennt das Backup während der Arbeitszeit auch HOT_BACKUP und wird von den Herstellern der Backup_Software nicht unbedingt empfohlen.
Hoffentlich hilfts ein bisschen
mfg
wir machen das wie folgt: benutzen auch sbs 2003 aber Acronis Serverversion zur Sicherung. einmal im Monat Vollsicherung am Wochenende, Mo-Fr jeweils abends ab 20:00 Uhr Differential_Backup. Ich lasse die Backups immer ausserhalb der Produktivzeiten laufen um eine Netzwerkbelastung zu vermeiden.
Eigentlich läuft das Differential_Backup wesentlich schneller als das Vollbackup weil ja nur veränderte Daten gesichert werden ??
Vielleicht ist zuviel Betrieb in Eurem Netzwerk ? Denn das Differential mus ja nach geänderten Daten schauen und wenn mehrere 100 User arbeiten kann das dauern. Mann nennt das Backup während der Arbeitszeit auch HOT_BACKUP und wird von den Herstellern der Backup_Software nicht unbedingt empfohlen.
Hoffentlich hilfts ein bisschen
mfg
Hi,
langsamer ist das bei mir auch, kann ja auch gut sein, da BE ja erstmal alle Dateien angucken muss, und auch die Verzeichnisse anlegen muss, auch wenn dann nichts drinsteht. Allerdings trifft das auch auf die Uhrzeit zu.
Beim Vollbackup kann BE ja einfach alles draufkloppen.
Allerdings habe ich "nur" Faktor 2-4 langsamer, aber dafür auch viel weniger Daten.
Aber Aussagen zur Geschwindigkeit sind immer recht schwer zu vergleichen ....
Hast du Support?
Wenn ja, dann frage doch mal die Inder
VG
Markus
langsamer ist das bei mir auch, kann ja auch gut sein, da BE ja erstmal alle Dateien angucken muss, und auch die Verzeichnisse anlegen muss, auch wenn dann nichts drinsteht. Allerdings trifft das auch auf die Uhrzeit zu.
Beim Vollbackup kann BE ja einfach alles draufkloppen.
Allerdings habe ich "nur" Faktor 2-4 langsamer, aber dafür auch viel weniger Daten.
Aber Aussagen zur Geschwindigkeit sind immer recht schwer zu vergleichen ....
Hast du Support?
Wenn ja, dann frage doch mal die Inder
VG
Markus
Ähm, war das vor dem R3 denn schneller?
Sonst date ich besser noch nicht ab
Sonst date ich besser noch nicht ab
Ich glaube mit dem R3 habe ich mich da etwas verguckt. Ich hätte schwören können, dass mir im LiveUpdate der R3 angeboten wurde, installiert ist aber noch der R2.
Die Datenmenge ist unterschiedlich.. Der Server um den es geht, hat insgesamt 250GB.
Ich habe nochmal einen komplett neuen Job mit eigener Auswahlliste erstellt und auf diese AL ebenfall die Differential-Sicherung konfiguriert. Aber auch hier liegt die Durchschnittsauftragsrate vom Job Insgesamt bei 25 MB/Min.
Bei der dazugehörigen Vollsicherung betrug die Rate 831 MB/Min.
Dass es langsamer ist, ist klar, weil er schließlich prüfen muss.. aber so langsam?
Support habe ich leider keinen, daher die Anfrage hier im Forum
@101238: Die Differentialsicherung lief heute Nacht ab 0 Uhr, hier war niemand (oder kaum jemand) im Netz bzw. auf dem Fileserver unterwegs
Die Datenmenge ist unterschiedlich.. Der Server um den es geht, hat insgesamt 250GB.
Ich habe nochmal einen komplett neuen Job mit eigener Auswahlliste erstellt und auf diese AL ebenfall die Differential-Sicherung konfiguriert. Aber auch hier liegt die Durchschnittsauftragsrate vom Job Insgesamt bei 25 MB/Min.
Bei der dazugehörigen Vollsicherung betrug die Rate 831 MB/Min.
Dass es langsamer ist, ist klar, weil er schließlich prüfen muss.. aber so langsam?
Support habe ich leider keinen, daher die Anfrage hier im Forum
@101238: Die Differentialsicherung lief heute Nacht ab 0 Uhr, hier war niemand (oder kaum jemand) im Netz bzw. auf dem Fileserver unterwegs
Ich glaube mit dem R3 habe ich mich da etwas verguckt. Ich hätte schwören können, dass mir im LiveUpdate der R3
angeboten wurde, installiert ist aber noch der R2.
angeboten wurde, installiert ist aber noch der R2.
Das stimmt schon, nur nicht ganz
Das LiveUpdate zeigt dir an das das R3 verfügbar ist, nur musst du es manuell installieren ...
Dass es langsamer ist, ist klar, weil er schließlich prüfen muss.. aber so langsam?
Finde ich aber auch zu langsam .... aber warum ??
Sind das denn Millionen von kleinen Dateien, oder eher die dicken (> 2 MB)??
Support habe ich leider keinen, daher die Anfrage hier im Forum
Den Support kann ich auch nicht wirklich empfehlen, aber du hast damit die Möglichkeit immer auf die neuste Version upzudaten.
Ich weiß nicht ob du auf die R3 updaten darft, wenn die neue Lizenz-Schlüssel braucht, dann geht das nicht.
Das steht aber in der Release Info.
Zitat von @Deepsys:
Das stimmt schon, nur nicht ganz
Das LiveUpdate zeigt dir an das das R3 verfügbar ist, nur musst du es manuell installieren ...
Das stimmt schon, nur nicht ganz
Das LiveUpdate zeigt dir an das das R3 verfügbar ist, nur musst du es manuell installieren ...
Okay, dann habe ich mich doch nicht geirrt
Finde ich aber auch zu langsam .... aber warum ??
Sind das denn Millionen von kleinen Dateien, oder eher die dicken (> 2 MB)??
Also es sind schon ziemlich viele Dateien. Dadurch, dass dies unser Fileserver ist und viele Verwaltungsstellen mit diesem arbeiten wächst das Datenvolumen schon Mal an. Aktuell sind es wie schon erwähnt 252 GB. Dies entspricht etwa über 400.000 Dateien und über 55.000 Ordnern.
Komisch ist hier halt auch, dass die Methode mit dem Zeitstempelvergleich wesentlich schneller geht. Ich als Mensch würde sagen, dass die Methode mit dem Archivbit schneller geht, da beim Vergleich mit dem Zeitstempel eine Datenbank abgefragt werden muss. Beim Archivbit muss "nur" das Attribut abgefragt werden.
Servus,
Das kann schon möglich sein das eine Differenzialsicherung oder Zuwachssicherung länger braucht als eine Vollsicherung. Ist immer abhängig von folgenden
Dateistruktur: Um so tiefer verzweigt um so mehr ist es für BE mühsam die durch zu suchen
Files: Kleines Files dauern in normal Fall immer länger.. Netzwer Request
Bei der Zuwachssicherung wird auch geschaut welches File ein Archivbit gesetzt bekommen hat -< also viel intensiver. als bei einen Vollbackup. Da heisst es nur sichern was das Zeug hält...
lg Lykantroph
Das kann schon möglich sein das eine Differenzialsicherung oder Zuwachssicherung länger braucht als eine Vollsicherung. Ist immer abhängig von folgenden
Dateistruktur: Um so tiefer verzweigt um so mehr ist es für BE mühsam die durch zu suchen
Files: Kleines Files dauern in normal Fall immer länger.. Netzwer Request
Bei der Zuwachssicherung wird auch geschaut welches File ein Archivbit gesetzt bekommen hat -< also viel intensiver. als bei einen Vollbackup. Da heisst es nur sichern was das Zeug hält...
lg Lykantroph
Hallo zusammen,
nachdem ich nun 2 Server von Backup Exec 2010 R2 auf R3 (incl. aller aktuellen Hotfixe) upgedatet habe, kann ich sagen:
- Keine Problem beim Update; nur der Medienserver muss neustartet, die Agenten nicht
- R3 ist um einiges schneller; z.B. Exchange-Sicherung 101GB von 00:45 / 3GB/min auf 00:38 / 4,3GB/min, auch die Diff-Sicherung (118GB) ist schneller (von 1:33 1,4GB/min auf 1:08 2,1GB/min) (beide auf Disk)
Lohnt sich !
nachdem ich nun 2 Server von Backup Exec 2010 R2 auf R3 (incl. aller aktuellen Hotfixe) upgedatet habe, kann ich sagen:
- Keine Problem beim Update; nur der Medienserver muss neustartet, die Agenten nicht
- R3 ist um einiges schneller; z.B. Exchange-Sicherung 101GB von 00:45 / 3GB/min auf 00:38 / 4,3GB/min, auch die Diff-Sicherung (118GB) ist schneller (von 1:33 1,4GB/min auf 1:08 2,1GB/min) (beide auf Disk)
Lohnt sich !
Zitat von @Deepsys:
Hallo zusammen,
nachdem ich nun 2 Server von Backup Exec 2010 R2 auf R3 (incl. aller aktuellen Hotfixe) upgedatet habe, kann ich sagen:
- Keine Problem beim Update; nur der Medienserver muss neustartet, die Agenten nicht
- R3 ist um einiges schneller; z.B. Exchange-Sicherung 101GB von 00:45 / 3GB/min auf 00:38 / 4,3GB/min, auch die Diff-Sicherung
(118GB) ist schneller (von 1:33 1,4GB/min auf 1:08 2,1GB/min) (beide auf Disk)
Lohnt sich !
Hallo zusammen,
nachdem ich nun 2 Server von Backup Exec 2010 R2 auf R3 (incl. aller aktuellen Hotfixe) upgedatet habe, kann ich sagen:
- Keine Problem beim Update; nur der Medienserver muss neustartet, die Agenten nicht
- R3 ist um einiges schneller; z.B. Exchange-Sicherung 101GB von 00:45 / 3GB/min auf 00:38 / 4,3GB/min, auch die Diff-Sicherung
(118GB) ist schneller (von 1:33 1,4GB/min auf 1:08 2,1GB/min) (beide auf Disk)
Lohnt sich !
Servus Deepsys,
Ich denke mal du sicherst Exchange ohne GRT ansonsten würdest du auf nicht so einen Wert kommen. Hast du nach den Update auf R3 keine Probleme mit die Deduplizierungs Services gehabt. Bei mir ist der konkret der Fall das nach einspielen dieses Updates der Dedup Engine Service nicht mehr hoch kommt.
lg
Lykantroph
Hallo Lykantroph,
doch ich sicher mit GRT ... Aber eben zuerst auf Platte und dann auf Band und immer ein Vollbackup.
Und der Exchange-Server ist eine VM mit FC-SAN.
Die Dedup Option nutzte ich noch nicht, so recht war mir nicht klar was mir das bringen soll.
VG
Deepsys
doch ich sicher mit GRT ... Aber eben zuerst auf Platte und dann auf Band und immer ein Vollbackup.
Und der Exchange-Server ist eine VM mit FC-SAN.
Die Dedup Option nutzte ich noch nicht, so recht war mir nicht klar was mir das bringen soll.
VG
Deepsys
Servus Deepsys,
Wow 3Gb / Min is geil, wir fahren mit 1GB / Min bei 250 GB DB Grösse also... Rauschebartverdächtig Wieviel hattest du vor Einspielen von R3?
Die Deduboption bringt dir einfach den Vorteil das du auf deiner Storage Appliance nicht so viel Speicherplatz verbratest. D.h. bei redudante Dateien oder auch Blöcke wird die Datei nur einmal gesichert und die redundanten bekommen einen Link auf diese Datei. Aber Achtung Dedub sollte man nur Medienserverseitig machen und nicht Clientseitig da z.b. der Fileserver dann ziemlich viel CPU verbratet und das Backu Fenster sich dadurch erhöhen kann.
lg
Lykantroph
Wow 3Gb / Min is geil, wir fahren mit 1GB / Min bei 250 GB DB Grösse also... Rauschebartverdächtig
Wieviel hattest du vor Einspielen von R3?Die Deduboption bringt dir einfach den Vorteil das du auf deiner Storage Appliance nicht so viel Speicherplatz verbratest. D.h. bei redudante Dateien oder auch Blöcke wird die Datei nur einmal gesichert und die redundanten bekommen einen Link auf diese Datei. Aber Achtung Dedub sollte man nur Medienserverseitig machen und nicht Clientseitig da z.b. der Fileserver dann ziemlich viel CPU verbratet und das Backu Fenster sich dadurch erhöhen kann.
lg
Lykantroph
Hi,
Ähm, das war mit R2, R3 schafft 4,3GB/Min
Ah, ok, danke.
Werde ich mir doch mal später antun, obwohl wenn das Ding unter R3 nicht startet ...
Wow 3Gb / Min is geil, wir fahren mit 1GB / Min bei 250 GB DB Grösse also... Rauschebartverdächtig Wieviel hattest
du vor Einspielen von R3?
Wieviel hattestdu vor Einspielen von R3?
Ähm, das war mit R2, R3 schafft 4,3GB/Min
| Name | Gerätename | Auftragstyp | Auftragsstatus | Startzeit | Endzeitpunkt | Verstrichene Zeit | Byte (Anzahl) | Auftragsrate |
| Exchange - Disk- Gesamt | B2D-05 (Exchange) | Backup | Erfolgreich | 02.08.2011 22:00:01 | 02.08.2011 22:38:09 | 0:38:08 | 101.600.302.916 | 4.361,00 MB/min |
Die Deduboption bringt dir einfach den Vorteil das du auf deiner Storage Appliance nicht so viel Speicherplatz verbratest. D.h.
bei redudante Dateien oder auch Blöcke wird die Datei nur einmal gesichert und die redundanten bekommen einen Link auf diese
Datei. Aber Achtung Dedub sollte man nur Medienserverseitig machen und nicht Clientseitig da z.b. der Fileserver dann ziemlich
viel CPU verbratet und das Backu Fenster sich dadurch erhöhen kann.
bei redudante Dateien oder auch Blöcke wird die Datei nur einmal gesichert und die redundanten bekommen einen Link auf diese
Datei. Aber Achtung Dedub sollte man nur Medienserverseitig machen und nicht Clientseitig da z.b. der Fileserver dann ziemlich
viel CPU verbratet und das Backu Fenster sich dadurch erhöhen kann.
Ah, ok, danke.
Werde ich mir doch mal später antun, obwohl wenn das Ding unter R3 nicht startet ...
Ist halt die Frage ... wenn du es nicht eingesetzt hat sind die 2 Services eh auf manuell und gestoppt. Ich hab es laufen und beim Update auf R3 kam ich nicht einmal zur Logon Maske von Windoes. Gut war das ich über UNC auf diesen Server drauf kam und die Datei von diesen Service unbenannte danach Kaltstart und dann hat es auch das Anmelden wieder funktioniert. Jedoch Dedub ist deaktivert.
lg
Lykantroph
lg
Lykantroph
Hi Deespy,
Also ich habe jetzt auch R3 mit den aktuellen Patchstand eingespielt jedoch kann ich nicht wirklich eine Performance Verbesserung bei der GRT Sicherung von Exchange feststellen.
Daher meine Frage an dich: Ist dein Backup 2 Disk Ordner für Exchange auf einen Raid 1 Laufwerk oder Raid 5. Hast du hier in den Backup Einstellungen Speicherplatz zugewiesen?. Normalerweise braucht man speziell bei der Exchange GRT Sicherung keinen Speicherplatz zuweisen.
Danke und lg
Lykantroph
Also ich habe jetzt auch R3 mit den aktuellen Patchstand eingespielt jedoch kann ich nicht wirklich eine Performance Verbesserung bei der GRT Sicherung von Exchange feststellen.
Daher meine Frage an dich: Ist dein Backup 2 Disk Ordner für Exchange auf einen Raid 1 Laufwerk oder Raid 5. Hast du hier in den Backup Einstellungen Speicherplatz zugewiesen?. Normalerweise braucht man speziell bei der Exchange GRT Sicherung keinen Speicherplatz zuweisen.
Danke und lg
Lykantroph
Hi,
Das sehe ich aber komplett anders.
Ich würde da immer schon mal Platz reservieren, das kostet zwar Plattenplatz, ist aber auch schneller:
Maximale Größe: 1GB
Maximale Größe für B2D- Dateien zuordnen = Ja
Max 5 Gleichzeitge Auträge
Was auch noch Wunder wirkt: Defragmentier mal die Platte
VG
Deepsys
Daher meine Frage an dich: Ist dein Backup 2 Disk Ordner für Exchange auf einen Raid 1 Laufwerk oder Raid 5.
Das ist ein RAID 5 aus 6x 2TB SATA II Platten an einem IBM (LSI) ServeRAID M5014Hast du hier in den Backup Einstellungen Speicherplatz zugewiesen?. Normalerweise braucht man speziell bei der Exchange GRT Sicherung keinen
Speicherplatz zuweisen.
Speicherplatz zuweisen.
Das sehe ich aber komplett anders.
Ich würde da immer schon mal Platz reservieren, das kostet zwar Plattenplatz, ist aber auch schneller:
Maximale Größe: 1GB
Maximale Größe für B2D- Dateien zuordnen = Ja
Max 5 Gleichzeitge Auträge
Was auch noch Wunder wirkt: Defragmentier mal die Platte
VG
Deepsys
Ich habe heute auch auf R3 geupdatet. Aufgrund der Tatsache, dass ich Exchange 2010 DAG's nicht mit einem 32Bit-Server sichern kann, habe ich den Backupserver komplett neu aufgesetzt (Windows Server 2008 R2 x64).
Nun habe ich die ersten neuen Jobs (komplett neu eingerichtet) laufen lassen wollen und merke, dass die Festplatte nach wenigen Sekunden vollläuft!! von 2TB sind anfangs noch 500GB frei (was so in Ordnung ist) und sobald ich nur einen Job starte, läuft die Festplatte sofort voll. Nirgends auf der Platte sind Daten in der Größenordnung vorhanden, die die Platte zum überlaufen bringen!
Die laufenden Jobs lassen sich auch nicht mehr abbrechen, nur ein Serverneustart hilft.
Nach einem Serverneustart ist der Plattenplatz wieder frei und die Jobs stehen mit einem Abbruchfehler in der Auftragsliste.
Weiß hier jemand vielleicht kurzfristig rat??
EDIT: hat sich erledigt, war ein Haken in den Backup-to-Disk Ordnern zuviel!!
Nun habe ich die ersten neuen Jobs (komplett neu eingerichtet) laufen lassen wollen und merke, dass die Festplatte nach wenigen Sekunden vollläuft!! von 2TB sind anfangs noch 500GB frei (was so in Ordnung ist) und sobald ich nur einen Job starte, läuft die Festplatte sofort voll. Nirgends auf der Platte sind Daten in der Größenordnung vorhanden, die die Platte zum überlaufen bringen!
Die laufenden Jobs lassen sich auch nicht mehr abbrechen, nur ein Serverneustart hilft.
Nach einem Serverneustart ist der Plattenplatz wieder frei und die Jobs stehen mit einem Abbruchfehler in der Auftragsliste.
Weiß hier jemand vielleicht kurzfristig rat??
EDIT: hat sich erledigt, war ein Haken in den Backup-to-Disk Ordnern zuviel!!
Hallo Niggel,
Sieht man in den Backup To Disk Ordner das Files geschrieben werden?. Die Services kannst normal auch übern Taskmanager killen.
lg
Lykantroph
Sieht man in den Backup To Disk Ordner das Files geschrieben werden?. Die Services kannst normal auch übern Taskmanager killen.
lg
Lykantroph
das hat sich erledigt
haber aber gerade ein anderes problem: Auf unserem alten exchange (2003) war die alte version vom remote agent installiert. das backup lief aber mit der R3 version trotzdem, allerdings mit dem hinweis, dass der agent geupdatet werden muss.
da ich den server nicht oft neustarten kann, habe ich das erst mal rausgezögert. heute hatte der exchange ein problem und musste neugestartet werden. nach dem neustart läuft das backup nicht mehr.
ich habe also die möglichkeit genutzt, den alten agent zu deinstallieren:
über die systemsteuerung habe ich die deinstallation angestoßen. diese ist mit der aussage "schwerwiegender fehler bei der installation" abgebrochen. nach erneutem "deinstallieren", ist der eintrag aus der software-liste auch verschwunden. der dienst "BackupExecAgentAccelerator" allerdings war noch vorhanden und gestartet. ich habe den dienst also manuell mit dem "sc" befehl deinstalliert und das system neugestartet.
nach dem neustart habe ich die push-installation über den medienserver angestoßen, welche auch erfolgreich abgeschlossen wurde.
auf dem exchange allerdings fehlt der dienst für den remote agent, dieser ist nicht installiert worden (lediglich der dienst "Backup Exec Error Recording Service" ist installiert und gestartet)!
der medienserver findet demnach auch den remote-server nicht... in der serverliste in der auswahl ist auch nicht das orangene symbol dargestellt, welches anzeigt, ob ein remote-agent vorhanden ist. der job schlägt mit folgender meldung auch fehl:
"Der Medienserver konnte keine Verbindung zum remoten Server herstellen. Der remote Computer ist möglicherweise auf dem ausgewählten Subnetz nicht vorhanden. Wählen Sie eine andere Netzwerkschnittstelle oder lassen Sie eine beliebige verfügbare Netzwerkschnittstelle von Backup Exec auswählen.
Endgültige Fehlerkategorie: Ressourcenfehler"
ich habe auch schon erneut alles gelöscht, was mit symantec zu tun hat, auch was die registry angeht (die deinstallation des agents über die systemsteuerng verlief diesmal ohne probleme).
es ist nichts mehr auf dem system, was mit symantec zu tun hat. selbst wenn jetzt die push-installation erneut läuft, funktioniert es nicht
mir kommt es auch so vor, als ob die push-installation sehr schnell geht. normalerweise dauert sie ca. 3 minuten oder so. in dem fall nun aber keine einzige minute, eher eine halbe.
wenn ich nun erneut den assistenen für die installation der agents aufrufe, bekomme ich angezeigt, dass die installation gestartet werden kann. auch hier erkennt er nicht, dass der agent bereits isntalliert ist. führe ich die installation erneut durch, kopiert er erst die ganzen dateien und dann erscheint die fehlermeldung:
- Installation fehlgeschlagen mit Fehlercode 1603
ich habe auch schon probiert, die "beremote.exe" manuell zu starten und anschließend den job auszuführen. selbst das führt zur fehlermeldung, dass der medienserver den remote-server nicht finden kann.
kann mir hier noch jemand einen entscheidenden tipp geben??
haber aber gerade ein anderes problem: Auf unserem alten exchange (2003) war die alte version vom remote agent installiert. das backup lief aber mit der R3 version trotzdem, allerdings mit dem hinweis, dass der agent geupdatet werden muss.
da ich den server nicht oft neustarten kann, habe ich das erst mal rausgezögert. heute hatte der exchange ein problem und musste neugestartet werden. nach dem neustart läuft das backup nicht mehr.
ich habe also die möglichkeit genutzt, den alten agent zu deinstallieren:
über die systemsteuerung habe ich die deinstallation angestoßen. diese ist mit der aussage "schwerwiegender fehler bei der installation" abgebrochen. nach erneutem "deinstallieren", ist der eintrag aus der software-liste auch verschwunden. der dienst "BackupExecAgentAccelerator" allerdings war noch vorhanden und gestartet. ich habe den dienst also manuell mit dem "sc" befehl deinstalliert und das system neugestartet.
nach dem neustart habe ich die push-installation über den medienserver angestoßen, welche auch erfolgreich abgeschlossen wurde.
auf dem exchange allerdings fehlt der dienst für den remote agent, dieser ist nicht installiert worden (lediglich der dienst "Backup Exec Error Recording Service" ist installiert und gestartet)!
der medienserver findet demnach auch den remote-server nicht... in der serverliste in der auswahl ist auch nicht das orangene symbol dargestellt, welches anzeigt, ob ein remote-agent vorhanden ist. der job schlägt mit folgender meldung auch fehl:
"Der Medienserver konnte keine Verbindung zum remoten Server herstellen. Der remote Computer ist möglicherweise auf dem ausgewählten Subnetz nicht vorhanden. Wählen Sie eine andere Netzwerkschnittstelle oder lassen Sie eine beliebige verfügbare Netzwerkschnittstelle von Backup Exec auswählen.
Endgültige Fehlerkategorie: Ressourcenfehler"
ich habe auch schon erneut alles gelöscht, was mit symantec zu tun hat, auch was die registry angeht (die deinstallation des agents über die systemsteuerng verlief diesmal ohne probleme).
es ist nichts mehr auf dem system, was mit symantec zu tun hat. selbst wenn jetzt die push-installation erneut läuft, funktioniert es nicht
mir kommt es auch so vor, als ob die push-installation sehr schnell geht. normalerweise dauert sie ca. 3 minuten oder so. in dem fall nun aber keine einzige minute, eher eine halbe.
wenn ich nun erneut den assistenen für die installation der agents aufrufe, bekomme ich angezeigt, dass die installation gestartet werden kann. auch hier erkennt er nicht, dass der agent bereits isntalliert ist. führe ich die installation erneut durch, kopiert er erst die ganzen dateien und dann erscheint die fehlermeldung:
- Installation fehlgeschlagen mit Fehlercode 1603
ich habe auch schon probiert, die "beremote.exe" manuell zu starten und anschließend den job auszuführen. selbst das führt zur fehlermeldung, dass der medienserver den remote-server nicht finden kann.
kann mir hier noch jemand einen entscheidenden tipp geben??
