*.bak datei wird nicht gesichert

[#1]

Hallo,

ich habe ein Problem bei der Datensicherung.

Vor der Datensicherung wird der SQL Server per Skript gestoppt (net stop MSSQL$DATEV_DBENGINE /Y).

Die Sicherung beginnt 20 Minuten später. Dabei werden alle Daten gesichert, bis auf die folgende Datei:

ERROR: Beim Kopieren ist ein Fehler aufgetreten: #5 - Zugriff verweigert [CopyFile3] (D:\windvsw1\DATEV\DATEN\K0005064\DATA\STANDARD\2017_2_13_14_37_36_SI.bak

Die zwei anderen *:bak Dateien in dem gleichen Verzeichnis werden problemlos kopiert.

Hat jemand eine Idee was hier schief läuft?

Gruß Denzel

[#2]

Moin,

wenn es sich um eine .bak handelt, die von der DATEV SQL Onlinesicherung erzeugt wurde, könnte es sich um ein Rechteproblem handeln. Die .bak werden im Systemkontext erzeugt, hat der Sicherungsoperator nicht die nötigen Rechte kann die Datei nicht gesichert werden.

Gruß

KP

[#3]

Schau mal via Explorer auf den Eigentümer der Datei. Alternativ sitzt noch ein hängender Prozess auf der Datei der sie exklusiv RW-Lock geöffnet hat.

Wenn Du Generationen sicherst würde ich *.bak Dateien eh ausschliessen.

Bernd

[#4]

unbedingt Testen, ob das Problem nach einem Neustart des Servers weiter besteht.

[#5]

Hallo,

herzlichen Dank für die Antworten.

Nach dem Neustart des Rechners besteht das Problem weiter.

Eigentümer der Datei ist der User mit Adminrechten. Dieser ist standadmäßig eingeloggt und über ihn läuft bei der Datensicherung der Dateizugriff.

Das System wird jede Nacht gesichert. Das heißt zu diesem Zeitpunkt arbeitet in der Regel seit drei bis 4 Stunden niemand mehr auf dem System. Ist es da überhaupt nötig die *.bak Datei miit zu sichern?

Denzel

[#6]

Frage an einen DATEV- Techniker:

Können diese bak- Dateien bedenkenlos entsorgt werden?
Hier tummeln sich ein Dutzend Bak- Dateien, die wohl seit Jahren bei jedem Update erzeugt wurden und dann als Datenmüll stehen blieben.

[#7]

Das System wird jede Nacht gesichert. Das heißt zu diesem Zeitpunkt arbeitet in der Regel seit drei bis 4 Stunden niemand mehr auf dem System. Ist es da überhaupt nötig die *.bak Datei miit zu sichern?

*.bak und *.tmp werden generell nicht mitgesichert.

Bernd

[#8]

Gerade bei DATEV sollten wirklich alle Daten mitgesichert werden und eine gesperrte Bak- Datei ist bei gestoppten Diensten ein nicht zu ignorierendes Alarmsignal, da die Möglichkeit besteht, daß die verantwortliche Anwendung beim nächsten Update durch die gesperrte Datei gegen eine Wand kracht und die notwendige Datenanpassung nicht erfolgt, oder schon seit dem letzten Update Probleme verursachte. (hier: Basisdienste Office)

[#9]

Gerade bei DATEV sollten wirklich alle Daten mitgesichert werden und eine gesperrte Bak- Datei ist bei gestoppten Diensten ein nicht zu ignorierendes Alarmsignal, da die Möglichkeit besteht, daß die verantwortliche Anwendung beim nächsten Update durch die gesperrte Datei gegen eine Wand kracht und die notwendige Datenanpassung nicht erfolgt, oder schon seit dem letzten Update Probleme verursachte. (hier: Basisdienste Office)

Ist die DATEV Software wirklich noch schlechter als ich es in meinen kühnsten Alpträumen hatte? Weia....

Bernd

[#10]

Mit welchem Backup-Programm wird denn gesichert?

Welcher Virenscanner ist auf dem System?

Ist der Backup-User Mitglied der "Sicherungs-Operatoren"?

[#11]

Hier scheint das Problem nicht die Backup- Routine zu sein, sondern daß bei einer 14 Tage alte bak- Datei trotz System- Neustart der Zugriff nicht möglich ist.

Da ist irgend etwas am 13.2.2017 schief gelaufen...

Hier lassen sich alle bak- Daten aus L:\Datev\DATEN\K0005064\DATA\STANDARD im laufenden Betrieb mit dem Explorer kopieren.

[#12]

Moin,

na da hab ich ja eine Diskusion losgetreten.

Das Backupprogramm heißt ALLsync. Es läuft auch auf anderen Servern hier im Haus.

Unter anderem auch auf einem Server auf dem ein anderer SQL Server läuft (Waageprogramm). Da gibt es keine Probleme.

Den Virenscanner (GData) haben wir aktuell deinstalliert und nur Bordmittel laufen.

Ich weiß das ist nicht gut, aber wir wollten Ausschließen, dass es damit zusammenhängt.

Letztendlic wurde aber meine Frage noch nicht wirklich beantwortet.

Brauch ich die Datei nun für eine Widerherstellung oder nicht. Kann ich den Fehler ignorieren, wenn alle anderen Dateien gesichert werden?

[#13]

Der GData ist auch auf dem Backup Ziel komplett deinstalliert?

Laut der AllSync Homepage kann das Tool auch auf VSS zurückgreifen zum Sichern. Funktioniert es mit der Option?

Ansonsten scheint der Fehler 3 auf Verbindungsprobleme zum Backup Ziel zu deuten: AllSync - Ordner und Dateien sichern, Daten sichern, PC abgleichen

Ignorieren würde ich den Fehler nicht (Auch wenn die Datei nicht für den Restore gebraucht werden sollte). Sowas kann auch mal ein erstes Zeichen für ein defektes Dateisystem o.ä. sein.

[#14]

Ansonsten scheint der Fehler 3 auf Verbindungsprobleme zum Backup Ziel zu deuten: AllSync - Ordner und Dateien sichern, Daten sichern, PC abgleichen

Es war die Fehlernummer #5 "Zugriff verweigert". #3 ist auch eher "Ich soll was sichern was plötzlich nicht mehr da ist". Fehler im Dateisystem laufen vermutlich auf einen #1117 hinaus.

Mich macht genauso wie Martin stutzig, dass auf die Datei nicht zugegriffen werden kann.

@Andreas: kannst Du mal als Administrator ein Kommandozeilenfenster aufmachen und die genannte Datei von Hand irgendwohin kopieren? Wenn das geht, ist es "nur" ein Rechteproblem. Du könntest dann einfach dieser BAK-Datei die gleichen Rechte geben wie den anderen BAK-Dateien und gut ist.

Bernd

[#15]

Menschenkinder.. Da habe ich mich von der 3 bei [CopyFile3] verleiten lassen

Ohne Rechteanpassung sollte das mit robocopy im Backupmodus (robocopy QUELLE ZIEL /B) klappen.

Wenn man dann noch wenige andere Schalter tätigt und ein bisschen den Taskplaner bemüht, hat man vermutlich ein gratis AllSync

[#16]

Menschenkinder.. Da habe ich mich von der 3 bei [CopyFile3] verleiten lassen

Komm vorbei, hier gibt es frisch gepressten Espresso

Ohne Rechteanpassung sollte das mit robocopy im Backupmodus (robocopy QUELLE ZIEL /B) klappen.

Auch Robocopy ist kein Deus Ex Machina was Wunder vollbringen kann - wenn das Programm mit den gleichen Rechten wie Allsync läuft wird er auch scheitern (es sei denn, Allsync hat an der Stelle einfach einen Bug und kommt zb. mit dem Dateinamen nicht klar.

Bernd

[#17 · Accepted solution]

So.........

Um der Sache hier ein Ende zu machen 🙂

Es war ein Rechteproblem. Ich habe mir an den anderen *.bak Dateien mal die Rechte genau angesehen. Für die besagte Datei waren die Rechte, warum auch immer, anders gesetzt.

Nachdem ich es geändert habe lässt sie sich problemlos kopieren.

Espresso? Das ist ne gute Idee! Ich gehe mir einen holen.