11
Simple Frage an alle ARCserve Anwender
Hi,
dieses ArcServe macht mich noch wahnsinnig...
Wie kann man VOR dem Beginn der Sicherung erfahren, WELCHES Band verlangt wird?
ArcServe r11.5 SP3 mit einer konfigurierten GFS Sicherung.
Folgendes ist (wieder mal) passiert:
Der vergangene Freitag war der 27.11.2009 (der letzte Tag der Woche), heute ist Montag der 30.11.2009 (der letzte Tag im Monat)
Ordnungsgemäss hat der Sicherungs-Operator am Freitag ein "Weekly" Band eingelegt, denn es war ja Freitag, der letzte Tag der Woche. Heute sehen wir, dass ArcServe ein Monthly" Band verlangt hat!
Mich interessiert gar nicht das WARUM, nach meinem Ermessen ist das völliger Blödsinn. Ich will einfach nur, dass vorhersehbar ist, WELCHES Band diese verfluchte ArcServe bei der nächsten anstehenden Sicherung haben möchte!
Ich habe mir ausführlich die Doku zu allen ca_*.exe Befehlen angesehen. Keiner davon gibt das her. Im Gegenteil: Die Tools scheinen von Praktikanten entworfen zu sein und sind teilweise völlig praxisfern (z.B. ca_log.exe)
BITTE: Falls irgendwer einen kleinen Tipp hat oder einen Workaround, wie ihr das Problem löst, immer her damit.
PS: Google und die CA-Support Seiten geben nichts dazu her. Als ob ich der Einzige bin, der sich so blöd anstellt :-?
dieses ArcServe macht mich noch wahnsinnig...
Wie kann man VOR dem Beginn der Sicherung erfahren, WELCHES Band verlangt wird?
ArcServe r11.5 SP3 mit einer konfigurierten GFS Sicherung.
Folgendes ist (wieder mal) passiert:
Der vergangene Freitag war der 27.11.2009 (der letzte Tag der Woche), heute ist Montag der 30.11.2009 (der letzte Tag im Monat)
Ordnungsgemäss hat der Sicherungs-Operator am Freitag ein "Weekly" Band eingelegt, denn es war ja Freitag, der letzte Tag der Woche. Heute sehen wir, dass ArcServe ein Monthly" Band verlangt hat!
Mich interessiert gar nicht das WARUM, nach meinem Ermessen ist das völliger Blödsinn. Ich will einfach nur, dass vorhersehbar ist, WELCHES Band diese verfluchte ArcServe bei der nächsten anstehenden Sicherung haben möchte!
Ich habe mir ausführlich die Doku zu allen ca_*.exe Befehlen angesehen. Keiner davon gibt das her. Im Gegenteil: Die Tools scheinen von Praktikanten entworfen zu sein und sind teilweise völlig praxisfern (z.B. ca_log.exe)
BITTE: Falls irgendwer einen kleinen Tipp hat oder einen Workaround, wie ihr das Problem löst, immer her damit.
PS: Google und die CA-Support Seiten geben nichts dazu her. Als ob ich der Einzige bin, der sich so blöd anstellt :-?
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: 130568
Url: https://administrator.de/forum/simple-frage-an-alle-arcserve-anwender-130568.html
Ausgedruckt am: 26.12.2024 um 01:12 Uhr
11 Kommentare
Neuester Kommentar
Hallo,
ArcServe verlangt am Freitag normalerweise die "Weekly" Datenträger, ausser es ist der letzte Freitag des Monats. dann wird natürlich das "Monthly" verwendet. Ist irgendwo in der Hilfe beschrieben. das kann aber auch im "Planer"? (habe kein ArcServe mehr zur hand) nachgeschaut werden. Dort werden doch die geplanten Sicherung und deren Art (Daily, Weekly, Monthly) angezeigt.
Peter
ArcServe verlangt am Freitag normalerweise die "Weekly" Datenträger, ausser es ist der letzte Freitag des Monats. dann wird natürlich das "Monthly" verwendet. Ist irgendwo in der Hilfe beschrieben. das kann aber auch im "Planer"? (habe kein ArcServe mehr zur hand) nachgeschaut werden. Dort werden doch die geplanten Sicherung und deren Art (Daily, Weekly, Monthly) angezeigt.
Peter
nunja, Freitag ist (normalerweise) weekly, das stimmt schon. Allerdings (so schätze ich mal) wird dein GFS so konfiguriert sein, dass nur weekly-sicherungen auch monthly-sicherungen sein können. Demnach war der am Freitag laufende Job ein Monthly-job für november, weil der nächste Termin im Dezember stattgefunden hätte müssen, was ja dann nicht mehr November ist. Verstanden? 
Danke (euch beiden) für die schnelle Antwort
"Verstanden" wäre zu viel gesagt. Aber wie erwähnt, es ist mir schnuppe, *warum* ArcServe meint, monatliche Sicherungen nur Freitags ausführen zu müssen. Egal aus elchem Grund und egal was die Jungs bei CA rauchen:
Woher weiss ich *VOR* der Sicherung (die ja nachts abläuft, wenn niemand da ist, um ArcServe das Händchen zu halten) welches Band verlangt werden wird.
Es kann doch nicht gängige Praxis sein, sich täglich auf dem Backup-Server einzuloggen, das ArcServe Management zu starten und dann auf "Job ändern" gehen, um zu sehen, welches Band morgen dran ist???
Ich habe mir ein Script geschrieben:
Den Output lasse ich mir per Mail schicken. So kriege ich zumindest raus, welche Bänder im Arbeitssatz sind, also verlangt werden *könnten*. Nun muss ich "nur" noch in den Kalender gucken um rauszukriegen, ob es Daily, Weekly oder Monthly ist. Aber an solchen Tagen wie am Freitag geht das eben total in die Hose.
Wie ist das in der Praxis handelbar? Wie machen das andere Administratoren? ArcServe ist doch kein 0815-Lieschen-Müller-Programm. Ich habe wichtigeres zu tun, als täglich 15 Minuten mit Knöchelchen schmeissen zu vertun
"Verstanden" wäre zu viel gesagt. Aber wie erwähnt, es ist mir schnuppe, *warum* ArcServe meint, monatliche Sicherungen nur Freitags ausführen zu müssen. Egal aus elchem Grund und egal was die Jungs bei CA rauchen:
Woher weiss ich *VOR* der Sicherung (die ja nachts abläuft, wenn niemand da ist, um ArcServe das Händchen zu halten) welches Band verlangt werden wird.
Es kann doch nicht gängige Praxis sein, sich täglich auf dem Backup-Server einzuloggen, das ArcServe Management zu starten und dann auf "Job ändern" gehen, um zu sehen, welches Band morgen dran ist???
Ich habe mir ein Script geschrieben:
@echo off
set capfad=C:\Programme\CA\BrightStor ARCserve Backup
rem - Alle im betr. Datenträgerbestand enthaltenen Bänder listen (Speichersatz (SAVE) und Arbeitssatz (SCRATCH))
%capfad% ca_dbmgr -show poolmedia GFS21_DLY
%capfad% ca_dbmgr -show poolmedia GFS21_MLY
%capfad% ca_dbmgr -show poolmedia GFS21_WLY
Den Output lasse ich mir per Mail schicken. So kriege ich zumindest raus, welche Bänder im Arbeitssatz sind, also verlangt werden *könnten*. Nun muss ich "nur" noch in den Kalender gucken um rauszukriegen, ob es Daily, Weekly oder Monthly ist. Aber an solchen Tagen wie am Freitag geht das eben total in die Hose.
Wie ist das in der Praxis handelbar? Wie machen das andere Administratoren? ArcServe ist doch kein 0815-Lieschen-Müller-Programm. Ich habe wichtigeres zu tun, als täglich 15 Minuten mit Knöchelchen schmeissen zu vertun
Hi,
genaugenommen handelt ArcServe streng nach der Definition von GFS, wie sie auch auf Wiki erklärt ist:
Aber so wie s aussieht gibt es auch Andere die dein Problem teilen und sich nicht merken können (oder wollen) wann welches Band dran ist, immerhin hat hier jemand einen dynamisch generierten GFS-Kalender programmiert: http://acumenis.com/resources/gfs-backup-calendar
Bei unseren Kunden die GFS nutzen sparen wir uns die Mühe. Da entscheidet nicht ArcServe welches Band jetzt dran sein soll, sondern es bleibt dem "Bandwechsler" im Haus überlassen das richtige Band einzulegen bzw. er braucht nur auf seinen für ein Jahr im Voraus ausgedruckten "heute ist dieses-und-jenes Band dran"-Zettel zu schauen.
genaugenommen handelt ArcServe streng nach der Definition von GFS, wie sie auch auf Wiki erklärt ist:
The daily, or son, backups are rotated on a daily basis with one graduating to father status each week.
The weekly or father backups are rotated on a weekly basis with one graduating to grandfather status each month.
Von daher ist es ganz "logisch" dass statt dem letzten weekly-Band das monthly-Band verlangt wird. Dass unsere menschliche Logik das monthly-Backup auf den 30. legen würde ist für ArcServe wohl zu hoch. ^^;The weekly or father backups are rotated on a weekly basis with one graduating to grandfather status each month.
Aber so wie s aussieht gibt es auch Andere die dein Problem teilen und sich nicht merken können (oder wollen) wann welches Band dran ist, immerhin hat hier jemand einen dynamisch generierten GFS-Kalender programmiert: http://acumenis.com/resources/gfs-backup-calendar
Bei unseren Kunden die GFS nutzen sparen wir uns die Mühe. Da entscheidet nicht ArcServe welches Band jetzt dran sein soll, sondern es bleibt dem "Bandwechsler" im Haus überlassen das richtige Band einzulegen bzw. er braucht nur auf seinen für ein Jahr im Voraus ausgedruckten "heute ist dieses-und-jenes Band dran"-Zettel zu schauen.
Danke dir, auch für den Link
Ähnliches hatte ich schon selbst vor, als Excel Sheet oder so. Bisher dachte ich aber, ich bin nur zu blind, um ArcServe zu scripten bzw. zu Manuals zu lesen ;)
Ich gebe also auf und resumiere:
Das Profi-Backup-Programm des Global-Players "CA" ist im Jahr 2009 nicht in der Lage, einen simplen Bericht über das nächste benötigte Band zu erstellen (Yosemite übrigens auch nicht. Veritas weiss ich nicht)
Da bin ich echt baff! Wie könnte man die CA Programmierer (falls es da welche gibt) zu diesem 5-Zeiler überreden? Weil, ... ich habe eine 21 Bänder Rotation mit 5 Weekly Bändern. Die Weekly's lassen sich nicht in eine allgemeine Regel packen. Fehler sind also vorprogrammiert, weil mit dem Bandwechsel ist kein Admin betraut sind, sondern einfache Angestellte.
Die Zeit ist reif für Bacula!
PS: Apropos Logik: Wenn ich in 6 Monaten eine Datei vom 30. November wiederherstellen will, muss ich nicht etwa die November Sicherung rauskramen, sondern die vom Dezember. Dazu muss ich nur einfach und bequem einen alten Kalender vorkramen und gucken, wie die Knöchelchen am bewussten Monatsende gefallen sind.
Und sowas lassen sich Vollblut-Admins seit Jahren bieten!? Ich glaubs nicht, ich glaubs nicht, ich glaubs nicht, ich glaubs nicht, .... sssst ;)
Ähnliches hatte ich schon selbst vor, als Excel Sheet oder so. Bisher dachte ich aber, ich bin nur zu blind, um ArcServe zu scripten bzw. zu Manuals zu lesen ;)
Ich gebe also auf und resumiere:
Das Profi-Backup-Programm des Global-Players "CA" ist im Jahr 2009 nicht in der Lage, einen simplen Bericht über das nächste benötigte Band zu erstellen (Yosemite übrigens auch nicht. Veritas weiss ich nicht)
Da bin ich echt baff! Wie könnte man die CA Programmierer (falls es da welche gibt) zu diesem 5-Zeiler überreden? Weil, ... ich habe eine 21 Bänder Rotation mit 5 Weekly Bändern. Die Weekly's lassen sich nicht in eine allgemeine Regel packen. Fehler sind also vorprogrammiert, weil mit dem Bandwechsel ist kein Admin betraut sind, sondern einfache Angestellte.
Die Zeit ist reif für Bacula!
PS: Apropos Logik: Wenn ich in 6 Monaten eine Datei vom 30. November wiederherstellen will, muss ich nicht etwa die November Sicherung rauskramen, sondern die vom Dezember. Dazu muss ich nur einfach und bequem einen alten Kalender vorkramen und gucken, wie die Knöchelchen am bewussten Monatsende gefallen sind.
Und sowas lassen sich Vollblut-Admins seit Jahren bieten!? Ich glaubs nicht, ich glaubs nicht, ich glaubs nicht, ich glaubs nicht, .... sssst ;)
Hallo lexa-lexa,
nun ja, es hat dich wohl niemand gezwungen dieses Programm zu nutzen. Ich persönlich finde, das es mal besser war. Durch die übernahme von CA ist es nicht besser geworden, eher in der Entwicklung stehen geblieben. CA hat aber auch ein weiteres Problem. Welches seiner Datensicherungsprodukte ist den "das" Programm schlechthin? Es gibt keins. Wenn man weiß, welches das Unternehmerische Ziel von CA ist, verwundert das nicht. Es geht denen ja nicht um deine Probleme sondern um das Verkaufen von Produkten.
Entweder akzeptiere ich ein programm und deren Strategie, oder ich lasse es. Du kannst natürlich bei ArcServe auch deine eigen Datensicherungsstrategie verwende, es hindert dich niemand daran.
Das du kein Datensicherungsprogramm findest, welches deine Logik verwendet ist klar. Siehe hierzu mal wie die Strategie von GFS oder auch Drei-Generationen-Sicherung aufgebaut ist. Wenn ich also einem Datensicherungsprogramm sage, GFS zu nutzen, so tut es das auch. Da bleibt dir nur übrig, deine Logik umzustellen, oder keine GFS Strategie nutzen.
Zur protokollierung und feststellung welches band wird denn jetzt als nächstes erwartet, da hat sich eine Excel liste immer als bestes mittel bewährt. Der Benutzer zuständig für die Sicherung konnte da auch abhaken was erledigt war. Hört sich nach Steinzeit EDV an, ist es auch.
Ich Persönlich versuche ArcServe und BackupExec zu vermeiden, und wo es geht die OS eigenen Sicherungsprogramme einzusetzen.
Peter
nun ja, es hat dich wohl niemand gezwungen dieses Programm zu nutzen. Ich persönlich finde, das es mal besser war. Durch die übernahme von CA ist es nicht besser geworden, eher in der Entwicklung stehen geblieben. CA hat aber auch ein weiteres Problem. Welches seiner Datensicherungsprodukte ist den "das" Programm schlechthin? Es gibt keins. Wenn man weiß, welches das Unternehmerische Ziel von CA ist, verwundert das nicht. Es geht denen ja nicht um deine Probleme sondern um das Verkaufen von Produkten.
Entweder akzeptiere ich ein programm und deren Strategie, oder ich lasse es. Du kannst natürlich bei ArcServe auch deine eigen Datensicherungsstrategie verwende, es hindert dich niemand daran.
Das du kein Datensicherungsprogramm findest, welches deine Logik verwendet ist klar. Siehe hierzu mal wie die Strategie von GFS oder auch Drei-Generationen-Sicherung aufgebaut ist. Wenn ich also einem Datensicherungsprogramm sage, GFS zu nutzen, so tut es das auch. Da bleibt dir nur übrig, deine Logik umzustellen, oder keine GFS Strategie nutzen.
Zur protokollierung und feststellung welches band wird denn jetzt als nächstes erwartet, da hat sich eine Excel liste immer als bestes mittel bewährt. Der Benutzer zuständig für die Sicherung konnte da auch abhaken was erledigt war. Hört sich nach Steinzeit EDV an, ist es auch.
Ich Persönlich versuche ArcServe und BackupExec zu vermeiden, und wo es geht die OS eigenen Sicherungsprogramme einzusetzen.
Peter
Warum CA bezüglich "nur Freitagbänder können Monatsbänder sein" denkt, kann ich mir so erklären:
Tagessicherungen werden Incremental gesichert, Wochensicherungen Full (ausgegangen von großen Organisationen)
Da eine Sicherung auch Zeit in Anspruch nimmt (und Netzauslastung), wird man eine Vollsicherung dahin verlegen, wo sie am wenigsten stört, und das ist nun mal das Wochenende.
Der letzte Freitag im Monat wird dann somit zur Monatssicherung, da man übers WE gemütlich sichern kann.
Wir verzichten aus dem Grund komplett auf eine GFS Rotation.
Bei uns gibt es Tägliche und Wöchtentliche Jobs, die als "Custom" definiert sind, und mittels "Repeat Interval" rotieren.
Ein Fullbackup benötigt mehrere Ultrium3 Bänder -> Wöchentliches Fullbackup daher nur am Freitag.
Wir bringen täglich die Bänder in einen Datensafe, womit sich zur Sicherung auch nur die benötigten Bänder im Changer befinden dürfen!
Allerdings haben wir hier bestimmte Personen, die auch genau dafür Verantwortlich sind -> und die müssen täglich schauen ob die richtigen Bänder
(Name, ID, Sequ.Nr,..) im Changer sind, Bänder in den Safe tragen, Sicherung kontrollieren etc.
Tagessicherungen werden Incremental gesichert, Wochensicherungen Full (ausgegangen von großen Organisationen)
Da eine Sicherung auch Zeit in Anspruch nimmt (und Netzauslastung), wird man eine Vollsicherung dahin verlegen, wo sie am wenigsten stört, und das ist nun mal das Wochenende.
Der letzte Freitag im Monat wird dann somit zur Monatssicherung, da man übers WE gemütlich sichern kann.
Wir verzichten aus dem Grund komplett auf eine GFS Rotation.
Bei uns gibt es Tägliche und Wöchtentliche Jobs, die als "Custom" definiert sind, und mittels "Repeat Interval" rotieren.
Ein Fullbackup benötigt mehrere Ultrium3 Bänder -> Wöchentliches Fullbackup daher nur am Freitag.
Wir bringen täglich die Bänder in einen Datensafe, womit sich zur Sicherung auch nur die benötigten Bänder im Changer befinden dürfen!
Allerdings haben wir hier bestimmte Personen, die auch genau dafür Verantwortlich sind -> und die müssen täglich schauen ob die richtigen Bänder
(Name, ID, Sequ.Nr,..) im Changer sind, Bänder in den Safe tragen, Sicherung kontrollieren etc.
Hi Peter,
danke für dein Statement, aber wie ich schon sagte: Mir ist völlig wurscht, warum ArcServe dieses oder jenes Band verwendet. Ich wills nur vorher wissen. Es kann nicht unmöglich sein, denn in der Zeit zwischen dem letzten Backup und dem kommenden ist das nächste Band (oder was für ein Set auch immer dran ist) bekannt, also kann es theoretisch und praktisch reportet werden:
Mehr will ich gar nicht
Des Weiteren: Doch, ich wurde gezwungen, dieses Programm zu nutzen. Ich hab's so übernommen. Und vor allem wüsste ich nicht, welches man alternativ für Datei-basierende Backups nehmen könnte, für normale 10-50 User Companies mit ein bis drei Servern. Die ich kenne, haben alle ihre Macken.
Ich persönlich versuche (zu deinen zweien) noch das Yosemite Tapeware zu vermeiden. Leider vergeblich. Wo ich auch hinkomme, ist mindestens eine dieser Krücken installiert. Was aber nicht an nur den "Krücken" liegt, sondern auch am Kodex der Systemhäuser:
Gib dem Kunden auf keinen Fall ein Programm, das er selbst bedienen könnte! Wird Zeit, dass ich mich auch danach richte
danke für dein Statement, aber wie ich schon sagte: Mir ist völlig wurscht, warum ArcServe dieses oder jenes Band verwendet. Ich wills nur vorher wissen. Es kann nicht unmöglich sein, denn in der Zeit zwischen dem letzten Backup und dem kommenden ist das nächste Band (oder was für ein Set auch immer dran ist) bekannt, also kann es theoretisch und praktisch reportet werden:
- ca_dbmgr -show pool GFS21 next_tape
Mehr will ich gar nicht
Des Weiteren: Doch, ich wurde gezwungen, dieses Programm zu nutzen. Ich hab's so übernommen. Und vor allem wüsste ich nicht, welches man alternativ für Datei-basierende Backups nehmen könnte, für normale 10-50 User Companies mit ein bis drei Servern. Die ich kenne, haben alle ihre Macken.
Ich persönlich versuche (zu deinen zweien) noch das Yosemite Tapeware zu vermeiden. Leider vergeblich. Wo ich auch hinkomme, ist mindestens eine dieser Krücken installiert. Was aber nicht an nur den "Krücken" liegt, sondern auch am Kodex der Systemhäuser:
Gib dem Kunden auf keinen Fall ein Programm, das er selbst bedienen könnte! Wird Zeit, dass ich mich auch danach richte
Hallo lexa-lexa,
ich bin nach 10 Jahren Arcserve Backup zu Dataprotector Backup gewechselt.
Dieses Programm löst dein Problem auf die Weise das die Sicherungsjobs einen zeitlichen Schreibschutz bekommen. Der wird dann runtergezählt (minütlich)
und du siehst genau welche Bänder als nächstes wieder abgelaufen (zeitl. Schreibschutz) sind und damit für die kommende Sicherung verwendet werden.
Wir haben die Generationensicherung in Arcserve manuell definiert wie Equinox es beschreibt.
Nachdem man verstanden hat wie Dataprotector arbeitet, ein geniales Programm und ein sehr gutes Lizenzmodell.
Du bezahlst nur für Starterpack (Server + 1 Sicherungslaufwerk) und für Datenbankagents (SQL, Exchange, .u.s.w.)
Mit dem installierten Server kannst du endlos Clients auf Dateiebene sichern.
Du bezahlst also nur wenn du ein neues Sicherungslaufwerk (ein 40er Bibliothek mit einem Laufwerk ist auch nur eine Lizenz) dazubauen willst oder du einen Datenbankserver zusätzlich sichern willst.
ich bin nach 10 Jahren Arcserve Backup zu Dataprotector Backup gewechselt.
Dieses Programm löst dein Problem auf die Weise das die Sicherungsjobs einen zeitlichen Schreibschutz bekommen. Der wird dann runtergezählt (minütlich)
und du siehst genau welche Bänder als nächstes wieder abgelaufen (zeitl. Schreibschutz) sind und damit für die kommende Sicherung verwendet werden.
Wir haben die Generationensicherung in Arcserve manuell definiert wie Equinox es beschreibt.
Nachdem man verstanden hat wie Dataprotector arbeitet, ein geniales Programm und ein sehr gutes Lizenzmodell.
Du bezahlst nur für Starterpack (Server + 1 Sicherungslaufwerk) und für Datenbankagents (SQL, Exchange, .u.s.w.)
Mit dem installierten Server kannst du endlos Clients auf Dateiebene sichern.
Du bezahlst also nur wenn du ein neues Sicherungslaufwerk (ein 40er Bibliothek mit einem Laufwerk ist auch nur eine Lizenz) dazubauen willst oder du einen Datenbankserver zusätzlich sichern willst.
Hi Frosch,
das ArcServe arbeitet ja auch mit einem zeitlichen Schreibschutz, d.h., der Speichersatz ist ro und alle Bänder im Arbeitssatz können beschrieben werden. Du kennst das ja sicher noch. Der Befehl "ca_dbmgr -show poolmedia POOL" gibt auch aus, welche Datenträger beschreibbar sind. Bei einer GFS Rotation betrifft das am Monatsende aber mindestens 2 Bänder, oft mehr zzgl. ein leeres Band. Das wird bei DataProtector nicht anders sein, das am Freitag+Monatsende mehrere Bänder zugleich beschreibbar werden.
Trotzdem danke für die Info zum Programm
das ArcServe arbeitet ja auch mit einem zeitlichen Schreibschutz, d.h., der Speichersatz ist ro und alle Bänder im Arbeitssatz können beschrieben werden. Du kennst das ja sicher noch. Der Befehl "ca_dbmgr -show poolmedia POOL" gibt auch aus, welche Datenträger beschreibbar sind. Bei einer GFS Rotation betrifft das am Monatsende aber mindestens 2 Bänder, oft mehr zzgl. ein leeres Band. Das wird bei DataProtector nicht anders sein, das am Freitag+Monatsende mehrere Bänder zugleich beschreibbar werden.
Trotzdem danke für die Info zum Programm
Hi Equinox,
danke. Bei diesem speziellen Kunden habe ich (genau umgekehrt) die vorhandene, manuelle Sicherung auf GFS umgestellt in der Hoffnung, dass die Backups damit zuverlässiger laufen und dort endlich eine vernünftige Archivierung stattfindet. Die Firma ist sehr schnell gewachsen und die IT wird (wie so oft) nur als notwendiges Übel angesehen. Sie hatten sehr oft Ausfälle, weil die Bänder irgendwann immer komplett im Speichersatz landeten, also "ro".
Mein Ziel habe ich erreicht, die Sicherung ist zuverlässiger geworden - oder die damit Betrauten? Jedenfalls, bis auf den Gau am Freitag geht ab und an mal ein tägliches incrementelles flöten. Damit kann man z.Zt. noch leben und zum Glück kommen sie noch eine Weile mit einem Band je Streamer aus.
danke. Bei diesem speziellen Kunden habe ich (genau umgekehrt) die vorhandene, manuelle Sicherung auf GFS umgestellt in der Hoffnung, dass die Backups damit zuverlässiger laufen und dort endlich eine vernünftige Archivierung stattfindet. Die Firma ist sehr schnell gewachsen und die IT wird (wie so oft) nur als notwendiges Übel angesehen. Sie hatten sehr oft Ausfälle, weil die Bänder irgendwann immer komplett im Speichersatz landeten, also "ro".
Mein Ziel habe ich erreicht, die Sicherung ist zuverlässiger geworden - oder die damit Betrauten? Jedenfalls, bis auf den Gau am Freitag geht ab und an mal ein tägliches incrementelles flöten. Damit kann man z.Zt. noch leben und zum Glück kommen sie noch eine Weile mit einem Band je Streamer aus.
