Geplantes Backup bricht ab mit "Error: 65562 (0x1001A) Nicht genug Speicher"

[markus481]

Ich habe ein differentielles Backup von zwei Partitionen via FTP auf mein NAS erstellt. Das Backup lief einige Tage problemlos durch, bricht aber jetzt reproduzierbar mit der Fehlermeldung ab (auf dem NAS sind mehr als 1000 GB frei):

Error: 65562 (0x1001A)
Nicht genug Speicher

Hier der Auszug aus stubact.log:

################################################## ##############################
Applying a set of operations.
Time: 26.02.2013 18:00:33 (GM)
################################################## ##############################

__________________________________________________ ________26.02.2013 18:03:03 (GM)
[Operation]
Backup partition or disk
Code: 274 (0x112)
Virtual: 0 (0x0)
Error: 0 (0x0)

SOURCE
DiskNumber: 0 (0x0)
PartitionNumber: 0 (0x0)
Primary: 1 (0x1)
Letter: *
BaseArchive:: ftp:/192.168.178.31:21/BackupCSL/arc_030213121424317/arc_030213121424317_0000p.000

TARGET
Archive: ftp:/192.168.178.31:21/BackupCSL/diff_190213174610236/img_0_190213_174848904_2013_0226.PBF

PARAMETERS
One2One: 0 (0x0)
BackupMBR: 0 (0x0)
Backup1Track: 0 (0x0)
SetNamesAutomatically: 1 (0x1)
CompressionLevel: 10 (0xA)
SplitSize: 8192000 (0x7D0000)
Encrypted: 0 (0x0)
Incremental: 1 (0x1)
BackupTempFiles: 1 (0x1)
SignArchive: 0 (0x0)
BurnEntireDisc: 0 (0x0)
Label: Differentielle Sicherung, Basis ...24317.psl
HBOptions: 5 (0x5)
RawBackup: 0 (0x0)
VSSBackup: 1 (0x1)
__________________________________________________ ________26.02.2013 18:18:33 (GM)
[Operation]
Backup partition or disk
Code: 274 (0x112)
Virtual: 0 (0x0)
Error: 65562 (0x1001A)
Nicht genug Speicher

SOURCE
DiskNumber: 0 (0x0)
PartitionNumber: 1 (0x1)
Primary: 1 (0x1)
Letter: C
BaseArchive:: ftp:/192.168.178.31:21/BackupCSL/arc_030213121424317/arc_030213121424317_0001p.000

TARGET
Archive: ftp:/192.168.178.31:21/BackupCSL/diff_190213174610236/img_1_190213_174851307_2013_0226.PBF

PARAMETERS
One2One: 0 (0x0)
BackupMBR: 0 (0x0)
Backup1Track: 0 (0x0)
SetNamesAutomatically: 1 (0x1)
CompressionLevel: 10 (0xA)
SplitSize: 8192000 (0x7D0000)
Encrypted: 0 (0x0)
Incremental: 1 (0x1)
BackupTempFiles: 1 (0x1)
SignArchive: 0 (0x0)
BurnEntireDisc: 0 (0x0)
Label: Differentielle Sicherung, Basis ...24317.psl
HBOptions: 5 (0x5)
RawBackup: 0 (0x0)
VSSBackup: 1 (0x1)

################################################## ##############################
Closing stub engine.
Time: 26.02.2013 18:18:35 (GM)
################################################## ##############################

[Deutsches Paragon-Support-Team]

Hallo, markus481,

mit Verlaub - das kann nicht gelaufen sein. Ein differentielles Backup liest ja zuerst das Basis-Backup und ermittelt dann die Unterschiede, um nur die zu sichern. Über FTP (File Transfer Protocol !) können Dateien nur übertragen werden. Die Software kann über FTP keine Archivdatei zum Lesen öffnen. Auch für die Wiederherstellung muss ein Archiv zuerst über FTP nach lokal heruntergeladen werden, bevor sie gestartet werden kann. Für die Sicherung auf ein NAS erstellst Du zuerst eine Sicherung auf ein Netzlaufwerk. Dieses wird zuerst auf eine Laufwerksbuchstaben gemountet und dabei mit den nötigen Berechtigungen ausgestattet. Dann muss in dem Script der Laufwerksbuchstabe gegen den korrekten UNC-Pfad (oder wie im ftp-URL über die IP, natürlich ohne Port 21) getauscht werden. Beachte dazu bitte: http://support.paragon-software.com/...ull=1#post1952

[markus481]

Naja... klingt logisch, aber die Sicherung der Partition 0 auf Disk 0 (Recovery partition) funktioniert offenbar doch??? Erst Partition 1 Disk 0 führt zu einem Fehler.

Außerdem bin ich ziemlich sicher, daß das Script schon einmal durchgelaufen ist, siehe stubact.log Auszug vom 15.2. (s.u.). Oder sind die damals erzeugten Archive wertlos?

Last not least läßt der Assistent das Erstellen eines Scripts mit Target auf einem FTP Server klaglos zu... und die Einbindung des NAS via Laufwerksbuchstabe funktioniert bei mir nicht zuverlässig.

Viele Grüße, Markus
__________________________________________________ ________15.02.2013 17:00:19 (GM)
>> [Operation]
>> Backup partition or disk
>> Code: 274 (0x112)
>> Virtual: 1 (0x1)
>> Error: 0 (0x0)
>>
>> SOURCE
>> DiskNumber: 0 (0x0)
>> PartitionNumber: 0 (0x0)
>> Primary: 1 (0x1)
>> Letter: *
>> BaseArchive:: ftp:/192.168.178.31:21/BackupCSL/arc_030213121424317/arc_030213121424317_0000p.000
>>
>> TARGET
>> Archive: ftp:/192.168.178.31:21/BackupCSL/diff_030213172631105/img_0_030213_172856747_2013_0215.PBF
>>
>> PARAMETERS
>> One2One: 0 (0x0)
>> BackupMBR: 0 (0x0)
>> Backup1Track: 0 (0x0)
>> SetNamesAutomatically: 1 (0x1)
>> CompressionLevel: 2 (0x2)
>> SplitSize: 8192000 (0x7D0000)
>> Encrypted: 0 (0x0)
>> Incremental: 1 (0x1)
>> BackupTempFiles: 1 (0x1)
>> SignArchive: 0 (0x0)
>> BurnEntireDisc: 0 (0x0)
>> Label: Differenzsicherung, basierend auf ..24317.psf
>> HBOptions: 5 (0x5)
>> RawBackup: 0 (0x0)
>> VSSBackup: 1 (0x1)
__________________________________________________ ________15.02.2013 17:00:23 (GM)
>> [Operation]
>> Backup partition or disk
>> Code: 274 (0x112)
>> Virtual: 1 (0x1)
>> Error: 0 (0x0)
>>
>> SOURCE
>> DiskNumber: 0 (0x0)
>> PartitionNumber: 1 (0x1)
>> Primary: 1 (0x1)
>> Letter: C
>> BaseArchive:: ftp:/192.168.178.31:21/BackupCSL/arc_030213121424317/arc_030213121424317_0001p.000
>>
>> TARGET
>> Archive: ftp:/192.168.178.31:21/BackupCSL/diff_030213172631105/img_1_030213_172859399_2013_0215.PBF
>>
>> PARAMETERS
>> One2One: 0 (0x0)
>> BackupMBR: 0 (0x0)
>> Backup1Track: 0 (0x0)
>> SetNamesAutomatically: 1 (0x1)
>> CompressionLevel: 2 (0x2)
>> SplitSize: 8192000 (0x7D0000)
>> Encrypted: 0 (0x0)
>> Incremental: 1 (0x1)
>> BackupTempFiles: 1 (0x1)
>> SignArchive: 0 (0x0)
>> BurnEntireDisc: 0 (0x0)
>> Label: Differenzsicherung, basierend auf ..24317.psf
>> HBOptions: 5 (0x5)
>> RawBackup: 0 (0x0)
>> VSSBackup: 1 (0x1)
__________________________________________________ ________15.02.2013 17:00:23 (GM)
>> [Operation]
>> Merge archives into one archive
>> Code: 281 (0x119)
>> Virtual: 1 (0x1)
>> Error: 0 (0x0)

[Deutsches Paragon-Support-Team]

Hallo, markus481,

da ich durch die Erfolgsmeldung in dem ersten Log-Schnipsel oben verunsichert war, habe ich es jetzt mal ausprobiert, und es funktioniert tatsächlich - zumindest im lokalen Netz. Sogar die Wiederherstellung der differentiellen Sicherung ist möglich. Ich kann allerdings bei uns nicht herausfinden, wann und ob jemals so etwas in unsere Software implementiert worden wäre. Na, egal.

Wie sind die Partitionen auf dem NAS formatiert? Wenn das z. B. FAT32 wäre und Du das 4-GB-Splitting abgeschaltet hättest, wäre das eine Erklärung. FAT32 kann keine Dateien größer 4 GB und dann kommt genau die Meldung "Nicht genug Speicher".

Noch ein paar Anmerkungen:

Der untere Auszug aus der stubact.log ist der virtuelle Teil. Dies lässt sich an den Doppelpfeilen am Zeilenanfang erkennen. Danach kommt in der Regel die tatsächliche Ausführung ohne Pfeile wie in dem oberen Auszug. Meist treten erst dort die Fehler auf, wenn denn überhaupt gestartet wird.

Das Thema "NAS mit Laufwerksbuchstabe funktioniert nicht" hatten wir hier im Forum jetzt schon mehrfach.

Beim Anlegen der Aufgabe wird das NAS auf einen Laufwerksbuchstaben gemountet, indem man den UNC-Pfad in dem Textfeld einträgt. Dabei muss auch ein Benutzername mit Passwort eingegeben werden, der auf dem NAS lesen und schreiben darf. Wenn diese Aufgabe zeitgesteuert angelegt wird, scheitert sie oft beim zweiten Mal. Grund ist die Benutzerkontensteuerung (UAC), die mit Windows Vista eingeführt wurde.

Die Benutzerkontensteuerung verhindert, dass unsere Software die Verbindung zu dem Netzlaufwerk über den Buchstaben wiederherstellen kann. Dies kann man umgehen, indem man die Scripte bearbeitet. Wenn man in den Scripten den Laufwerksbuchstaben durch den entsprechenden UNC-Pfad ersetzt, sollte die Sicherung eigentlich funktionieren.

[markus481]

Mein NAS ist mit EXT4 formatiert, mein PC mit NTFS. Da sollte das Problem also nicht liegen.

[Deutsches Paragon-Support-Team]

Hallo, markus481,

tritt der Fehler denn auch auf, wenn Du wie anderenorts beschrieben über den UNC-Pfad sicherst?