Restore behavior

[coffee1978]

Hi,

I'm attempting to restore a mirror backup (encrypted with obfuscated filenames), and have run across some rather annoying behavior when clicking Cancel:

1. The file currently being restored is logged as "Error: Failed to restore ..." but the log lists the obfuscated filename (X:\1\2\3\4\F123) in the backup directory, *not* the filename being restored (C:\FOO\BAR.TXT). I have no idea where the restore was stopped at the time of cancellation.

2. The file that was currently being restored is kept in the restore directory. The restore itself was cancelled and this partially restored file is kept. Combined with #1 above, I cannot even clean up the file either. What is worse is the file size and date/time are set to the original size/date/time of the backed up file, so I cannot easily find the file manually. If I restart the restore and click Skip for preexisting files, this broken file is not replaced. Basically, I have no way to stop a restore in-progress and safely restart without risk of corrupting files.

Thanks

[Adrian (Softland)]

Hi,

1. What is the complete error message? (the reason)
If you try to extract that zip file using WinZip or 7zip, does it works?

2. Please try to repair that backup job, using the "Repair" option from Backup4all menu.

[coffee1978]

Please note this is about a restore, not backup

1. Testing the encrypted zip in the backup destination is fine. Since the restore was cancelled midstream, the restored file was incomplete and corrupted. The issue is logging makes it impossible to find the restored file, since the log only refers to the obfuscated filename in the backup destination. The second issue is the corrupted, half-restored file was kept instead of being deleted by B4A.

2. Won't a backup repair test the corrupted restored file, see it is different than the file in the backup destination, then backup/overwrite the backup with the corrupted file?

[Adrian (Softland)]

Hi,

Here is a quick solution:
1. Rename the broken file in sources to something else.
2. Run a restore with Skip existing files.
That should restore the "missing" file.

[coffee1978]

For #1, How do I know what file to rename when the logging is broken and printing the wrong information?

For #2, why would backup4all intentionally keep a half-restored file? I clicked Cancel, so the app had the opportunity to clean up what it knows is not complete. It's not like the app crashed or host crashed.

[Adrian (Softland)]

Hi,

#1. I understand you have a corrupt file and that is why you want to restore. If the restore was interrupted and you want to continue with the remaining files, you cannot do that. You need to run again the restore.

#2. I cannot know what happened there but when a file is overwritten, the process does not stop in the middle of the file copy, leaving the file corrupted.

[coffee1978]

I'll start from the beginning.

I am restoring a very large mirror backup, encrypted with obfuscated filenames. There is nothing in the directories where I an outputting the restore. It is a full restore from scratch. Nothing is being overwritten anywhere.

When I needed to click Cancel in the middle of this very large restore:

1. B4A printed a useless log message stating: Error: Failed to restore "Z:\OBFUSCATED\FILENAME\2\3\4\F4567". The obfuscated filename is 100% meaningless to me, the user. B4A should print the real filename, so the error message has value.

2. Clicking Cancel stops the in-progress operation immediately. It does not finish restoring the file that is in-progress when I clicked Cancel. B4A knows the in-progress restore of this file is incomplete but keeps the partially restored file anyway. This makes no sense. B4A should be smart enough to delete a file it knows was only partially restored.

Because of #1, I could not manually clean up the broken file created by B4A in #2. As such, there was no reliable way to continue the restore without wiping clean the entire restore destination. If I restarted the restore and told B4A to skip existing files, it would skip the existing partially restored file it created previously.

As I see it, I only have 2 options because this logging is broken in B4a - always restart a massive 52TB restore from scratch, or end up with random corrupted files in my restore if the restore ever needs to be interrupted. Both of those options are unacceptable. If the logging was helpful, I would have an acceptable 3rd option.

[Adrian (Softland)]

Hi,

I understand your position. The obfuscation was implemented this way so that no real name of the file will be logged. I will create a ticket to analyze if revealing the name of the files in log is possible without compromising the obfuscation.