Failed to read data from disk – does nonstop backup interfering?
Hi!
Well, this thread concerning TI 2017, 2018 and 2019.
I had TI 2017 and upgraded it to 2018. I was running TI for full backup of disk and no problem was reported during using TI 2017. After upgrade I start to get errors “Failed to read data from disk”. I checked disk using (Windows 10) chkdsk /f /r, it took … over 10 hours and stuck at 12%, but I remain calm and it finished next morning wo problems. Then I tried again to take an image and … same error appears. Mh. I tried to another disk (!), same. Then I let it ignore errors and backup finished. Then I upgraded TI 2018 to 2019 (was entitled) and started backup again … next morning no errors on screen and in TI everything was “green”, but … I had notification in mailbox about error(s) – around 0:24 AM was backup stopped due error(s) – “2018-08-25T00:24:17:405+03:00 1352 E000101F6: Error 0x101f6: Read error”. Anyway, weird is that I had another notification about success of the same job at 6:35 AM. Job was started “by schedule” at 0:24 AM, after this failed attempt. Odd a bit. I’m glad it was successfully finished, but … This job was firstly started manually, no schedule at all. Perhaps error triggered to start it again, never seen this before. (Wasn’t in TI 2018, neither in 2017.) But … success? What about read error(s) this time!? Also, I mentioned before about job I let finishing by ignoring errors, this was another job to another disk, but with exactly same content – even in TI I see same amount of files, size etc. reported, but … ignored (and successfully finished) tib-file was 150 GB less in size comparing this one which finished today morning (~ 320 GB vs 470)! Sure, maybe those read errors lead to this significant difference (unreadable content not backed up), but then disk (when blamed to) must be broken to pieces according to TI failed attempt, don’t You think!? And this kind of problem should be “noticed” by Windows 10 which is running well this very moment (including chkdsk). Huge difference … almost size of … I have also nonstop backup running (since TI 2017) – I wonder could this problem related!? I see that nonstop backup stopped just before running second “scheduled” and successful backup, mh. And this size difference of two backups (ignored vs successful) almost size of nonstop …
Day after I suspended nonstop backup before performing scheduled full backup and … no errors appear!
More thanks, Alar.
Hi and thanks!
Yesterday I suspended nonstop and … no error.
Probably I must make a call to support. I would say, if I’m correct, this is defect and should be sorted out by Acronis. Interestingly, this wasn’t issue (at least not appear) in TI 2017 and started with TI 2018. Well, anyway. I can’t exclude nonstop area, well, don’t want to, different meaning. Too bad!
More thanks, Alar.
One of the beta testers reported problem associated with non-stop backup - full disk content and it just stopped backing up. No idea if it has been resolved.
I have just created a non-stop backup for all content of a partition - backing up to my NAS. There is a weekly backup both to Acronis Cloud and my NAS, but they have not yet cut in. I will keep an eye out.
Have lodged feedback (accompanied by system report) for this problem?
Ian
Hi and thanks!
Yes, I opened case, we’ll see. Hopefully they able to reproduce this issue.
More thanks, Alar.
Hi!
Any experiences on this subject? Am I alone with this kind of error? From support … not sure they tried to reproduce issue. Well, they said not good idea to have two backups set to run at the same time. Sure, but hardly I can do something – when one does have a nonstop (which does work … all the time, can’t customize it) then according to support we can’t have on same machine another (full) backups which does overlap nonstop one or vice versa. Mh.
More thanks, Alar.
There is no evidence from my system that having non-stop backup interferes with any of backup to cloud, backup to local HDD or backup to my NAS - the non-stop backup is to the NAS.
If you have not already done so I would provide in-App feedback, making sure you have clicked on the check box for "Attach system report". Include a brief description of the problem and include a link to this thread.
Ian
After upgrade I start to get errors “Failed to read data from disk”. I checked disk using (Windows 10) chkdsk /f /r, it took … over 10 hours and stuck at 12%, but I remain calm and it finished next morning wo problems. Then I tried again to take an image and … same error appears.
Alar, are you still getting the same 'Failed to read data from disk' errors?
If you are, then I doubt that this has anything at all to do with using NSB but would need to see some examples of the actual backup log files to better understand what exactly is being reported here. If you can attach some of the log files either as text attachments, or zipped that would help.
IanL-S wrote:There is no evidence from my system that having non-stop backup interferes with any of backup to cloud, backup to local HDD or backup to my NAS - the non-stop backup is to the NAS.
If you have not already done so I would provide in-App feedback, making sure you have clicked on the check box for "Attach system report". Include a brief description of the problem and include a link to this thread.
Ian
Hi and thanks!
Well, could be something special here after all, mh. But have You seen, is nonstop backup suspended during regular (full) backup?
Thanks, Alar.
Steve Smith wrote:After upgrade I start to get errors “Failed to read data from disk”. I checked disk using (Windows 10) chkdsk /f /r, it took … over 10 hours and stuck at 12%, but I remain calm and it finished next morning wo problems. Then I tried again to take an image and … same error appears.
Alar, are you still getting the same 'Failed to read data from disk' errors?
If you are, then I doubt that this has anything at all to do with using NSB but would need to see some examples of the actual backup log files to better understand what exactly is being reported here. If you can attach some of the log files either as text attachments, or zipped that would help.
Hi and thanks!
So far I manually suspend nonstop backup for night when regular (full) backup is performed and no error appear. At morning I’ll start nonstop backup again.
As I wrote – same backup scheme with TI 2017 resulted with no error(s). In TI 2018 at morning I was seen error on TI screen – “Failed to read data from the disk.” and sector etc. In e-mail I saw …
---
Information: Failed to read data from the disk.
Details: Failed to read from sector '814 408 296' of hard disk '1'. Try to repeat the operation. If the error persists, check the disk using Check Disk Utility and create a backup of the disk.
Failed to read the snapshot. See VSS logs for details. (0x10C481) Unknown status. (0x9) The device is not ready (0xFFF0)
---
Then I checked disk, but no errors whatsoever.
After that I upgraded to TI 2019 (it was just released) and then I started to see two (full) backup jobs performed during night time – first one with failed result, second one right after failed one with success.
---
2018-08-26T02:54:29:502+03:00 6048 E000101F6: Error 0x101f6: Read error
| trace level: error
| line: 0x65b5eb7011094703
| file: c:\bs_hudson\workspace\544\processor\diskadm\da_commit.cpp:348
| function: DaProcessor::CommitImpl::OnDaError
| line: 0x65b5eb7011094703, c:\bs_hudson\workspace\544\processor\diskadm\da_commit.cpp:348, DaProcessor::CommitImpl::OnDaError
| $module: ti_demon_vs_13660
|
| error 0x70003: Read error
| line: 0xdf81da2c74ec5024
| file: c:\bs_hudson\workspace\544\core\resizer\backup\output_stream.cpp:98
| function: `anonymous-namespace'::ReadDrive
| line: 0xdf81da2c74ec5024, c:\bs_hudson\workspace\544\core\resizer\backup\output_stream.cpp:98, `anonymous-namespace'::ReadDrive
| $module: ti_demon_vs_13660
|
| error 0x10c482: A fatal error occurred while reading the snapshot. The snapshot was canceled by the system. See system logs for details.
| line: 0x3fec04e376b89f08
| file: c:\bs_hudson\workspace\544\core\fdisk\win_snapshot.cpp:530
| function: win_snapshot_volume::IoOp
| line: 0x3fec04e376b89f08, c:\bs_hudson\workspace\544\core\fdisk\win_snapshot.cpp:530, win_snapshot_volume::IoOp
| $module: ti_demon_vs_13660
|
| error 0x9: Unknown status.
| line: 0x2aacb7b2ab852ac
| file: c:\bs_hudson\workspace\544\core\fdisk\ver2\arch\windows\win_errors.cpp:40
| function: Fdisk::AddKstatusError
| line: 0x2aacb7b2ab852ac, c:\bs_hudson\workspace\544\core\fdisk\ver2\arch\windows\win_errors.cpp:40, Fdisk::AddKstatusError
| code: 0x15
| $module: ti_demon_vs_13660
|
| error 0xfff0: The device is not ready
| line: 0xbd28fdbd64edb8f1
| file: c:\bs_hudson\workspace\544\core\common\error.cpp:307
| function: Common::Error::AddWindowsError
| line: 0xbd28fdbd64edb8f1, c:\bs_hudson\workspace\544\core\common\error.cpp:307, Common::Error::AddWindowsError
| code: 0x80070015
| $module: ti_demon_vs_13660
2018-08-26T02:54:33:769+03:00 6048 E013C0005: Error 0x13c0005: Operation has completed with errors.
| trace level: error
| line: 0x9f2c53c72e8bcee4
| file: c:\bs_hudson\workspace\544\products\imager\demon\main.cpp:750
| function: main
| line: 0x9f2c53c72e8bcee4, c:\bs_hudson\workspace\544\products\imager\demon\main.cpp:750, main
| $module: ti_demon_vs_13660
---
Then I started to think about nonstop backup interfering (well, I can’t say with 99% certainty which one does interfere or where is “dog buried”) and next day I suspended nonstop before regular full backup and … voila! … no errors. But should! when disk broken, right?! Then I wrote here and afterwards to support. So, three different TI versions behave differently here.
More thanks, Alar.
Alar, there are several potential issues here:
First, NSB is just another backup / schedule scheme, so there should be no issues with using this alongside other backup / schedule schemes. If more than one backup task attempts to run at the same time, then ATI should queue these. This is what happens on my own computer and hasn't changed across many versions of ATI.
Next, Failed to read from sector '814 408 296' of hard disk '1'. type errors have always been caused by disk errors in my experience but there is a 'gotcha!' in this message, because hard disk '1' in Acronis speak is not the same as hard disk '1' in Windows speak!
Acronis numbers disk drives from 1 upwards, whereas Windows starts from 0, so in this message, Acronis hard disk '1' = Windows hard disk '0' - which is the disk that CHKDSK needs to have been run against.
A second 'gotcha!' with this type of message is that hard disk '1' is a fairly vague description of where the problem sector actually is! If running CHKDSK C: finds no errors, then you need to understand that CHKDSK only can operate against drives with an allocated drive letter, but your backup can include drives with no drive letter, i.e. hidden/system partitions.
To run CHKDSK against hidden/system partitions requires that these are given a temporary drive letter via Windows Disk Management, or else a full disk diagnostic tool is used that can check the whole disk surface etc.
Next, ' Failed to read the snapshot' in the error text tells you that the issue here is not directly in the Source data for the backup, but rather in the areas of disk being used to store snapshot data created by the Microsoft VSS snapshot service. This again can be on hidden/system partitions or in unused space on the source drive. I would suggest downloading / running the Acronis VSS Doctor tool to check your VSS configuration details and attempt to repair any issues found.
Last, 'The device is not ready' shown in the detailed log data, can suggest that you have power saving options enabled here, i.e. selective suspend for USB devices, or allow this device to be powered off when idle, etc. You should check through your Control Panel > Power Options to see if you have this type of setting enabled.
Then I started to think about nonstop backup interfering (well, I can’t say with 99% certainty which one does interfere or where is “dog buried”) and next day I suspended nonstop before regular full backup and … voila! … no errors.
Sorry, but without knowing much more detail of what exactly is included in each of your backup tasks, it is impossible to comment more on this statement other than as above. As already stated, it should be impossible for one task to interfere with another as only one task can ever be active, the second / other tasks are queued and inactive.
Hi and thanks!
Well, I’m not sure at all what is going on in deep, but … there is a BUT – why this disk error does not appear during regular full backup(s)? Shouldn’t it appear? And why it (this error) stopped appear after suspending nonstop backup? There seems to be some connection between those backup jobs running.
More thanks, Alar.
Alar, sorry I can't answer the 'but why?' question with only the information provided.
Can you confirm that you are still seeing the disk error, and if so, when is it being given?
If the error is still given, then please collect an Acronis System Report zip file and let me know what size this is?
Hi and thank You!
Well, but when disk has some problems shouldn’t it appear during this successful regular (full) backup as well? Don’t You think? But it doesn’t. (Backup running every night!)
Also … I recall (also noted above in first post) that I checked files of nonstop backup and there was updates to files during running regular (full) backup, so … both were running at the same time. Then – after failed full backup – nonstop was suspended (not sure on what reason and by which process) and full backup repeated and this time successfully.
Ahjaa, as I wrote above … when I choose to ignore errors given (I was running full backup manually) then difference in file size between successful backup and failed one was almost the amount of nonstop backup size, maybe coincidence. Unfortunately, I didn’t check inside backup to see what’s missing, sorry.
I’ll (try to) leave nonstop running (sometimes it does stop … on some another reason by system) and we’ll see how it goes, maybe it is healed by … who knows! At weekend I may have more time to run those manually.
More thanks, Alar.
Well, but when disk has some problems shouldn’t it appear during this successful regular (full) backup as well?
It would only appear if you are touching exactly the same areas of the disk in each backup.
both were running at the same time
That should not be possible as ATI is not designed to allow this - only 1 task can be active. If you are seeing 2 active at the same time (both processing the backup and not in queued state) then there is an issue with the ATI installation and I would recommend a Repair install be done.
when I choose to ignore errors given (I was running full backup manually) then difference in file size between successful backup and failed one was almost the amount of nonstop backup size, maybe coincidence.
Sorry, but it is never a good idea to ignore errors related to disk sectors - they have a habit of coming back and biting you in an unpleasant place!
Hi and thanks!
Mnjah, it’s odd when these disk errors appear when nonstop and full backups is enabled, but not when just full enabled, isn’t it!? And when some 140 GB’s is missing from backup finished when errors ignored … these errors should appear every time full backup does run, I think. I could be wrong, though. Btw., ignoring errors was just for testing purposes, obviously I’ll never trust backup with errors, that’s clear.
Well, anyway, yesterday I’d leave both tasks (nonstop and regular nightly full backup) running and … nonstop was today still active and full backup was accomplished wo any problem whatsoever! Mh, interesting. We’ll see. When I’m not able to reproduce this … there is nothing to report, mh. Could be, yesterday nonstop backup (USB) disk was fulfilled and I’d emptied it, as said – we’ll see, fingers crossed!
More thanks, Alar.