SOLVED: second full job will always fail. different error messages, e.g. invalid access to a memory space

Karl, what exactly are you backing up here and which backup scheme are you using? Just wondering what is needed to attempt to recreate the same issue?

My own backups with ATI 2020 have all been running fine so far with no similar errors hence my questions.

Bruno C: Karl, pinging the drive every second may not be a good test to see if the drive is getting disconnected. It may be that the pinging script itself would be keeping the drive connected whereas a longer period without access may cause disconnect.

Bruno, I see your point yes this could lead to a different state, I just wanted,  at least try, to a exclude a technical issue with the drive. 

edit: Bruno due to the fact that the second full data job (as outlined below) will fail even with the running script, there is no disconnection happening. Sorry I mixed things up.

Steve, the setup is as follows:

3 PCs are backing up to this target. Call the devices Karl, Nadine, NAS

Karl: Full Backup OS (SSD), keep 2 versions, scheduled every week > target \\nas\backups, OS 1903, UEFI, Acronis 2020 beta2

Nadine: Full Backup OS (SSD), keep 2 versions, scheduled every week > target \\nas\backups, OS 1903, UEFI, Acronis 2020 beta2

NAS: Full Backup OS (SSD), keep 2 versions, scheduled every week > target B:\my backups (USB 3.0 HDD), OS 1903, UEFI, Acronis 2020 final

NAS: Full Backup DATA (HDD), keep 2 versions, scheduled every week > target B:\my backups (USB 3.0 HDD), OS 1903, UEFI, Acronis 2020 final

I cannot reproduce the issue when Karl and Nadine backup via LAN, and also everything is fine when NAS does the

full backup OS. Additionally the DATA backup is fine with the first run, the second backup or subsequent will cause the issue.

This happened first time with ATIH 2020 beta2

you'll see the current status with the backup files in 509350-171296.png. 

they do not follow a weekly schedule atm, due to the testing everything is fine except the data job runs second time

file: NAS_DATA_WDC WD20EFRX-68AX9N0 80.00A80-0001.tibx

TIBX will not be deleted despite the error and remains incomplete as you may guess through the size.

edited the post above as it contained misinformation.

Karl,

I do not have an explanation for your issue here.  I do have a similar issue that might be related however.  In my case I have an internal drive (WD 2TB) used for app and user data.  I have hard linked my Win 10 user folders to the drive.  Ever since my upgrade to Win 10 1903 version I have a situation where Windows will complain that there is no access to the drive.  An example would be if I download a file and choose to save it in the user download folder on that drive and also choose to create a new folder for the file, I get an error message that the drive cannot be located.

Of course this has nothing to do with TI but sounds familiar to what you report.  Maybe your problem is a Windows issue like mine is?

Interesting that this is happening with backups to a NAS. Like you I have 3 PCs doing backups to my NAS. I have seen some instances where the backup does not complete. Last night one PC was doing a backup when I went to close it down, clicked on option for PC to shut down when backup completed. Just realised that the reason why the PC did not shut down was that the backup failed.

Not sure if this is the same problem: log file information not very helpful (as expected):

26/08/2019 7:12:17:706 AM    +10:00 8892 I00000000: -----
26/08/2019 7:12:17:706 AM    +10:00 8892 I00000000: ATI Demon started. Version: 24.3.1.20600.
26/08/2019 7:12:17:742 AM    +10:00 8892 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
26/08/2019 7:12:17:743 AM    +10:00 8892 I00640002: Operation 2020Beta NAS started manually.
26/08/2019 7:12:17:908 AM    +10:00 8892 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
26/08/2019 7:12:17:909 AM    +10:00 8892 I013C0000: Operation: Backup
26/08/2019 7:12:17:910 AM    +10:00 8892 I0064000B: Priority changed to High.
26/08/2019 7:55:20:708 AM    +10:00 8892 E00040019: Error 0x40019: Error occurred while backing up.
| trace level: error
| line: 0xaa33a143c434a5f5
| file: c:\bs_hudson\workspace\1088\home\backup_worker\impl\backup_worker.cpp:167
| function: `anonymous-namespace'::ReturnCodeToError
| line: 0xaa33a143c434a5f5; c:\bs_hudson\workspace\1088\home\backup_worker\impl\backup_worker.cpp:167; `anonymous-namespace'::ReturnCodeToError
| Archive3Code: 0x138d
| Name:
| $module: archive3_adapter_vs_20600
26/08/2019 7:55:29:930 AM    +10:00 8892 E013C0005: Error 0x13c0005: Operation has completed with errors.
| trace level: error
| line: 0x9f2c53c72e8bced6
| file: c:\bs_hudson\workspace\1088\products\imager\demon\main.cpp:736
| function: main
| line: 0x9f2c53c72e8bced6; c:\bs_hudson\workspace\1088\products\imager\demon\main.cpp:736; main
| $module: ti_demon_vs_20600
 

Ian 

Karl, a little clarification please.

You say the Karl and Nadine backups are going to the NAS and the NAS backups to the USB drive.Where is the folder showing all the .tibx files? Is that on the USB drive? If so, why are the Karl and Nadine backups there?

Is the NAS that you are backing up to the USB the same NAS as the destination of the Karl and Nadine backups?

Also you said ...

file: NAS_DATA_WDC WD20EFRX-68AX9N0 80.00A80-0001.tibx

TIBX will not be deleted despite the error and remains incomplete as you may guess through the size.

I think you are saying that you expect the -0001.tibx file should be as big as the first .tibx file and since the backup failed the -0001.tibx should be deleted because it is not complete. Is that correct?

Are there any exclusions in the backups? What are the error handling parameters?

Finally, if you feel there may be any validity to this concern, can you try renaming the NAS data backup so as not to include a dot in the filename... just in case something does not get handled right in that situation.

I am having the exact same issues with my recent upgrade.  I first deleted all my backups in the old version, which was ATI 2017.  I upgraded to 2020 and then tried to recreate my backup to one of my NAS devices.  The backup failed stating the device was inaccessible.  Then I switched to a different NAS, and got the same error.  So then I eliminated the network and placed a USB3 drive (Western Digital 2TB Ultra), and the product still failed.  It always seems to failed between 700 and 800GB, and is trying to backup about 1.7TB of data.  The previous version had absolutely zero issues with either USB3 drives and also to either NAS.  In all cases, it seems to state the writing drive is inaccessible.  Here is the message that gets sent to my email in all cases (Just with different times)

2019-08-25T11:09:55:403-07:00 42104 I00000000: -----
2019-08-25T11:09:55:403-07:00 42104 I00000000: ATI Demon started. Version: 24.3.1.20600.
2019-08-25T11:09:55:490-07:00 42104 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false; 
2019-08-25T11:09:55:490-07:00 42104 I00640002: Operation PC on WD Drive started manually.
2019-08-25T11:09:55:690-07:00 42104 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false; 
2019-08-25T11:09:55:692-07:00 42104 I013C0000: Operation: Backup
2019-08-25T11:09:55:692-07:00 42104 I0064000B: Priority changed to Low.
2019-08-25T13:16:10:136-07:00 42104 E000B042F: Error 0xb042f: Destination is unavailable.
| trace level: error
| line: 0x5d5406763c32a94
| file: c:\bs_hudson\workspace\1088\products\imager\archive\impl\operations\utils.cpp:582
| function: TrueImage::Archive::MakeDestinationUnavailableError
| line: 0x5d5406763c32a94, c:\bs_hudson\workspace\1088\products\imager\archive\impl\operations\utils.cpp:582, TrueImage::Archive::MakeDestinationUnavailableError
| Path: G:\
| StrId: \local\hd_sign(6A4119AE)\part_sn(74B76DCCF474B7AA)start(2048)
| $module: ti_demon_vs_20600
|
| error 0x2160015: A backup error.
| line: 0xa340ffd3416335cf
| file: d:\bs_hudson\workspace\mod-disk-backup\470\product\core\da_api\backup.cpp:353
| function: da_backup::Commit
| line: 0xa340ffd3416335cf, d:\bs_hudson\workspace\mod-disk-backup\470\product\core\da_api\backup.cpp:353, da_backup::Commit
| $module: disk_backup_vs_470
|
| error 0x29b138d: Input/output error
| line: 0x30ba355f9fd4ffbd
| file: d:\bs_hudson\workspace\mod-disk-backup\470\product\core\resizer\archive3\utils.cpp:364
| function: `anonymous-namespace'::ArchiveWriterImpl::CoroutineFunc
| line: 0x30ba355f9fd4ffbd, d:\bs_hudson\workspace\mod-disk-backup\470\product\core\resizer\archive3\utils.cpp:364, `anonymous-namespace'::ArchiveWriterImpl::CoroutineFunc
| function: archive_stream_write_shbuf
| path: \\?\G:\/PC on WD Drive.tibx
| $module: disk_backup_vs_470
|
| error 0xfff0: Invalid access to memory location.
| 
| line: 0x30ba355f9fd4ffbd
| file: d:\bs_hudson\workspace\mod-disk-backup\470\product\core\resizer\archive3\utils.cpp:364
| function: `anonymous-namespace'::ArchiveWriterImpl::CoroutineFunc
| line: 0x30ba355f9fd4ffbd, d:\bs_hudson\workspace\mod-disk-backup\470\product\core\resizer\archive3\utils.cpp:364, `anonymous-namespace'::ArchiveWriterImpl::CoroutineFunc
| function: pcs_co_file_writev
| path: \\?\G:\PC on WD Drive.tibx
| code: 0x800703e6
| $module: disk_backup_vs_470
2019-08-25T13:16:10:298-07:00 42104 E013C0005: Error 0x13c0005: Operation has completed with errors.
| trace level: error
| line: 0x9f2c53c72e8bced6
| file: c:\bs_hudson\workspace\1088\products\imager\demon\main.cpp:736
| function: main
| line: 0x9f2c53c72e8bced6, c:\bs_hudson\workspace\1088\products\imager\demon\main.cpp:736, main
| $module: ti_demon_vs_20600

The reason I deleted all my old backups, was that I wanted the new TIBx format, which was supposed to be faster.

Did a manual backup before going out this morning. On return I found it failed again (4 times). The log file (as far as I can see) said nothing about not being able to connect to the NAS but the activity tab shows this in 2 out of 4 instances.

I did not have this issue with beta 2, so it may be something introduced in the final build. At least this time there was a notification on the backup tab suggesting there was an issue with getting access to the relevant directory on the NAS. I decided to check the setting and was immediately prompted for NAS user name and password, entered them and clicked test, all OK. The clicked on destination and inexplicable windows login popped up cancelled it and continued. Went immediately to the correct directory.

No idea why windows account and password were requested - although I recall that others have experienced this happening (not sure if with beta or ATI 2019).

Update: Just notice that on the same PC a backup to the NAS configured by ATI 2019 ran without incident between the run last night and the run this morning of the one configured with ATI 2020 (originally created using 2020 beta). Suggests the problem is with ATI rather than the NAS.

Further Update: backup has been going for a while now and it gives the nonsense time of 1 day one hour remaining - it also claims merely to have backed up 102 mb.

Ian

I am getting a little peeved by this.

Folks, a couple of comments here.

The ti_demon logs for new .tibx backup tasks only contains an overview of what is happening, not all the full details - the latter is held in the backup_worker logs for .tibx backup tasks!

Dean, your issue looks to be the same as forum topic: Large backups fail at around 900gb - created by user Patrick where the core issue seems to be around a memory issue, which in turn begs a question as to whether ATI 2020 is using memory more intensively for new .tibx tasks?

error 0xfff0: Invalid access to memory location.  (from Dean's update above).

Karl, your issue scenario looks to be complex to say the least..  I doubt that I would be able to get near to trying to recreate such a scenario.  I have never used my NAS as the source for any tasks and currently only have one laptop running ATI 2020 #20600 public release.  My other computers are running a mix of ATI 2019 and 2018.

Dean - Since your backups seem to fail at the same point I would suggest running check disk on the drive to see if any errors can be found and corrected.

Ian, Karl, I had issue with one of my 3 NAS devices that sound the same as you report.  I eventually found the issue to be Windows permissions as they relate to the underlying Linux OS partition structure.

Basically I had to break the exiting SMB share which of course destroyed all data (make sure you move it all to another location).  At that point by establishing a new SMB share directly under the root and then applying Windows permission to the share I was able to fix the problem.

Prior to this change my SMB shares where nested under a user account as viewed from a directory view.  Interestingly, the change I made still requires the user account credentials for authentication.  I believe this is because the user is the Owner of the SMB share not root or some other user.

Good luck to you if this proves to be the case for you.  I spent 2 full days working around the problem.

Hi lads, I read your comments but I miss to see how this could be a file system or permission issue if the first run of DATA Full backup runs ok, and only the second full fails. But only for this particular job. I have already

- recreated all jobs

- deleted all archives

- checked all drives (source and target on NAS) 

- formatted the target on NAS

IanL-S wrote:

No idea why windows account and password were requested - although I recall that others have experienced this happening (not sure if with beta or ATI 2019).

As near as I can tell, if you use a local Windows account that has a password, ATI prompts for that password when you add or change a backup task. I suspect there's more to it than that, but this is what I'v noticed.

You say the Karl and Nadine backups are going to the NAS and the NAS backups to the USB drive.Where is the folder showing all the .tibx files? Is that on the USB drive? If so, why are the Karl and Nadine backups there?

Is the NAS that you are backing up to the USB the same NAS as the destination of the Karl and Nadine backups?

NAS OS and NAS DATA aswell as Karl OS and Nadine OS will backup to the same target, external USB3 disk, as shown in the screenshot. The difference is that only NAS OS and NAS DATA job run locally while Karl and Nadine jobs will backup via NAS Win10 SMB share to the external disk (with no issues)

Also you said ...

file: NAS_DATA_WDC WD20EFRX-68AX9N0 80.00A80-0001.tibx

TIBX will not be deleted despite the error and remains incomplete as you may guess through the size.

I think you are saying that you expect the -0001.tibx file should be as big as the first .tibx file and since the backup failed the -0001.tibx should be deleted because it is not complete. Is that correct?

Are there any exclusions in the backups? What are the error handling parameters?

Yes I expected this.

Exclusions: all  job have default exclusion settings
Error handling: default settings, retry on error 5 times within 30 seconds

Finally, if you feel there may be any validity to this concern, can you try renaming the NAS data backup so as not to include a dot in the filename... just in case something does not get handled right in that situation.

interesting thought. This is actually the default name. ATIH will pick the drive name I just added a prefix. Can anyone repro this naming a job containing a "." ? would understand if there is a code issue that this would prevent a second backup but not interrupt it in the middle of the process.

Of course this has nothing to do with TI but sounds familiar to what you report.  Maybe your problem is a Windows issue like mine is?

Bob, no I doubt it is an Windows issue, it started with ATIH 2020 beta 2. The only way to prove this would be to uninstall 2020 and reinstall the 2019.

I hope that ATIH will contact me before going down this road.

Enchantech wrote:

Dean - Since your backups seem to fail at the same point I would suggest running check disk on the drive to see if any errors can be found and corrected.

 

I have run a check disk and all comes back with zero errors across the drives that I'm backing up.  There are no errors on the NTFS volumes at all that can be found.  The first drive is a SSD raid zero stripe for the system drive at 256GB, and the 2nd drive is a WD Black 4TB data drive about 45% full.  Both are error free. 

Good news, bad news.

I ran a test where I created 2 disk backup tasks to a USB drive. Full backups only, set to run every hour. I was testing my theory about a dot in the file name being problematic.

After dinner and a movie I came back to the machine and here is what I first saw on the activity screens... the backup without the dot is just about done with its fifth full backup. The one with the dot did two successful backups but has failed four times since.

Looking at the ti_demon logs, I can see that the backup task that succeeds actually is failing but on the 5th retry is succeeding. The other task is failing on all retries. All the failures seems to be in function CheckVolumeDeviceIdMatch.

Tomorrow I plan to capture a system report. Karl, if you've got a report number I can reference that may help.

I also plan to try to narrow down the test to find a minimal, but repeatable sequence.

Bruno you are awesome 🐱‍👤. I've already opened a ticket yesterday. Please attach your findings to case #04128179

Same thing here... backup failed due to destination not available.

OK, Karl, I don't know if today's results help or not.

First, take a look at my thread on the BSOD. The drive that caused that problem was the one I was using yesterday when I ran the backups and experienced the errors. It was so odd that the backup that succeeded only did so on the fifth and final retry. The one that failed missed on all retries.

So once I got the drive repaired, and with a new ATI 2020 install today, I recreated the same two tasks that I ran yesterday. I've been running them and the results are completely error free.

At this point, I might suggest running a check of the USB drive you are using for backup. As I said in the other thread, I used the Check File System option in MiniTool Partition Wizard Free, which I think goes through chkdsk. The problem I had was in the free space allocation, as I recall, but I didn't write it down (silly me).

If I learn anything new, I'll keep you posted.

(BTW, I did send the feedback to Acronis on your case #)

Hello Karl, 

I've sent you an email regarding the issue with invalid access to memory, please check your mailbox :) 

Hi Ekaterina, as confirmed within ticket 04128179 the pre-release update fixes the issue.

Thanks for providing a solution so I am able to backup my main data storage location again.

There is just one thing, this version lacks of updating the survival kit. It looks a bit different from when it terminates as in the beta 

https://forum.acronis.com/forum/backuprestore/issue-blocker-upgrading-survival-kit-terminates-unspecified-error

yet I cannot upgeade it (again). last time I had to completely format the drive as a workaround. hope we can get this fixed before release in a seperate ticket / discussion.

Hi All. :)

Sorry to jump on your thread. I have a similar problem with ATIH2020, or at least I think it's similar anyway, it's all just so confusing for me. I updated from ATIH2019 to 2020 and since then my backups to my local networked NAS (MyCloud PR2100) have been faiIing. Basically the error is that ATI cannot access the backup location. I'm not expecting anyone to help me out here and now, I'll create a new thread after I've done more research and have been in touch with customer support. I just wanted to post the error messages which I obtained from the Web Dashboard. Maybe/somehow/hopefully the info may be of use to you here.

I have one backup plan which makes a full backup of my Windows 10 (1903 x64) PC's 3 disks (1xSSD 2x3.5" SATA) to my Western Digital My Cloud PR2100. I rarely had any issues with ATI2019 but since upgrading to ATI2020 I'm getting the same error every time. I've Uninstalled, Reinstalled, Clean Installed, used the Acronis Cleanup Tool but I just won't complete the backup.

Sorry, I'm going on a bit too much, here's the error(s) from the last time I ran the backup:

Error
Date and time
Sep 07, 2019, 11:14:01 PM
Module
11
Message

Additional info:
------------------------
Error code: 1067
Module: 11
LineInfo: 0x7761D36A3D1400D5
Fields: {"$module":"ti_demon_vs_20770"}
Message: The backup failed. Ensure that folder 'nas://MCPR2100/acronis/#MyComputersName#/All Disks/' is accessible.
------------------------
Error code: 1067
Module: 11
LineInfo: 0x4D3F22948E29F35D
Fields: {"Path":"nas://MCPR2100/acronis/#MyComputersName#/All Disks/","$module":"ti_demon_vs_20770"}
Message: The network share is inaccessible.
------------------------
Error code: 21
Module: 534
LineInfo: 0xA340FFD3416335CF
Fields: {"$module":"disk_backup_vs_480"}
Message: A backup error.
------------------------
Error code: 5005
Module: 667
LineInfo: 0x30BA355F9FD4FFBD
Fields: {"path":"\\\\?\\UNC\\MCPR2100\\acronis\\#MyComputersName#\\All Disks\\/#MyComputersName# - All Disks.tibx","function":"archive_stream_write_shbuf","$module":"disk_backup_vs_480"}
Message: Input/output error
------------------------
Error code: 65520
Module: 0
LineInfo: 0x30BA355F9FD4FFBD
Fields: {"path":"\\\\?\\UNC\\MCPR2100\\acronis\\#MyComputersName#\\All Disks\\#MyComputersName# - All

The network share connection (ethernet) is always active before, during and after the backup fails. I even added Acronis as a user on the NAS without a password, the backup location is in the Acronis share and Acronis is the only user connected to the NAS. I do not have any mapped drives.

Anyway... hope some of that helps.

Cheers.

Andrew. :)

Your issue is likely related to changes in Windows 10 and TI 2020 networking.  It has more to do with Windows changes than TI.

Below is a link that may help you solve the issue you face.

LINK

Enchantech wrote:

Your issue is likely related to changes in Windows 10 and TI 2020 networking.  It has more to do with Windows changes than TI.

Below is a link that may help you solve the issue you face.

LINK

The article linked to contains the very strange comment

Connect, Access and Map a My Cloud password protected Private Share before accessing the Public share

Once a user on Windows has accessed a share on a device with one set of credentials that user cannot access any share on that same device with another set of credentials (including the null credentials for a public share) until that first connection has terminated. 

Maybe other platforms do not have this restriction so those instructions might make sense, but not for Windows ... and the instructions are supposed to be for Windows 10.  I have no idea what point the article is trying to make except that SMB1 (and SMB2 guest access) has been disabled in Win 10.

The links the article provides do give correct information for accessing or mapping the WD devices assuming everybody uses the default device names set by WD.

Patrick,

Depending on the SAMBA version used in the MyCloud it is possible to set parameters or auxiliary settings that enable either/or protected shares/guest shares and to specify which order they are accessed.  SAMBA version 3.6 is required at a minimum to enable use of SMB 2.0.  I believe that SAMBA version 5 up needs to be in use to support SMB 3.0 and higher.

Users are faced with a conundrum at present due to the changes that Windows 10 has brought to networking.  The deprecation of SMB 1.0, HomeGroup, and network discovery method changes have rendered some devices obsolete and simply will not work unless the user decides to re-enable the SMB 1.0 protocols to bet the working. 

I have no idea what SAMBA version a MyCloud uses but I am betting on it being other/less than version 3.6.

Enchantech wrote:

I have no idea what SAMBA version a MyCloud uses but I am betting on it being other/less than version 3.6.

I've got a public share on a MyCloud and Windows says the connection is SMB 3.1.1. I'm surprised but pleased.

Patrick O'Keefe wrote:

Enchantech wrote:

I have no idea what SAMBA version a MyCloud uses but I am betting on it being other/less than version 3.6.

I've got a public share on a MyCloud and Windows says the connection is SMB 3.1.1. I'm surprised but pleased.

That is good news.  I am a bit surprised as well.  Is this device relatively new or have you upgraded it lately?

SMB 3 came out in 2011 and then subsequent releases of that protocol, like 3.02 (came out in 2012) and 3.1.1 (came out in 2015).  95% of all samba stuff out there now fully supports modern SMB protocols.  If the manufacturer patches for vulnerabilities, which they do, then you'll always get a version that supports SMB3, at least in any purchase since mid 2016.

Enchantech wrote:

That is good news.  I am a bit surprised as well.  Is this device relatively new or have you upgraded it lately?

I don't remember when I got the device but my firmware was released May 2018, and I see there have been several more releases since then.  I am in remiss!  I guess there is still active development going on.

Dean Drolet wrote:

SMB 3 came out in 2011 and then subsequent releases of that protocol, like 3.02 (came out in 2012) and 3.1.1 (came out in 2015).  95% of all samba stuff out there now fully supports modern SMB protocols.  If the manufacturer patches for vulnerabilities, which they do, then you'll always get a version that supports SMB3, at least in any purchase since mid 2016.

There are still a lot of devices out there with back-level SMB support - especially devices that are out of support. For instance, my WD MyBookLive NAS drives are still perfectly usable (if a bit slow). They support SMB 2 but not SMB 3.  Some user in another thread was using a configuration that supported only SMB 1.

Patrick O'Keefe wrote:

I've got a public share on a MyCloud and Windows says the connection is SMB 3.1.1. I'm surprised but pleased.

Too bad I just bricked it trying to upgrade the firmware. :(

Patrick,

If your device quit working while attempting to upgrade the firmware what does WD say about that?   Are you the user solely responsible?

I have had issue with device firmware upgrade seemingly failing but have gotten round the issue by disconnecting power to the device and letting it sit for a few hours so that residual electricity dissipates them plug them back in and give them a start.  More often than not they will startup and the firmware upgrade will be intact.

Enchantech wrote:

Patrick,

If your device quit working while attempting to upgrade the firmware what does WD say about that?   Are you the user solely responsible?

I have had issue with device firmware upgrade seemingly failing but have gotten round the issue by disconnecting power to the device and letting it sit for a few hours so that residual electricity dissipates them plug them back in and give them a start.  More often than not they will startup and the firmware upgrade will be intact.

I read - after the fact, of course - that a number of users had problems with recent WD firmware upgrades. I should have opened a problem case with WD but I was in a panic and not thinking well. I tried powering off for several minutes but not several hours.  Poor decision, I guess.

I decided to do a "reset to factory settings" procedure.  This, unfortunately, wipes data from the drive and, according to reports on the web, can take several days to complete depending on drive size.  (Mine is 3TB.)  I started the process about 12 hours ago so I may not know until the weekend whether the device is alive or dead.

I've restored the data to an older, slower WD NAS (It uses SMB 2.0.2.) so I'm not dead in the water.

Patrick,

Sorry to hear that you had to reset your device.  Thankfully you have backups!  I bet the device will reset just fine and being just 3TB I would think it will be done in about 6 to 8 hours.

As info on the SMB Protocol I thought I would post an excerpt from a brief on the differences in versions.  I believe others following this thread will find it useful.

Here’s a very short summary of what changed with each version of SMB:

• From SMB 1.0 to SMB 2.0 - The first major redesign of SMB
  • Increased file sharing scalability
  • Improved performance
    • Request compounding
    • Asynchronous operations
    • Larger reads/writes
  • More secure and robust
    • Small command set
    • Signing now uses HMAC SHA-256 instead of MD5
    • SMB2 durability
• From SMB 2.0 to SMB 2.1
  • File leasing improvements
  • Large MTU support
  • BranchCache
• From SMB 2.1 to SMB 3.0
  • Availability
    • SMB Transparent Failover
    • SMB Witness
    • SMB Multichannel
  • Performance
    • SMB Scale-Out
    • SMB Direct (SMB 3.0 over RDMA)
    • SMB Multichannel
    • Directory Leasing
    • BranchCache V2
  • Backup
    • VSS for Remote File Shares
  • Security
    • SMB Encryption using AES-CCM (Optional)
    • Signing now uses AES-CMAC
  • Management
    • SMB PowerShell
    • Improved Performance Counters
    • Improved Eventing
• From SMB 3.0 to SMB 3.02
  • Automatic rebalancing of Scale-Out File Server clients
  • Improved performance of SMB Direct (SMB over RDMA)
  • Support for multiple SMB instances on a Scale-Out File Server

You can get additional details on the SMB 2.0 improvements listed above at
http://blogs.technet.com/b/josebda/archive/2008/12/09/smb2-a-complete-redesign-of-the-main-remote-file-protocol-for-windows.aspx

You can get additional details on the SMB 3.0 improvements listed above at
http://blogs.technet.com/b/josebda/archive/2012/05/03/updated-links-on-windows-server-2012-file-server-and-smb-3-0.aspx

You can get additional details on the SMB 3.02 improvements in Windows Server 2012 R2 at
http://technet.microsoft.com/en-us/library/hh831474.aspx

Enchantech wrote:

I bet the device will reset just fine and being just 3TB I would think it will be done in about 6 to 8 hours.

It's getting close to 22 hours now with no change. I think it's time for the powering off for a few hours as you suggested earlier.  I've opened a ticket with WD.  They promise to get back in 2 days. 

I'm glad I had the extra NAS.  I was planning to get rid of it.   And I'm very glad I have backups.  Yeah, ATI!

22 hours, that seems long to me but then it depends on a whole bunch of factors in what all occurs with the reset.

Hope it all works out for you!

I have similar experience with full (all Partitions) backup  failing with the "Access" issue.

However, I discovered today that if I split my backup down a maximum of 2 Partitions per backup then they work OK without the Access issue raising its ugly head. This is still a hassle because I have 3 Backups for every full machine backup. Its all a bit odd because I have second PC which is basically setup as the first machine (in terms of SSDs and partitions) and I have no problem doing full backups on that PC.

I never had any such hassles with Acronis 2019.    

Hi everyone,

the original issue of this thread will be addressed in a next update. I have received an "insider" build from Acronis RnD and the issue is solved there. 

Also "." in job names are ok then, e.g. when the backup target is an external WD drive this is the name picked automatically.

Enchantech wrote:

Your issue is likely related to changes in Windows 10 and TI 2020 networking.  It has more to do with Windows changes than TI.

Below is a link that may help you solve the issue you face.

LINK

Hi @Enchantech. :)

As your above post wasn't mentioning me and/or didn't quote anything from my post (#23) I'm unsure whether it was a direct reply to my post or not. But as your post (#24) was the next post I'm assuming that it was in reply to my post. I do apologise if it wasn't.

If it was a reply to my post then thank you very much for your post. :)

It's obviously been quite a while since I made that post and since then there have been many more posts. And also Acronis released 'Update 1 (v21400)' for ATI2020. The update addressed numerous issues and since I installed that update I've not had any errors with my backups. I did not install any Windows Updates or change any settings on my PC or NAS so it does appear that the ATI 21400 update has fixed whatever it was that was wrong.

If anyone elses post(s) was intended for me then thank you too and I'm sorry I didn't reply. Much of the content was way over my head. I have much research to do in order to understand everything. But I suppose the important thing is that I'm not getting anymore errors with my ATI backups.

:)