Hope This Helps

Problem:
Ich hatte das Problem, dass meine Backup-Platte defekt war und ich daher die Veeam-Sicherung neu einrichten musste. Dazu wollte ich aber nicht die ganze Software deinstallieren. Ich wollte nur die komplette Konfiguration löschen und neu einrichten.

Lösung:
Mit der nachfolgenden Prozedur wird die komplette Backup-Historie und -Konfiguration gelöscht!
Die Backup-Daten bleiben aber erhalten.

1.) Folgenden Registry-Key setzen:

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Endpoint Backup
Value Name: RecreateDatabase
Value Type: DWORD
Value: 1 (= Reset Database)

2.) Neustart des Dienstes "Veeam Agent for Microsoft Windows"

3.) Neustart von Veeam Backup und es öffnet sich der Konfigurationsassistent! FERTIG!

Quelle:
tinkertry.com: How to manually reset your Veeam Endpoint Backup FREE database

Problem:
Wer kennt das nicht...ein VSS Writer steht nach dem Backup mit einem Fehler im System und Sie können den Server nicht neu starten, da dieser in Verwendung ist!

Lösung:

1.) Überprüfen Sie mit folgendem Befehl, welcher Writer im Fehler-Status ist:

vssadmin list writers

2.) Hier finden Sie alle VSS Writer und unter Status sollte "Stabil" stehen, ansonsten hat dieser einen Fehler
3.) Folgenden Dienst müssen Sie neu starten um den entsprechenden Writer wieder in den Status "Stabil" zu bekommen
(Achtung: Die Dienste sind in Englisch und könnten von Ihren Namen abweichen)


Quelle: datto: How to resolve VSS writer errors without rebooting (VShadow)

Problem:
Ich hatte einen Fehler beim Kopieren von Daten mittels Robocopy auf einem Server 2008R2. Hier kam ich folgenden Fehler bei einzelnen Dateien:

„2016/11/21 00:31:28 FEHLER 64 (0x00000040) Folgende Datei wird kopiert D:\blahblahblah.xlsm
Der angegebene Netzwerkname ist nicht mehr verfügbar.“


Lösung:
Nach etwas Suche und Recherche bin ich darauf gestoßen, dass der Parameter /Z in diesem Zusammenhang Probleme machen kann.
/Z : Copy files in restartable mode (survive network glitch)

Leider scheinen manche Shares damit Probleme zu haben, daher habe ich den Parameter komplett entfernt und somit wird per Default /B gewählt.
/B : Copy files in Backup mode

Ich habe jetzt alle Robocopy-Jobs angepasst und getestet…alles gut!

Problem:
Ich habe einen neuen Backupserver mit Windows Server 2008 R2 und BackupExec 2010 R3 SP4 installiert.
Gleich vorweg, da Problem ist auch mit BackupExec 2012 aufgetreten, war als unabhängig von der Version.
Mein gesamtes Backup lief problemlos durch, nur mein Exchange GRT-Backup-To-Disk schlug jedes mal mit dem Fehler E0000396 fehl.

'-546 The log file sector size does not match the sector size of the current volumn.

Die Fehlerscueh verlief wie folgt:

- Ein direktes GRT-Backup-To-Tape lief problemlos durch!
- Mein erster Verdacht war wirklich die Sektorengröße, die aber auf beiden Servern identisch war - also OK, was sich aber später als falsch erweisen sollte!
- Der zweite Verdacht war mein Backup-To-Disk-Ziel, dass ein lokales RAID-10 mit 3 TB umfasste und somit nicht MBR sondern GPT war - aber das war nicht das Problem.
- Nächster Verdacht waren 4k-Sectorsize Festplatten im Server - war nicht der Fall!
- Dann Update auf neue BackupExec Version - gleicher Fehler!!

Nach viel Try&Error, langen Gesprächen und drei Tagen testen fand ich die Lösung!!

Lösung:
Ich habe mir zwei andere Backupserver angeschaut und hier ist mir folgendes aufgefallen:

Du kannst Dir ja mittels „fsutil fsinfo ntfsinfo lw:“ die Laufwerksparameter anzeigen lassen.
Hier ist mir ein Unterschied beim Parameter „Bytes pro physischen Sektor“ aufgefallen:

Mein Backupserver


Mein Exchange-Server


Alter Backupserver


Es muss also mit den "Physical Bytes per Sector" Wertz zu tun haben.
Dann habe ich eine USB-Platte gefunden, die ebenfalls „nicht unterstützt“ bei den Infos anzeigt. Hierauf habe ich dann alle BackupExec-TEMP-Ordner gedreht und siehe da, dass Backup läuft!
Jetzt habe ich nach einer Möglichkeit gesucht, damit meine Platten ebenfalls diese Info nicht mehr anzeigen bzw. auch „nicht unterstützt“ bringen.
Nach längerer Suche bin ich tatsächlich über einen Reg-Key gestolpert, mit dem ich das Verhalten steuern kann. Das muss aber PRO Storage-Treiber eingetragen werden.

Pfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\\Parameters\Device
Name: EnableQueryAccessAligment
Typ: REG_DWORD
Wert: 0 = Disabled (Bytes per physical sector wird nicht übermittelt) / 1= Enabled (Bytes per physical sector wird angezeigt)

Nachdem ich den Reg-Key auf "0" gesetzt und meine Kiste durchgestartet habe, wurde die Angabe "Bytes per physical sectors" mit "not supported" angezeigt und mein GRT-Backup-To-Disk lief problemlos durch!!

Kleiner Tipp noch am Rande:
Um den Controller Name für den Service zu finden, geht man am besten in den Gerätemanager und öffnet die Eigenschaften des Speichercontrollers. Hier findet man auf dem Reiter "Details" ein DropDownMenü. Hier wählt man "Dienst" aus und sollte so den Namen des Dienstes erfahren.



…und wieder einmal verlässt das IT-Team siegreich das Schlachtfeld!!! ?

Quelle:
Understanding the Impact of Large Sector Media for IT Pros
(Hier Szenario 3)

Problem :

Ein Backup Auftrag wird immer mit Warnungen beendet.

VSS-Snapshotwarnung : Datei [Pfad und Name der Datei] ist im Snapshot nicht vorhanden

Lösung :

Bei mir war dieses Verhalten auf eine Fehlerhafte deinstallation der Software zurückzuführen. Die Dateien selbst wurden gelöscht allerdings nicht der Verweis unter
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PnpLockdownFiles nachdem ich der Administratorgruppe Vollzugriff
auf diesen Schlüssel gewährt hatte konnte ich die Verweise ohne Probleme löschen. Dannach war dieser Fehler behoben.

Problem :

Beim Versuch den lokalen Server zu sichern starb jedesmal die komplette Backup Exec 2012 Instanz nur ein Reboot konnte das System reanimieren.
In meinem Fall handelte es sich um einen Windows 2008 R2 Enterprise Server auf dem ein aktuellen Backup Exec 2012 (14.0 Rev 1798) läuft.
Nach langem Suche stellte sich herraus das der VSS Dienst der Grund war. Im Eventlog wurde folgender Eintrag gelogt:

Quelle : VSS

Ereignis-ID : 12293

Detail : Volumeschattenkopie-Dienstfehler: Beim Aufrufen einer Routine auf einem Volumeschattenkopieanbieter "GUID" ist ein Fehler aufgetreten. Routinedetails EndPrepareSnapshots(GUID) [hr = 0x80042302, Unerwarteter Fehler bei einer Komponente des Volumeschattenkopie-Diensts.Cannot find anymore diff area candidates

Lösung :

In meinem Fall hat die Vorgehensweise den Provider neu zu erstellen leider nichts geholfen. Zuerst habe ich das Skript aus diesem Beitrag ausgeführt.
Dann einen Reboot. Nachdem der Server wieder online war Explorer öffnen und einen Rechtsklick auf ein lokales Laufwerk machen. Dann auf Eigenschaften > Schattenkopie für die Laufwerke die gesichert werden sollen hab ich dann unter Einstellungen die Maximale Größe auf Unbegrenzt gesetzt. Sollte hier nicht genug Speicher verfügbar sein sollten mind. 15% der Laufwerksgröße angegeben werden. Nach einem klick auf OK lief auch das Backup wieder.




Quellen :
http://answers.microsoft.com/e.../-abdf-22efe4252979
http://www.symantec.com/connect/blogs/vss-fixbat
http://backupchain.com/Canno...y-service-error-troubleshooting.html