Willkommen Gast 

Infos ein-/ausblenden

Willkommen Gast! Um Beiträge zu verfassen musst Du registriert sein.





Seiten: [1]
Autor Thema:Fehlgeschlagenes Backup mit 2.2
cv55
Neuling
Beiträge: 3
Permalink
avatar
Beitrag Fehlgeschlagenes Backup mit 2.2
am December 29, 2015, 22:54
Zitat

Hallo,

habe beim Start heute auf 2.2.0.9111 upgedated (und die massenhaften Beschwerden von Kaspersky über den Installer durchaus mit "vertrauenswürdiges Programm" weggeklickt). Das schon oft erfolgreich durchgeführte Backup bricht aber nach 2-3 Sekunden mit Fehler ab (Log-Auszug s. unten).

Beim Neustart bemerkt HLBU den Fehlschlag und kündigt an, dass der fragliche Satz "durch eine Aufräumregel" gelöscht werde. Wird er aber nicht: Vielmehr wird überhaupt kein Backup durchgeführt, weil "bereits ein Backupsatz X:\Pfad\MyBackup_YYYY-MM-DD existiert" - und auch nichts "aufgeräumt". (Nochmal "Löschen" anklicken nützt ebenfalls nichts.)

Nun könnte ich den Namen einfach abwandeln. - Muss aber, falls der Fehlschlag dann wieder nicht gelöscht wird und als 'leerer' Satz auf der Platte bleibt, nicht die komplette Datei- (bzw. Link-)struktur neu aufgebaut werden? Bei gut einem TB aus vielen kleinen Daten dauert das gern mal 1-2 Tage -- aus demselben Grund würde ich auch nicht gern einfach eine neue Backup-Definition aufsetzen, sondern die alte behalten...

Kurzum, drei Fragen:
- Was ist eigentlich schiefgelaufen?
- Wie werde ich den fehlerhaften Backupsatz los?
- Wenn's elegant nicht geht, gibt es eine Möglichkeit, den 'Fehler-Satz' aus HLBUs Gedächtnis (Protokoll/DB) zu streichen und manuell zu entfernen?

Beste Grüße,
Volker

- und hier noch ein paar {gekürzte} Zeilen aus dem Fehler-Log:

[19:22:38.95] INF: Create target directory "X:\{Pfad}_2015-12-29"
[19:22:38.98] INF: Check file access rights to "X:\{Pfad}_2015-12-29"
[19:22:39.74] INF: Support (+/-/?): +PreserveCaseNames,+SupportUnicodeNames,+PersistentAcls,+SupportCompression,+SupportsSparseFiles,+SupportsReparsePoints,+SupportsEncryption,+SupportsHardLinks,+SupportsHardLinkRead,+SupportsSymLinks,+SupportsAlternativeDataStreams,-ReadOnly,+WriteAccess,+WritePermissions
[19:22:39.79] INF: Create log-file "X:\{Pfad}.log"
[19:22:39.81] INF: Create log-file "C:\ProgramData\Lupinho.Net\HardlinkBackup\CachedBackupSets\X_\{Pfad}_2015-12-29\backup_{Date-Time}.log"
[19:22:39.84] INF: Directory "X:\{Pfad}_2015-12-29" online.
[19:22:39.84] INF: Start watching target "X:\{Pfad}_2015-12-29" (online).
[19:22:39.86] INF: Start backup process
[19:22:40.09] INF: Use "index.hbi" for "X:\{Pfad}_2015-12-16"
[19:22:40.30] INF: Use "index.hbi" for "X:\{Pfad}_2015-11-16"
[19:22:40.46] INF: Use "index.hbi" for "X:\{Pfad}_2015-11-02"
[19:22:40.77] FAT: The worker "FileScanWorker" failed because an exception occured:
[19:22:40.77] FAT: CalculateBackupActionWithoutPartition(Lupinho.Net.HardlinkBackup.Engine.FileVariant.BaseEntry,Users\Administrator\Anwendungsdaten[Directory,Unchanged,{DirectoryJunction["U:\Users\Administrator\Anwendungsdaten",{gekürzt:unveränderte Daten eines ungenutzten Users...})
[19:22:40.82] MSG: Creating directory "X:\{Pfad}_2015-12-29\Users"
[19:22:40.83] FAT: Worker "BackupProcessorWorker_0" aborted.
[19:22:40.85] FAT: Worker "PostProcessorWorker_0" aborted.
[19:22:40.88] INF: Writing backup set info for target "X:\{Pfad}_2015-12-29"
[19:22:40.90] FAT: Worker "ScanBackupWorker" aborted.
[19:22:40.91] INF: Backup process failed
[19:22:40.98] FAT: The worker "FullBackupWorker" failed because an exception occured:
[19:22:40.99] FAT: The sub-worker "ScanBackupWorker" has been failed.
[19:22:40.99] INF: Closing backup...
[19:22:41.02] INF: Summary:
[19:22:41.05] INF:   Backup time: 19:22 - 19:22 (02.566 seconds)
[19:22:41.05] INF:   Processed 0 file (0 Byte) in 1 directories
[19:22:41.06] INF:   5 errors and 0 warnings occured
[19:22:41.06] INF: Backup failed with 5 errors.
cv55
Neuling
Beiträge: 3
Permalink
avatar
Beitrag Re: Fehlgeschlagenes Backup mit 2.2
am December 30, 2015, 11:03
Zitat

**Hallo nochmal, ich weiß nicht, ob's überall so ist - ich sehe aber gerade, dass (bei mir) nur ein Teil
**der Zeilen angezeigt wird und man nicht 'raus' scrollen kann 🙁 Vielleicht, weil ich's von einem falschen
**Platz hier rein kopiert habe? - Anyway: hier nochmal mit Zeilenumbrüchen: v.

habe beim Start heute auf 2.2.0.9111 upgedated (und die massenhaften Beschwerden von Kaspersky
über den Installer durchaus mit "vertrauenswürdiges Programm" weggeklickt). Das schon oft erfolgreich
durchgeführte Backup bricht aber nach 2-3 Sekunden mit Fehler ab (Log-Auszug s. unten).

Beim Neustart bemerkt HLBU den Fehlschlag und kündigt an, dass der fragliche Satz "durch eine
Aufräumregel" gelöscht werde. Wird er aber nicht: Vielmehr wird überhaupt kein Backup durchgeführt,
weil "bereits ein Backupsatz X:\Pfad\MyBackup_YYYY-MM-DD existiert" - und auch nichts "aufgeräumt".
(Nochmal "Löschen" anklicken nützt ebenfalls nichts.)

Nun könnte ich den Namen einfach abwandeln. - Muss aber, falls der Fehlschlag dann wieder nicht
gelöscht wird und als 'leerer' Satz auf der Platte bleibt, nicht die komplette Datei- (bzw.
Link-)struktur neu aufgebaut werden? Bei gut einem TB aus vielen kleinen Daten dauert das gern mal
1-2 Tage -- aus demselben Grund würde ich auch nicht gern einfach eine neue Backup-Definition
aufsetzen, sondern die alte behalten...

Kurzum, drei Fragen:
- Was ist eigentlich schiefgelaufen?
- Wie werde ich den fehlerhaften Backupsatz los?
- Wenn's elegant nicht geht, gibt es eine Möglichkeit, den 'Fehler-Satz' aus HLBUs Gedächtnis
(Protokoll/DB) zu streichen und manuell zu entfernen?

Beste Grüße,
Volker

- und hier noch ein paar {gekürzte} Zeilen aus dem Fehler-Log:

[19:22:38.95] INF: Create target directory "X:\{Pfad}_2015-12-29"
[19:22:38.98] INF: Check file access rights to "X:\{Pfad}_2015-12-29"
[19:22:39.74] INF: Support (+/-/?): +PreserveCaseNames,+SupportUnicodeNames,+PersistentAcls,
   +SupportCompression,+SupportsSparseFiles,+SupportsReparsePoints,+SupportsEncryption,
   +SupportsHardLinks,+SupportsHardLinkRead,+SupportsSymLinks,+SupportsAlternativeDataStreams,
   -ReadOnly,+WriteAccess,+WritePermissions
[19:22:39.79] INF: Create log-file "X:\{Pfad}.log"
[19:22:39.81] INF: Create log-file "C:\ProgramData\Lupinho.Net\HardlinkBackup\CachedBackupSets\
   X_\{Pfad}_2015-12-29\backup_{Date-Time}.log"
[19:22:39.84] INF: Directory "X:\{Pfad}_2015-12-29" online.
[19:22:39.84] INF: Start watching target "X:\{Pfad}_2015-12-29" (online).
[19:22:39.86] INF: Start backup process
[19:22:40.09] INF: Use "index.hbi" for "X:\{Pfad}_2015-12-16"
[19:22:40.30] INF: Use "index.hbi" for "X:\{Pfad}_2015-11-16"
[19:22:40.46] INF: Use "index.hbi" for "X:\{Pfad}_2015-11-02"
[19:22:40.77] FAT: The worker "FileScanWorker" failed because an exception occured:
[19:22:40.77] FAT: CalculateBackupActionWithoutPartition(Lupinho.Net.HardlinkBackup.Engine.
   FileVariant.BaseEntry,Users\Administrator\Anwendungsdaten[Directory,Unchanged,{DirectoryJunction
   ["U:\Users\Administrator\Anwendungsdaten",{gekürzt:unveränderte Daten eines ungenutzten Users...})
[19:22:40.82] MSG: Creating directory "X:\{Pfad}_2015-12-29\Users"
[19:22:40.83] FAT: Worker "BackupProcessorWorker_0" aborted.
[19:22:40.85] FAT: Worker "PostProcessorWorker_0" aborted.
[19:22:40.88] INF: Writing backup set info for target "X:\{Pfad}_2015-12-29"
[19:22:40.90] FAT: Worker "ScanBackupWorker" aborted.
[19:22:40.91] INF: Backup process failed
[19:22:40.98] FAT: The worker "FullBackupWorker" failed because an exception occured:
[19:22:40.99] FAT: The sub-worker "ScanBackupWorker" has been failed.
[19:22:40.99] INF: Closing backup...
[19:22:41.02] INF: Summary:
[19:22:41.05] INF:   Backup time: 19:22 - 19:22 (02.566 seconds)
[19:22:41.05] INF:   Processed 0 file (0 Byte) in 1 directories
[19:22:41.06] INF:   5 errors and 0 warnings occured
[19:22:41.06] INF: Backup failed with 5 errors.
HLB
Anfänger
Beiträge: 28
Permalink
avatar
Beitrag Re: Fehlgeschlagenes Backup mit 2.2
am December 30, 2015, 23:08
Zitat

Zitat von cv55 am December 30, 2015, 11:03
**Hallo nochmal, ich weiß nicht, ob's überall so ist - ich sehe aber gerade, dass (bei mir) nur ein Teil
**der Zeilen angezeigt wird und man nicht 'raus' scrollen kann 🙁 Vielleicht, weil ich's von einem falschen
**Platz hier rein kopiert habe?

Nein, hier ist das nicht so. Der erste Beitrag ohne deine zusätzlichen Umbrüche lässt sich deutlich besser lesen. Da gibts nämlich nicht abwechselnd eine lange und eine kurze Zeile. Wobei das allerdings stark von den Browsereinstellungen (insbesondere minimale Schriftgröße) und der Fenstergröße beeinflusst wird.

Edit: in Firefox, Opera 34 und Vivaldi wird der Text hier ebenfalls abgeschnitten, Opera 12 bricht den um. Vermutlich ein Fehler hier im Forum, denn das "Valid XHTML 1.1 and CSS 3" (unten auf jeder Seite) ist gelogen (einfach mal die Links anklicken und die Fehlermeldungen und Warnungen bewundern.)

lupinho
Administrator
Beiträge: 713
Permalink
avatar
Beitrag Re: Fehlgeschlagenes Backup mit 2.2
am December 31, 2015, 16:38
Zitat

Damit ich was dazu sagen kann, brauche ich die komplette Fehlermeldung. Bitte als Protokolleinstellung "detailliert" wählen (in den Einstellungen) und mir bitte die Log-Datei eines fehlgeschlagenen Backups an software@lupinho.net schicken. Dann kann ich herausfinden, was da schief gegangen ist.

cv55
Neuling
Beiträge: 3
Permalink
avatar
Beitrag Re: Fehlgeschlagenes Backup mit 2.2
am January 2, 2016, 15:59
Zitat

Hallo,
hier nochmal ein 'Zwischenstand' zu meinem Problem - das, zusammengefasst, vielleicht nicht wirklich eines von HLB ist:
(1) Der Fehler, warum HLB das angeforderte Backup überhaupt nicht mehr startete, war, dass ich es über einen Link in der Win-Schnellstartleiste aufrufe; der wurde beim Upgrade neu geschrieben (laut Dateidatum) und hat dabei wohl den Startparameter "mit Admin-Rechten" verloren, den das Backup aller Userprofile natürlich braucht. (Ich erinnere mich zwar nicht, damit bei früheren Updates Probleme gehabt zu haben - weswegen ich auch nicht dran gedacht habe... -, aber jetzt geht's ja wieder).
(2) Das als Admin gestartete Backup läuft zwar für 2 Stunden gut durch, bricht dann aber mit der Meldung "Der Dienst 'HardlinkBackup Service' konnte nicht erreicht werden." ab. Was stimmt: er läuft nicht - zumindest in diesem Moment; und da ich davon ausgehe, dass HLB ihn schon vom Start an braucht, vermute ich mal, dass er abgestürzt ist. HLB bietet an, ihn neu zu starten, schafft es aber nicht (vermutlich stürzt er gleich wieder ab); ihn manuell zu starten, bringt auch nichts; das nächste PopUp erklärt stets, es werde "gerade ein Backup durchgeführt", das man abbrechen oder "im Hintergrund fortsetzen" kann - das Letztere aber passiert nicht, es kommt auch über Stunden kein Bit mehr dazu... (Der Vollständigkeit halber: auch eine Neuinstallation -ohne Virenscanner- ändert nichts daran.)
(3) Der Abbruch erfolgt, soweit ich sehe, immer an derselben Stelle - mitten in dem Directory-Zweig, in dem ich gerade arbeite (und die Stelle deshalb schnell finde). Aus demselben Grund habe ich auch auf der Platte einen Hardlink (Junction) aus den Tiefen der Ordnerhierarchie 'nach oben' gelegt - Beispiel:

HDD:/documents/texte/projekte/2015/oktober/material/datenbank/
// ist jetzt erreichbar über:
HDD:/documents/datenbank

Sehe ich mir das auf der Backupquelle näher an, sieht es aus wie erwartet: "HDD:/documents/datenbank" hat "Linkeigenschaften", die auf die obere Zeile des Beispiels verweisen; alles, was 'darunter' an Daten und Verzeichnissen folgt, 'verhält' sich wie ein 'normaler' Inhalt.
Im HL-Backup aber sieht es anders aus - auf das obige Beispiel übertragen, verweisen an der offenbar zuletzt geschriebenen Stelle (also der des Abbruchs) sowohl "BU:/2016-01-02/documents/texte/projekte/2015/oktober/material/datenbank/version3" als auch "BU:/2016-01-02/documents/datenbank/version3" als "Verknüpfungsziel" auf "BU:/2016-01-02/documents/datenbank/version3" - und finden sie (beide) nicht...
An diesem Punkt beginnt mir die Komplexität dessen, was ich da veranstalte, ein bisschen unüberschaubar zu werden 🙁 Ich kann natürlich die o.g. 'Junction nach oben' künftig vom Backup ausschließen - nötig ist ihre Sicherung ja nicht, da die Daten ja 'unten' noch da sind. Allerdings verwende ich manuelle Hardlinks bzw. Junctions öfters - wo immer die Baumhierarchie halt zu starr ist. Und auch damit hatte ich bisher nie Probleme - HLB erhält interne und externe [sind das eigentlich (auch) solche im LAN und/oder WAN?] Links ja. Warum aber scheitert es an der 'einen' Stelle?
(Hängt es mit den - vielleicht aus anderen Gründen - gescheiterten Backups zusammen? Mittlerweile habe ich ja 4 oder 5 'Backup-Leichen' auf der Sicherungsplatte, von denen mir immer noch nicht klar ist, ob ich sie bedenkenlos manuell löschen kann. Soweit ich sehe, gleicht HLB seine neuen Sicherungen mit den letzten erfolgreichen Backups ab und ignoriert die gescheiterten; ganz sicher bin ich nicht.)
Soweit erst mal, und danke fürs Mitdenken, wer's bis hierher mitgemacht hat 🙂
Volker.

lupinho
Administrator
Beiträge: 713
Permalink
avatar
Beitrag Re: Fehlgeschlagenes Backup mit 2.2
am January 3, 2016, 01:03
Zitat

Du kannst abgebrochene Backups bedenkenlos manuell löschen. Du kannst sie aber auch zum Vergleich markieren (mit gedrückter STRG-Taste).

Seiten: [1]
Mingle Forum by cartpauj
Version: 1.0.34 ; Die Seite wurde geladen in: 0.06 Sekunden.