Suggestion to improve dealing with file errors during backup
Xavron opened this issue · 4 comments
Windows 11
Run backup
Point 1 - Backup failed pops up on the screen of which 1) is a problem itself as it disrupts the user in the worst way possible) and 2) the backup didn't actually fail so the message is completely wrong here.
Log:
Warning: at least one source file could not be read
...
error: open ...ntuser.dat.LOG1: The process cannot access the file because it is being used by another process. ...........blah blah yes VSS.
...
error: open ...AppData\Local\Temp\nsdBAB3.tmp: Access is denied. .........problem.
Point 2 - Its possible to make the GUI show a list of failed files with checkboxes or exclude all or whatever so that its quick and easy and awesome. The user shouldn't have to think "The backup failed. The backup is no good. I don't know what to do. Oh no! What's a log file? I can't do that. Where's the log file? I have to hunt through the log file. I have to manually copy and paste and exclude all files or manually exclude folders."
Of course, running in the background from the task in Task Scheduler does solve all of that to an extent. But, people won't see that way what files are not being backed up and would have to check the log every time. Instead, its possible to popup a non focus stealing notification such as "click here to view files that were not backed up" or whatever that shows the same thing as in point 2.
Point 3 - Should be able to just list them in their own file and then import the bytes into Strings and lines and have checkboxes or some other way. Technically, just putting them into their own log file would be tons better and should be quick to code.
Just a suggestion :)
And, btw, I know there's exclude, VSS, etc. That's not the point here. I know some people still won't get the point.
I see the Task Scheduler backup run does look like it compacts file errors in the log for easier viewing. At least its an improvement that cuts down the time wasted. Still, the rest pertains.
*or perhaps from lack of files to backup on following backups.
1/ As long as the backup did not succeed in doing what was asked, it's considered failed. Nobody wants to rely on incoherent backups. What you consider "completley wrong" is an assumption of your usecase where you don't care about some files. Now imagine backing up simple documents, and an important file isn't backed up because it was open and VSS failed, but your backup software tells you that everything is okay. That's my definition of "completley wrong".
2/ NPBackup's main target is the system administrator that will backup servers, and probably VIP laptops. The latter one might not know or even care what a log file is, but the administrator will.
The end user's main candy here is a nice GUI to restore files without the need to call for the sysadmins.
And yes, of course backups should always be run in background (hence the priority settings btw), since one cannot rely on the user to launch them periodically, manually via the GUI.
Since the user won't be aware if the backup suceed as background task, it's the sysadmin's task to verify backup coherence, hence the existence of prometheus support so the sysadmin can check hundreds of npbackup clients by a single status panel.
Thus being said, NPBackup is currently being improved to be able to act like a privileged orchestrator.
While refactoring, I also decided to improve the GUI to keep track of house keeping errors in a quick way.
My last commit afaa055 actually enables the backup core to send both logs and errors in separate channels, for better readability, and errors will be shown separately from logs.
Perhaps that will solve the issue you describe.
3/ Whatever GUI option with checkboxes you're talking about, I don't get it. Be more clear.
I see you see things differently. Closing.