Morpheus38

Hallo Zusammen,

 

auch ich reihe mich hiermit bei den "Opfern" ein. :-(

 

Nur ist es bei mir nicht der Benutzer "spwebapp" sondern der "sbsadmin" (!) Also das Admin-Konto, mit dem ich den SBS installiert habe.

Bei mir tritt die Meldung wegen dem temporären Profil aber nur sporadisch auf. Einmal waren dann auch alle Desktop-Icons verschwunden.

 

Ebenfalls in meinem Fall handelt es sich um einen frisch installierten SBS2011 Standard. Alle Updates sind drauf, sowie auch das SP1 für Windows und SP1 für Sharepoint.

 

Das SP1 vom Sharepoint musste ich auch manuell in der Shell updaten, da es nicht automatisch passierte.

 

Nachtrag: Jetzt kommt die Meldung (ID 1511) auch bei mir nach jedem Neustart.

 

Nachtrag2: Ich muss mich korrigieren:

 

1. Bei dem Benutzer in dem Eventlog-Eintrag handelt es sich doch um den Benutzer "spwebapp" und nicht "sbsadmin".

2. Dennoch hatte ich bisher einmal das Phänomen, dass beim Benutzer "sbsadmin" auf einmal alle Desktop-Verknüpfungen verschwunden waren!

 

Ganz komische Sache das...

danke für die Links! Hab das erste (CSSMTP), bereits mal angetestet.

 

Funktioniert zwar, aber leider funktioniert das Auslesen des "subjects" nicht.

 

Hintergrund: In dem Skript wird mit "If Errorlevel" das Ergbnis in "Emailtopic" übergeben.

Bei Blat wurde dann aus "%Emailtopic%" das entsprechende Ergebnis eingetragen. ("Erfolgreich" oder "Fehlgeschlagen").

CSSMTP ignoriert das und schreibt in den Betreffe einfach "%emailtopic%" rein ;-(

 

Naja, vermutlich habe ich da vielleicht irgendwo was vergessen, oder das Programm unterstützt das nicht. Ich teste weiter und berichte...

 

Gruß,

Sascha

Hier mal ein kleines Update:

 

wie von Geisterhand funktioniert die Emailzustellung ohne, dass ich irgend etwas verändert habe. :confused:

 

Bei 10 weiteren SBS Servern, wo das Tool im Einsatz ist, habe ich mal die "Problembehandlung" durchforstet. Und siehe da: Blat taucht bei vielen Servern, in unregelmäßigen Abständen dort auf. (Fehler in der Anwendung, ...muss beendet werden, etc.). Allerdings werden die Mails trotzdem brav jeden Tag verschickt.

 

Mein Resumé: Blat scheint grundsätzlich nicht stabil unter Server 2008 zu laufen. Es funktionierte zwar bisher bei den meisten Servern trotz der Fehlerprotollierung, aber was ist, wenn das Programm wegen der Instabilität sporadisch mal keine Mail verschickt? -> Eben.

 

Jetzt habe ich mir aber mein Backupskript mühevoll in unzähligen, kaffeeüberdosierten Nächten :D zusammen gestrickt, bis es so lief wie jetzt und es funktioniert tadellos. - bis auf, ja ...dem Problem mit BLAT ! :suspect:

 

Nun brauche ich ein anderes, am besten kostenloses Email-Befehlszeilentool, was unter SBS2008 stabil läuft und sich auch in das Skript einbauen lässt.

 

Jemand eine Idee, welches da in Frage kommt?

 

 

Achja: Guten Rutsch ins neue Jahr wünsche ich Euch Allen !

Hi,

 

das hört sich in der Tat strange an. Funktioniert blat wenn du es direkt von der cmd aus aufrufst?

 

... diese cmd tools haben manchmal probleme mit langen pfadnamen - hat sihc der speicherhort der Datei vielleicht geändert?

 

Hi nerd,

 

also in der cmd lässt es sich aufrufen und verschickt auch brav Mails.

Wenn ich es mit der Scheduler aufrufen lasse funktioniert es ebenfalls. (dort wird ein skript gestartet, welches nur blat mit seinen Parametern aufruft).

Wenn ich Blat hingegen in dem Backup-Skript aufrufen lassen möchte, wo es erst am Schluss (Übergabe "if" "else" "%emailtopic%"), aufgerufen werden soll, wird zwar das Backup erfolgreich erstellt, (Logfile liegt mit success vor), aber blat scheinbar einfach ignoriert. (noch nicht mal das Blat-Logfile wird geschrieben). Also wird es scheinbar nach dem Backuptool gar nicht erst aufgerufen. Aber auch kein anderer Fehler wird irgendwo ausgegeben.

 

Verstehe das echt nicht. Bei vielen anderen Servern mit gleicher Konfiguration funktioniert es ohne Probleme. :suspect:

 

Nach einer Blat-Alternative habe ich auch schon geschaut, aber nix brauchbares gefunden.

 

Achja, UAC ist deaktiviert.

Mir würde es ja schon weiterhelfen, wenn mir jemand die Bedeutung des Exitcode 255 nennen könnte?

Tagchen,

 

ich kämpfe gerade mit einem Fehler in der Skriptabfolge.

 

Zunächst wird ein Programm mit Parametern aufgerufen:

 

diskshadow.exe /s x:\skripts\ex-backup_fr.txt /l x:\logs\diskshadow\ex-backup_fr.log

 

Bei der Ausführung werden weitere Parameter aus der Datei "ex-backup_fr.txt" ausgelesen.

Der Inhalt dieser TXT-Datei ist folgender:

 

set context persistent
begin backup
add volume e: alias FirstStorageGroup
create
expose %FirstStorageGroup% Q:
exec x:\skripts\fr_dif.bat
end backup
delete shadows exposed Q:
exit

 

Wie man sieht, wird dort eine Batchdatei "fr_dif.bat" aufgerufen.

Der Aufruf funktioniert auch ohne Probleme.

Der Inhalt der Batchdatei "fr_dif.bat" sieht folgendermaßen aus:

 

del /q x:\snapshot\result_ERROR\*.*
del /q x:\snapshot\result_OK\*.*

 x:\snapshot\snapshot.exe Q:+C:+D: x:\backup\snapshot\$diskfreitag_dif.SNA -hx:\backup\snapshot\$diskmontag_full.hsh --novss --logfile:x:\logs\fr_dif.log
  if errorlevel 1 (
     set emailtopic=fehlgeschlagen! SERVER SNAPSHOT Sicherung FREITAG! Fehlercode: %errorlevel% 
     copy x:\logs\fr_dif.log x:\snapshot\result_ERROR
  ) else (
     set emailtopic=erfolgreich! SERVER SNAPSHOT Sicherung FREITAG!
     copy x:\logs\fr_dif.log x:\snapshot\result_OK
  )

x:\skripts\Blat.exe -install server.domäne.local email@domain.de
x:\skripts\Blat.exe "x:\skripts\body.txt" -to email@domain.de -server mail.domain.de -u username -pw passwort -debug -timestamp -log blatSMTPlog.txt -subject "%emailtopic%" 

 

Der Befehl "snapshot.exe Q:+C:+D: wird ausgeführt und das Logfile von Snapshot wird ebenfalls geschrieben. (alles success).

 

Das Problem fängt erst danach an: Es soll ja bei erfolgreichen Backup eine Email mit dem Betreff: "erfolgreich! SERVER SNAPSHOT Sicherung TAG" verschickt werden.

Und genau da ist irgendwo ein Fehler. Mir ist aber nicht klar, an welcher Stelle. Das Skript nach dem Ausführen von Snapshot mit einem "pause" anzuhalten gelingt mir nicht. Das CMD-Fenster geht trotzdem einfach zu.

In der anderen Logdatei wird einem dann auch nur angezeigt, dass die Batchdatei mit einem Fehlercode 255 beendet wurde.

 

-> expose %FirstStorageGroup% Q:
-> %FirstStorageGroup% = {0ed543e9-2a92-418f-a72c-75c75933fbe1}
Die Schattenkopie wurde als "Q:\" verfügbar gemacht.
-> exec x:\skripts\fr_dif.bat
Vom Befehlsskript wurde der Exitcode "255" zurückgegeben.
Fehler im Befehlsskript.

 

Quasi wird das Backup ordnungsgemäß durchgeführt und auch die Logfiles werden mit success beendet. Die Backupfiles sind alle da und auch vollständig. Er scheint sich beim anschließendem Versenden der Email im Skript an irgendwas zu stören. Nur leider finde ich nicht heraus was das sein soll. Hat hier jemand eine Idee?

Kennt jemand den Exitcode 255 und weiß, was er bedeutet?

 

Zur Info: Exakt das gleiche Skript, (nur mit anderen Pfaden und Servernamen), läuft auf einem anderen Server einwandfrei!

 

Gruß,

Sascha

Nabend Zusammen,

 

Situation:

 

SBS08 Server wird mit einem Snapshot-Tool via Batchdatei gesichert.

In dieser Batchdatei wird nach dem Backup der Emailclient "Blat" gestartet, welcher dann den "result" des Backuptools per Mail verschickt.

 

Dieses Skript läuft bei mehreren Kunden von mir einwandfrei.

Allerdings habe ich nun bei einem der Kunden das Problem, dass ich seit dem 10.11.2010 keine Mail mehr zugesand bekomme. (vorher ohne Probleme).

 

Ich habe in das Skript mal eine Pause eingebaut und es von Hand gestartet. Blat wird auch wie gewünscht gestartet, allerdings versendet es keine Mail. Es bleibt ca. 15 sek. stehen und danach erscheint ein Windows-Hinweisfenster, dass das Kommandozeilentool ein Problem verursacht hat. Klickt man dann auf ok, sieht man im CMD-Fenster, wie Blat die CMD wieder frei macht und sich beendet.

 

Schaut man unter "Problemberichte und Lösungen" nach, findet man mehrere Einträge, die den Absturz von Blat.exe anzeigen.

 

Nun hat es ja ne ganze Weile ohne auch nur ein Problem funktioniert. Warum auf einmal nicht mehr? Könnte ein Windowsupdate schuld sein?

Aber dann müsste es ja bei meinen anderen Kunden ebenfalls auftreten, da ich die Server immer auf den gleichen Patchstand halte.

Hab echt keinen blassen Schimmer, warum das Tool auf einmal keine Mails mehr verschicken will.

 

Was ich schon versucht habe:

 

1. Kompatibilitätsmodus für blat.exe (XP/Server 2003) eingestellt.

2. NTFS-Berechtigung Vollzugriff konfiguriert.

3. Datenausführungsverhinderung kontrolliert, (steh auf "nur Windowsprogramme").

4. SMTP-Port für Blat zum Senden tesweise geändert. ( -port 587)

 

In der CMD lässt blat sich ohne Parameter starten und stürzt dann auch nicht ab. Zumindest kommt kein Windows-Hinweisfenster, dass es abgestürzt ist.

 

In der Aufgabenplanung wird der Task, in dem Blat aufgerufen wird, mal mit dem Fehler "0xc0000005" , und mal mit dem Fehler 0xff beendet.

 

Hat das Problem schon mal wer gehabt? Google schweigt sich da seltsamerweise auch aus.

 

Edit: Hab auch mal andere Versionen von Blat getestet. Gleiches Problem.

Dieser Beitrag ist Teil des Gewinnspiels "Rette Julia" zur Monatsaufgabe November.

Der Beitrag ist geschlossen, da die Monatsaufgabe November erfüllt wurde.

Mehr dazu: http://www.mcseboard.de/rettejulia.php

 

__

 

Hallo Julia,

 

Ein weißes Fähnchen in der Taskleiste erscheint ganz unauffällig.

Klickt man einmal darauf, erscheinen wichtige Meldungen von Windows 7, welche den Benutzer über Sicherheits - oder Leistungsprobleme informiert und darüber hinaus nützliche Tipps gibt, welche die Leistung von Windows 7 erhöhen.

 

So wird man z.B. informiert, wenn die Überprüfung des PC´s durch Windows Defender mal wieder angebracht wäre.

 

Treten Probleme mit Programmen oder Treiber auf, so werden Lösungsvorschläge gemacht. Und wenn es noch keine Lösung gibt, wird dies durch das Wartungscenter erfasst und ein Bericht an Microsoft geschickt. Wenn Microsoft dann eine Lösung für das Problem parat hat, wirst du automatisch durch das Wartungscenter darüber informiert.

 

Wenn du das in Windows 7 integrierte Backuptool benutzt, wird das Einhalten einer regelmäßigen Sicherung ebenfalls durch das Wartungscenter überwacht.

 

Natürlich werden auch noch andere, sicherheitsrelevante Dienste durch das Wartungcenter überwacht. (z.B. Status des Virenschutz, Windowsupdates, Firewall).

 

Ein weiteres Highlight ist der Zuverlässigkeitsverlauf, wo alle vergangenen und bestehende Probleme in einer übersichtlichen Verlaufsgrafik angezeigt werden.

Dort kann man gut erkennen, welche Ereignisse, (Anwendungsfehler, Windows-Fehler, Warnungen), über einen längeren Zeitraum aufgetreten sind und dadurch einen "Hauptfehlerverursacher" leichter ausfindig machen.

Dieser Beitrag ist Teil des Gewinnspiels "Rette Julia" zur Monatsaufgabe November.

Der Beitrag ist geschlossen, da die Monatsaufgabe November erfüllt wurde.

Mehr dazu: http://www.mcseboard.de/rettejulia.php

 

__

 

Hallo Julia,

 

Windows 7 verwendet eine sicherere Version des Remote Desktop Protokolls als in früheren Windows Versionen.

 

Wenn man Remote Desktop Verbindungen zu seinem Windows 7 Client zulassen möchte, hat man nun die Möglichkeit bei der Aktivierung die Authentifizierung auf Netzwerkebene auszuwählen.

Die Authentifizierung auf Netzwerkebene sorgt dafür, dass sich der Jenige, welcher die Verbindung aufbaut zuerst authentifizieren muß, bevor er überhaupt das Anmeldefenster von Windows 7 zu Gesicht bekommt.

 

Die Remote Desktop Verbindung in Windows 7 ist jedoch nicht nur sicherer, sondern auch ressourcenschonender, da die Verbindung erst dann zustande kommt, nachdem der Benutzer die Authentifizierungsdaten eingegeben hat.

 

Das hat also in zweierlei Hinsicht Vorteile und dürfte ein weiteres, gutes Argument für eine Umstellung auf Windows 7 sein.

Hallo Julia,

 

aber auch an Menschen, die weiterhin mit Windows XP arbeiten, hat Microsoft mit Bitlocker To Go gedacht:

Unter Windows Vista oder Windows 7 mit Bitlocker To Go verschlüsselte Datenträger lassen sich problemlos unter Windows XP öffnen.

Allerdings können diese leider nur im schreibgeschützten Modus geöffnet werden.

Hi Zahni,

 

danke für deine Antwort.

Wenn ich für mich sprechen darf: - so habe ich mit dieser Methode allerdings durchaus positive Erfahrungen gemacht. (In Bezug auf Restoreszenarien).

 

Den einzigen Nachteil, den ich hier sehe ist, daß ein Restore auf fremder Hardware schwierig wird. Allerdings kann man das voraus planen und das EOL der Hardware in die Planung miteinbeziehen.

 

Nun, da ich bisher keinen Anhaltspunkt habe, was das Problem sein könnte, habe ich versucht auf die interne Backupsoftware des SBS2008 zurück zu greifen. Allerdings funktioniert selbst diese scheinbar nicht.

Nachdem ich in der SBS-Console auf den Button "Datensicherung gewechselt bin, erscheint ein Hinweisfenster wo steht, daß "Daten geladen werden".

Und das wars. Es geht nicht weiter. Keine Fehlermeldung. Er bleibt da einfach hängen. Also scheint hier ja grundsätzlich was schief zu laufen.

 

Vielleicht kann mir ja jemand auf dieser Grundlage einen Tipp geben.

 

Edit: Der Server läuft auf einem Raid5 (3+1Hotspare) auf einem LSI 9260-4i. Bis zu dem besagten Montag letzte Woche, keinerlei Probleme mit dem Server gehabt.

Ich habe leider immer noch keine Lösung gefunden. Wer kann helfen?

Hallo Zusammen,

 

bei einem Kunden habe ich seit Anfang letzter Woche das Problem, dass die Datensicherung nicht mehr funktioniert.

 

Für die Datensicherung setze ich ein Imageprogramm (Drive Snapshot), sowie Diskshadow ein.

 

Das Ganze wird per Aufgabenplanung initiiert, wobei zunächst Diskshadow aufgerufen wird.

 

Der Aufruf ist fogendermaßen:

 

set context persistent
begin backup
add volume e: alias FirstStorageGroup
create
expose %FirstStorageGroup% Q:
exec d:\skripts\mo_full.bat
end backup
delete shadows exposed Q:
exit

 

Das Skript kommt bis zur 4. Zeile "create" und bleibt dann einfach hängen.

Im Logfile sieht man keinen Fehler. (nur der Skriptablauf bis "create" ist zu sehen und danach ist das Logfile leer).

 

Ich habe den Aufruf dann mal in der CMD manuell eingetippt. An der Stelle, wo ich "create" eintippe, um das Shadow zu erstellen, bleibt er einfach so stehen und es tut sich nichts mehr.

 

Weder im Eventlog, noch im Skriptlogfile ist ein Fehler vorhanden. Ich habe absolut keinen Anhaltpunkt, wo ich nach dem Problem suchen soll.

 

Auf vielen anderen Servern läuft exakt das gleiche Skript einwandfrei. Das tat es auf dem betroffenen Server ja auch Monate lang bis verganenen Montag, wo er das erste mal nicht gesichert hat.

 

Falls jemand eine Idee hat, oder vielleicht sogar das gleiche Problem und eine Lösung parat hat, würde ich mich über einen Tipp freuen.

Das Problem ist ziemlich brisant, da der Kunde keine alternative Sicherungssoftware hat und ich nicht wüßte, wie ich den Exchange mit gesichert bekomme, da dort ein Imageprogramm eingesetzt wird.

 

Gruß,

Sascha

Hallo Dirk,

 

RDX kann ich nur empfehlen. Ich setze es mittlerweile bei vielen Servern ein und habe bisher nur gute Erfahrungen mit Backups auf RDX gemacht.

 

Beim Einsatz empfehle ich einen separaten SATA-Controller. Die Performance ist gut und die Datensicherung arbeitet zuverlässig im Gegensatz zur USB-Lösung.

achja nochwas: wenn der rechner ausserhalb des netzes ist (zb internetanbindung per umts) kann outlook mit dem exchange connecten und alles funktioniert sauber.

 

Meinst du mit "alles funktioniert sauber", dass auch die VPN-Verbindung geht?

 

Was ist denn mit dem Benutzer der sich am Domänen-Konto anmeldet, hat der auch die Berechtigung für VPN-Verbindung? Das klingt banal, aber sowas kann man ja mal vergessen einzustellen. ;-)

 

Ansonsten, habe in ähnlicher Konfig schon festgestellt, dass der W7-Client manchmal Probleme mit dem Verbindungsaufbau hat. Wenn man die Verbindung erfolgreich aufgebaut hat, dann trennt, und anschließend wieder aufbauen will, kommt entweder sofort eine Fehlermeldung, oder aber er versucht über sstp zu verbinden. Da habe ich dann beim Client bei "Sicherheit" von "AUTO" auf "PPTP" umgestellt. Das hat dann Abhilfe geschaffen. Aber bei dir kommt sie ja gar nicht zustande.

Hallo,

 

ich empfehle Drivesnapshot von Tom Ehlert Software.

Das Programm ist sehr klein, befehlzeilensteuerbar, (trotzdem mit Gui), kann differenzielle Backups und im Recovery-Fall kann man mit der BartPE-CD arbeiten, da dort Snapshot schon drauf ist.

Hallo Zusammen,

 

@Kamikatze:

Die Firewall von Windows 7 verhält sich schon ein wenig anders. Da gelten die Rules entsprechend den Profilen, die bei erstmaligen Verbindungsaufbau abgefragt werden.

(Domäne/Öffentlich/Privat). Allerdings kommt der Firwall-Profilassistent erst, wenn die Verbindung aufgebaut wurde. (was bei dir ja nicht klappt).

 

Was mich etwas irritiert, ist deine Aussage, dass von "Außerhalb des Netzes" die Verbindung mit Exchange funktioniert. Die VPN-Verbindung baut man doch auch von "Außerhalb des Netzes" auf, oder wo verstehe ich dich hier falsch?

Wie hast du denn Outlook an Exchange angebunden? Via https-Proxy?

 

Kann der Router VPN-Passthrue und ist dort GRE und Port 1723 freigeschaltet?

 

Ansonsten: Ist bei der VPN-Verbindung (W7-Client) bei Domäne der DOMÄNENNAME.LOCAL eingetragen?

 

Ist bei Eigenschaften->Netzwerk->Internetprotokoll TCP/IP V4->Eigenschaften->Erweitert->DNS der Domänenname bei: "DNS-Suffix für die Verbindung" angegeben?

Hallo,

 

wenn du die WLAN-Verbindung nutzt, und unbedingt feste IP-Adressen vergeben willst, solltest du den LAN-Adapter deaktivieren.

Dann sollte es funktionieren.

 

Gruß,

Morpheus38

Hallo Allerseits,

 

zwar konnte mir bisher niemand helfen, aber das Problem konnte ich dennoch lösen.

Das Problem war der Raid-Controller. Dieser meldete regelmäßig einen E/A-Fehler im Protokoll, und zwar immer dann, wenn auch die Sicherung fehl schlug.

Vermutlich hat der Controller ein Problem damit ein Raid5-Verbund und zusätzlich eine separate Festplatte im Raid0-Modus zu steuern.

Das Backup wird nun auf eine externe NAS umgeleitet und die Sicherung läuft ohne Fehler durch.

Hallo Community,

 

bin neu hier und falle auch gleich mit der Tür ins Haus

 

Habe hier einen Small Business Server 2008, den ich mit Drivesnapshot sichere.

 

Die folgende Beschreibung des Fehler richtet sich ins besondere an User, die schon ein mal mit Drivesnapshot gearbeitet haben.

 

Mir ist bekannt, dass man einen Domänencontroller nicht mit einer Imagelösung sichern sollte, wenn man mehrere DC´s betreibt, die sich untereinander replizieren.

Es handelt sich hier allerdings um einen alleinstehenden SBS-Server, der alle Dienste bereitstellt und von daher die Probleme mit USN etc. nicht relevant sind.

 

Nun aber zum Problem:

 

Ich versuche seit einiger Zeit Drivesnapshot mit Diskshadow zu kombinieren, damit ich auxh die Exchangedatenbank sauber gesichert bekomme.

 

Die Partitionen sind wie folgt eingerichtet:

 

C: <- SBS2008 Systempartition

D: <- Datenpartition

E: <- Exchangedatenbank

F: <- SQL-Partition

 

Dazu habe ich mir 2 Skripte erstellt. Das erste ruft Diskshadow auf, was wiederum eine Textdatei ausliest. Das Ganze wird via Aufgabenplanung folgendermaßen aufgerufen:

 

 C:\Windows\SysWOW64\diskshadow.exe 

 

Im Taskplaner (Aufgabenplanung) kann man unter dem Aufruf des Programms noch Parameter angeben, wo dann die Textdatei ausgelesen wird:

 

 /s x:\skripts\ex-backup_di.txt /l x:\logs\ex-backup_di.log 

 

Inhalt der Textdatei ist folgender:

 

 set context persistent
begin backup
add volume e: alias FirstStorageGroup
create
expose %FirstStorageGroup% Q:
exec x:\skripts\di_dif.bat
end backup
delete shadows exposed Q:
exit 

 

In der 6. Zeile wird wiederum eine Batch-Datei ausgeführt, in der folgendes steht:

 

 x:\snapshot\snapshot.exe C:+D:+Q:+F: x:\backup\snapshot\$diskdienstag_dif.SNA -hx:\backup\snapshot\$diskmontag_full.hsh --novss --logfile:x:\logs\di_dif.log 

 

Die "montag_full.hsh existiert, weil Montags die Vollsicherung gemacht wird, die auch ohne Probleme durchgeführt wird.

 

Beim Starten der Sicherung wird zunächst eine Schattenkopie der Exchange-Partition erstellt und mit Laufwerksbuchstaben Q: versehen.

Dann wird die Batchdatei aufgerufen, in der Snapshot die Partitionen c+d+q+f sichert. Wenn die Sicherung abgeschlossen ist, wird die Schattenkopie normalerweise wieder gelöscht. Das funktioniert bei der Vollsicherung und auch bei der ersten Differenziellen Sicherung Dienstags.

Ab Mittwoch jedoch tauchen schon die ersten Probleme auf, dass z.B. nach der Sicherung die Schattenkopie nicht gelöscht wird. Der anschließende Aufruf des nächsten Skripts schlägt dann fehl, weil Schattenkopie Q: schon exisiert und nicht erstellt werden kann. Die Folge ist, dass das Backupskript angehalten wird und die Sicherung nicht durchgeführt wird.

 

Die Log-Datein von Diskshadow und Snaphot nach einer erfolgreichen und fehlerhaften Sicherung habe ich mal angehängt.

 

Ich finde den Fehler einfach nicht, warum ab einem bestimmten Wochentag die Sicherung mit den im Anhang gezeigten Fehler fehlschlägt.

Das dumme ist, dass die Sicherung danach einfach nicht mehr fortgeführt wird und somit das Konzept unbrauchbar ist. :(