Question

Dell RD1000 Failed to open storage for read/write access

  • 27 October 2023
  • 9 comments
  • 453 views

Userlevel 1

Hi all.

Trying to run a Backup Copy on a Dell T110-II with WinServer 2012 and Veeam Bkp&Rst v. 12 to a RD1000 cartridge drive (Sata).

The drive works perfectly copying small and huge files from windows explorer, but doesn’t work at all with CopyBackup.

After starting the job it creates a 4-5kb file on the corrected created folder and then hungs with the following message:

 

27/10/2023 02.14.11 :: Error: The request could not be performed because of an I/O device error.
Asynchronous request operation has failed. [requestsize = 524288] [offset = 4096]
The request could not be performed because of an I/O device error.
Asynchronous request operation has failed. [requestsize = 524288] [offset = 528384]
Failed to open storage for read/write access. Storage: [H:\Backups\Backup Copy Job 1\Backup Job 1\W22-APPS.vm-1005D2023-10-27T021229_94BF.vbk].
 

Any idea? (RD1000 drivers and tools are installed)

Thank you!

 


9 comments

Userlevel 7
Badge +21

Based on the error is there any bad disks or corruption?  I would run a scan if you can.

Userlevel 1

Unfortunately no… same error with 3 different cartridges and, as I said, if I fill out the drive with stuff from Windows explorer it has no issues at all!

I also tried to manually put 100Gb on disk (all ok) and start the CopyBackup (in order to skip the first sectors), but Veeam hang after some kbs as with empty disk...

Userlevel 7
Badge +21

Might suggest contacting support at this point so they can go through your logs to determine the issue.

Userlevel 1

Anyway, I executed the scan:

 

Chkdsk was executed in read/write mode.  

Checking file system on H:
Volume label is RD1000-2TB-.

CHKDSK is verifying files (stage 1 of 3)...
  256 file records processed.                                          File verification completed.
  0 large file records processed.                                      0 bad file records processed.                                      
CHKDSK is verifying indexes (stage 2 of 3)...
  280 index entries processed.                                         Index verification completed.

 

CHKDSK is verifying security descriptors (stage 3 of 3)...
Security descriptor verification completed.
  12 data files processed.                                            
Windows has scanned the file system and found no problems.
No further action is required.

1953509375 KB total disk space.
     21608 KB in 13 files.
        12 KB in 14 indexes.
    125823 KB in use by the system.
     65536 KB occupied by the log file.
1953361932 KB available on disk.

 

Kind rgds

 

Userlevel 1

Unfortunately it is the Community edition: I opened a case on Aug 29th, but I only received an email saying that on free editions the answer has not SLA but it’s only managed on best effort…

 

Userlevel 7
Badge +21

Unfortunately it is the Community edition: I opened a case on Aug 29th, but I only received an email saying that on free editions the answer has not SLA but it’s only managed on best effort…

 

Ah ok.  Well, the only other place I can think to check is the logs - C:\ProgramData\Veeam\Backup

Hopefully the job log file will point you to how to fix this.

Userlevel 1

This is what I found: can give us an idea on the matter? It refers to formatting some metadata, does it need some particular access right?

 

[27.10.2023 01:15:55.193] < 34792>          | ERR |Attempt to format storage [H:\Backups\BkpCopy - RD1000\Backup Job 2 - LocalREFS\W22-APPS.vm-1005D2023-10-27T011430_74A4.vbk] has failed.
[27.10.2023 01:15:55.193] < 34792>          | ERR |The request could not be performed because of an I/O device error.
[27.10.2023 01:15:55.193] < 34792>          | >>  |Asynchronous request operation has failed. [requestsize = 524288] [offset = 4096]
[27.10.2023 01:15:55.193] < 34792>          | >>  |--tr:Error code: 0x0000045d
[27.10.2023 01:15:55.193] < 34792>          | >>  |--tr:Unable to format storage metadata.
[27.10.2023 01:15:55.193] < 34792>          | >>  |--tr:Failed to format metadata partition.
[27.10.2023 01:15:55.193] < 34792> stg      |     Deleting file [H:\Backups\BkpCopy - RD1000\Backup Job 2 - LocalREFS\W22-APPS.vm-1005D2023-10-27T011430_74A4.vbk].
[27.10.2023 01:15:55.287] < 34792>          | ERR |Failed to cleanup storage [H:\Backups\BkpCopy - RD1000\Backup Job 2 - LocalREFS\W22-APPS.vm-1005D2023-10-27T011430_74A4.vbk]. Attempt to format storage has failed.
[27.10.2023 01:15:55.287] < 34792>          | ERR |boost::filesystem::remove: The process cannot access the file because it is being used by another process: "H:\Backups\BkpCopy - RD1000\Backup Job 2 - LocalREFS\W22-APPS.vm-1005D2023-10-27T011430_74A4.vbk"
[27.10.2023 01:15:55.287] < 34792>          | >>  |File 'H:\Backups\BkpCopy - RD1000\Backup Job 2 - LocalREFS\W22-APPS.vm-1005D2023-10-27T011430_74A4.vbk' locked by 1 processes:
[27.10.2023 01:15:55.287] < 34792>          | >>  |  [30976:Critical] VeeamAgent: Status = 00000001, IsRestartable = False, TerminalSession = 0 (C:\Program Files (x86)\Veeam\Backup Transport\x64\VeeamAgent.exe)
[27.10.2023 01:15:55.287] < 34792> stg      |   Opening storage [H:\Backups\BkpCopy - RD1000\Backup Job 2 - LocalREFS\W22-APPS.vm-1005D2023-10-27T011430_74A4.vbk] for read/write access. Failed.
[27.10.2023 01:15:55.287] < 34792> stg      | Upgrading/fixing storage [H:\Backups\BkpCopy - RD1000\Backup Job 2 - LocalREFS\W22-APPS.vm-1005D2023-10-27T011430_74A4.vbk]. Standard block size: [1048576]. Block alignment logarithm: [3]. Failed.
[27.10.2023 01:15:55.287] < 34792> cli      | Removing stdin/stdout redirector: '766556522848'.
[27.10.2023 01:15:55.287] < 34792> cli      | CVaCtx: AbortQueueSafe

 

Userlevel 7
Badge +21

If this is a repo in Veeam I would assume the account used to connect it has the rights. Also wondering if maybe AV is scanning it and locking files?

Check exclusions - https://www.veeam.com/kb1999

 

Userlevel 1

No AV/EDR installed at all. OS just reinstalled from scratch… same error!

Drive has Everyone/fullcontrol rights.

I also tried to share the drive with SMB and define a new SMB target: \\localhost\H, same result!

Veeam starts writing each file correctly: 5Kb for each vbm are on the target disk. It cannot move forward for some reason…...

Comment