SCDPM 2019 The storage involving the current operation could not be read from or written to (ID 40003)

MIS-ItDoesntAddUp 1 Reputation point
2021-09-28T11:02:31.02+00:00

Hi all,

We have SC DPM 2019, on Server 2019, RU3, and through all the RU's we have had a repeated issue, which was an issue in DPM 2016 - but was resolved - but using DPM 2016 won't work for us, as we have other Server 2019 systems that we need to protect and DPM 2016 does not protect Server 2019.

The specific error we now get is:
The storage involving the current operation could not be read from or written to. (ID 40003)

But we also used to get an error that mentioned about not being able to mount or unmount the volume that was being processed during the protection job.

This has been affecting a small amount of SQL volumes repeatedly, then a larger amount, and now it's affected all SQL instances and RCT backups of VM's too. Reboot the server with the DPM on (i.e. not the host servers, the VM's or anything else that hosts the volumes or storage devices) and then the failed jobs can be re-run and most of the time the jobs will then succeed, successfully backing up all types of protection points. But we don't want to have to always be rebooting our DPM server (nothing else runs on the server, FYI) just to resolve this issue. I must add that this is an inconsistant error, it has been happening roughly once a week, sometimes multiple times a week, but sometimes, not for a few weeks.

We have tried changing the volumes, where the data is backed up from, and the DPM volume, where the data is backed up to, but no change, error still occurs.

We don't want to live like this, it's an added pressure that we don't have time for, we just want DPM to work, please help.

Windows Server 2019
Windows Server 2019
A Microsoft server operating system that supports enterprise-level management updated to data storage.
3,457 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. Limitless Technology 39,351 Reputation points
    2021-10-01T10:38:41.43+00:00

    Hello,

    in DPM This issue occurs if the input/output (I/O) latency is greater than the standard SMB time-out (60 seconds).

    On the protected server, open Registry Editor, and then add the SessTimeout registry entry as shown under the following subkey:

    HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters SessTimeout REG_DWORD 1200

    Note : The 1,200 seconds (20 minutes) time-out is a recommended value. Adjust the value as appropriate. You can review the Resilient File System (ReFS) event logs on the DPM or Azure Backup Server server to find any suspected I/O latency.


    --If the reply is helpful, please Upvote and Accept as answer--

    0 comments No comments