warning message on last nights tape backup

[B2r2]

Hi

Not sure if I need to open a support case with Veeam about this as it may not be a problem.

My last night file backup to tape, which read and transferred all data has the following warning message on it: -
Volume E: has 14 problems. Details: The handle is invalid.

Can anyone advice on this?

Thanks
Craig

[veremin]

We haven't seen this issue previously, so, kindly, reach our support team for further investigation. Thanks.

[idepolo]

I have the same problem. Any solution?

Volume C: has 15 problems. Details: The handle is invalid.

thanks.

[lyapkost]

Hi Ignacio. Is there any chance you include system directories such as C:\Windows\System32 to your file to tape job?

[idepolo]

Hi lyapkost,

I included the directory c:/windows/system32 to different tape jobs, but the problem is the same. In some cases there are more problems.

Volume C: has 10 problem. Details: The handle is invalid.
Volume C: has 195 problem. Details: The handle is invalid.
Volume C: has 175 problem. Details: The handle is invalid.

[csydas]

Hey Ignacio,

Most of the time this is either access denied issues or temp files that got enumerated by the job but were later no longer present. (Like Word ~Wordfile.docx files).

You could do some self-investigation in the job logs for the warning message and see exactly what is causing problems.

[lyapkost]

That is correct, the warning is displayed when the file is unreadable for any reason or contains some Unicode characters in name. One can check which files caused warnings in logs: C:\ProgramData\Veeam\Backup\tape_job_name\Task.hostname.log

Also I can explain my question and the warning when system files are backed by file to tape job in 64-bit Windows. The process that collects the hierarchy is a 32-bit process (Veeam Installer Service) meanwhile the Veeam data mover which reads and transfers the files is a 64-bit process. When a 32-bit process tries to read files in C:\Windows\System32 directory, Windows redirects it to to C:\Windows\SysWOW64 where the files are actually located so Installer Service 'thinks' the files are there. But a 64-bit process cannot find these files in C:\Windows\System32 directory and is not redirected, as a result you receive a warning.

[idepolo]

Thanks a lot. Everything very clear.

[jessie0]

Hello,
I have received a somewhat similar warning during file to tape backup.
It says;
Volume D: has 2 problems. Details: Problem with reading from source.

Please how do i go about solving this problem?

Thank you.

[Dima P.]

jessie0,

Can you please clarify if backup was performed with VSS options enabled? Thanks!

[jessie0]

Hello Dima,

I thought that might be the problem. But after disabling VSS option, it didn't change.
I redirected the data to a different disk drive and was able to back up to tape.
My D:\ drive was probably the problem.

Thanks!

[jessie0]

Hello Dima,
Now I am trying a direct file to tape backup from a client server to my tape server(Without first backing up to disk). With VSS enabled, I received a similar error.
"Volume C: has 232 problems. Details: Problem with reading from source."

With VSS disabled, I still received the same error. "Volume C: has 249 problems. Details: Problem with reading from source."
Just above these error in the action log I get a "Backup completed successfully" notification but the status ends with a warning.

I don't know how to go about solving this problem.

Thank you.

[veremin]

May we ask you to reach our support team for further investigation? Looks like an issue that cannot be resolved successfully via forum correspondence. Thanks!

[jessie0]

Hello Veremin,

Thanks for responding.
I opened a case (#04015491) with support team and they have been trying to help me figure out what the problem is.
I have tried all the solutions they proffered but the problem still persists.

Funny thing is that my first attempt at "file to tape" backup of my physical client server completed successfully without agent installed in the server.
This problem started after I installed agent in the client machine. My VB&R server has agent already installed and I also could not backup the drives.
I uninstalled the agent in the client machine and retried the job but it produced the same error.
A re-install of the OS did not change anything.
After going through the log files, support team thought that it was a permission problem, but I can access all these drives from windows explorer and the administrator account that I use has full control.
I was also asked to disable anti-virus software and windows FW but nothing changed.

Has anyone experienced an error like this?
Please how did you fix it?

Thanks.

[hhpp99]

Hello jessie,
did you solve the Problem?
For me there are not only read errors in system32, but also files in the AppData user directory and ProgrammData directory.
Greets Dirk

[hhpp99]

I have now opened a support ticket at Veeam: # 04072378

[Dima P.]

Dirk,

Can you please clarify if VSS is enabled and what was selected as a source for file to tape job? Thank you!

[hhpp99]

Hello Dima, VSS is selected for this file to tape job. As source is e.g. selected C:\Windows\system32.

[jessie0]

Hello jessie,
did you solve the Problem?
For me there are not only read errors in system32, but also files in the AppData user directory and ProgrammData directory.
Greets Dirk

No I didn't solve the problem.
Below is the response I received from support.

"When a File to Tape job is done file enumeration is carried out by our Veeam Installer service. This is a 32-bit application. When its enumerating files and directories to be included in the shadow copy it won't be able to find System32 folder or Program Files (x86) folder as Windows itself will not show them to 32-bit application. So the shadow copy command generated through installer service won't work correctly if it's trying to create a shadow copy of whole C drive.
Our R&D team know about this issue, but we cannot fix it as it will cause massive changes and effort for our applications. So the current workaround is not backup C drive through File to Tape job. If you want to backup specific files in C drive you can explicitly specify them in the job rather than adding whole C drive."

Cheers!

[Dima P.]

jessie0,

Thank you for sharing the update, I'll take it as a feature request and discuss with RnD folks. Meanwhile can propose a workaround to exclude System32 folder from the scope of the backup job. Cheers!

[adam900331]

Hy!

I have a File to Tape job for my file server. I backup the whole D:\ drive. When the job finish, there is a warning message which is contain lots of file read error. I checked the log file(C:\ProgramData\Veeam\Backup\File_to_Tape_Job_File) and see which folders has a problem.

D:\System Volume Information
D:\share\abcd folder which contain some type of files

Is it should be a permission problem?

Thanks.

[Natalia Lupacheva]

Hi @adam900331,

moved your post to the existing thread with the discussions on the same issue.
Please provide a support case ID for this issue, as requested when you click New Topic.
Also, please take a look at the discussions above, might give you a hint.

Thanks!

[adam900331]

Anyone?

[Dima P.]

Hello Adam,

We cannot say what is wrong with the job as debug log analysis is required. Any change you have a case ID to share? Thanks!

[adam900331]

Sorry, I have no case ID.

[wishr]

Hi Adam,

In this situation, we recommend raising a support case to get it sorted.

Thanks

[ecorec]

I use B&R community edition, version 10.0.1.4854.
I opened twice a case, but after some time it has been closed because support team is too busy.
Ok, I know it's because it's a free product, so I ask here.

During a backup to tape, I get such warnings:

Volume C: has 14 problems. Details: Problem with reading from source

But it doesn't say which are these files, and the reason why they are not copied. Access denied? I/O error etc.
Is it possible to get more details? It could help.

[Natalia Lupacheva]

Hi Valerio,

Moved your post to the existing thread to keep similar issues together.
Please take a look at the discussions above, might give you a hint.
Also, have you already checked the logs?

Thanks!

[Dima P.]

Valerio,

Can you please also share the screenshot of this error? Thank you!

[ecorec]

In History -> Jobs I find such results. With variable volumes: some times C:, some others E:.
Not always, it's two week it doesn's show up (I didn't change anything from that). And, also before, not all days.
Backup is scheduled FULL all days.

Code: Select all

14/09/2021 01:03:31 :: Queued for processing at 14/09/2021 01:03:31  
14/09/2021 01:03:31 :: Required backup infrastructure resources have been assigned  
14/09/2021 01:03:32 :: Using tape library HP Ultrium 5-SCSI  
14/09/2021 01:03:49 :: Starting new media set: tape O-Venerdi-2 is unavailable, using expired tape O-Lunedi  
14/09/2021 01:04:04 :: Drive 1 (Server: SERVER3, Library: HP Ultrium 5-SCSI, Drive ID: Tape0) locked successfully  
14/09/2021 01:04:04 :: Current tape is O-Lunedi  
14/09/2021 01:04:42 :: New tape backup session started, encryption: disabled  
14/09/2021 01:05:11 :: Processing started at 14/09/2021 01:03:26  
14/09/2021 01:05:11 :: Creating VSS snapshot for C:  
14/09/2021 01:05:11 :: Queued for processing at 14/09/2021 01:05:11  
14/09/2021 01:05:11 :: Required backup infrastructure resources have been assigned  
14/09/2021 01:05:14 :: Backup completed successfully  
14/09/2021 01:14:06 :: Volume C: has 16 problems. Details: Problem with reading from source  
14/09/2021 01:15:13 :: Removing shadow copy  
14/09/2021 01:15:15 :: Creating VSS snapshot for E:  
14/09/2021 01:15:15 :: Queued for processing at 14/09/2021 01:15:15  
14/09/2021 02:18:02 :: Removing shadow copy  
14/09/2021 02:18:04 :: Creating VSS snapshot for G:  
14/09/2021 02:18:04 :: Queued for processing at 14/09/2021 02:18:04  
14/09/2021 02:58:35 :: Removing shadow copy  
14/09/2021 02:58:36 :: Creating VSS snapshot for K:  
14/09/2021 02:58:36 :: Queued for processing at 14/09/2021 02:58:36  
14/09/2021 03:02:23 :: Removing shadow copy  
14/09/2021 03:02:24 :: 38252 folders and 462758 files have been backed up  
14/09/2021 03:02:24 :: Busy: Source 57% > Proxy 6% > Network 36% > Target 37%  
14/09/2021 03:02:24 :: Primary bottleneck: Source  
14/09/2021 03:02:24 :: Network traffic verification detected no corrupted blocks  
14/09/2021 03:02:24 :: Processing finished with warnings at 14/09/2021 03:02:24  

I looked into log directory, but I find may files: which should I look at?

C:\ProgramData\Veeam\Backup\Backup_Giornaliero

Code: Select all

26/05/2021  11:49         2.681.363 2021-05-11_Backup_Giornaliero.zip
09/06/2021  11:36         3.276.147 2021-05-26_Backup_Giornaliero.zip
23/06/2021  12:09         3.427.929 2021-06-09_Backup_Giornaliero.zip
07/07/2021  12:01         3.477.798 2021-06-23_Backup_Giornaliero.zip
23/07/2021  01:07         4.435.909 2021-07-07_Backup_Giornaliero.zip
05/08/2021  02:58         1.553.587 2021-07-22_Backup_Giornaliero.zip
19/08/2021  18:22         1.465.817 2021-08-05_Backup_Giornaliero.zip
02/09/2021  12:35         3.042.794 2021-08-19_Backup_Giornaliero.zip
16/09/2021  03:17         1.043.697 2021-09-02_Backup_Giornaliero.zip
30/09/2021  01:27           847.620 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.10.log.gz
30/09/2021  01:32           942.684 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.9.log.gz
30/09/2021  01:35           707.325 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.8.log.gz
30/09/2021  01:39           892.539 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.7.log.gz
30/09/2021  01:43         1.516.778 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.10.log.gz
30/09/2021  01:45           901.705 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.6.log.gz
30/09/2021  01:48         1.839.460 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.9.log.gz
30/09/2021  01:52         1.530.899 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.8.log.gz
30/09/2021  01:55         1.155.530 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.5.log.gz
30/09/2021  01:58         2.440.971 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.7.log.gz
30/09/2021  02:00           868.106 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.4.log.gz
30/09/2021  02:01         2.154.316 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.6.log.gz
30/09/2021  02:03         1.351.108 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.5.log.gz
30/09/2021  02:05           760.491 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.3.log.gz
30/09/2021  02:06         1.678.701 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.4.log.gz
30/09/2021  02:10           831.216 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.2.log.gz
30/09/2021  02:10         1.530.968 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.3.log.gz
30/09/2021  02:13         1.664.609 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.2.log.gz
30/09/2021  02:14           864.297 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.1.log.gz
30/09/2021  02:16         1.999.753 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.1.log.gz
30/09/2021  02:18         1.208.082 Agent.Backup_Giornaliero.TapeFilesBackup.TapeHost.log.gz
30/09/2021  02:19           895.755 Agent.Backup_Giornaliero.TapeFilesBackup.FileHost.1.log.gz
30/09/2021  03:26         1.157.258 2021-09-16_Backup_Giornaliero.zip
30/09/2021  03:26    <DIR>          ..
30/09/2021  03:26    <DIR>          .
30/09/2021  03:26                98 2021-09-30_Backup_Giornaliero.zip
30/09/2021  03:27               466 Job.Backup_Giornaliero.TapeFilesBackup.log
              34 File     54.145.776 byte
               2 Directory  24.846.852.096 byte disponibili