Backup failed with error "The request failed due to a fatal device hardware error."

Support
#1

Hi - I am a newbie - just started trying out the CLI.

I am trying to backup one external HDD (F:) to another external HDD (E:\Backup).

I ran the command duplicacy_win_x64_2.2.3.exe backup -stats and while there was a lot of “Uploaded chunk” messages, I do see a good number of “Skipped chunk” messages too.

Uploaded chunk 161531 size 2748341, 45.30MB/s 04:17:32 52.3%
Skipped chunk 161534 size 8449156, 45.30MB/s 04:17:31 52.4%

And eventually there was

Skipped chunk 169786 size 5968377, 45.86MB/s 03:59:38 55.1%
Failed to upload the chunk 66482aaa44a51ba87e3154fc4427465ef0c81c7015691a14e12ecb5928ea8dbb: open E:\MyDuplicacyBackup/chunks/66/482aaa44a51ba87e3154fc4427465ef0c81c7015691a14e12ecb5928ea8dbb.omhdbyck.tmp: The request failed due to a fatal device hardware error.
Skipped chunk 169787 size 9448409, 45.86MB/s 03:59:38 55.1%
Skipped chunk 169788 size 2692587, 45.86MB/s 03:59:38 55.1%
Skipped chunk 169789 size 14252259, 45.86MB/s 03:59:38 55.1%
Skipped chunk 169790 size 3890744, 45.86MB/s 03:59:38 55.1%
Incomplete snapshot saved to F:\MyData/.duplicacy/incomplete

And the app exited.

Is this an issue with my destination HDD (WD 5 TB external drive)? I ran Data Lifeguard diagnostic from Western Digital and it came out showing PASSED after running for 7 to 8 hrs to checking.

Suggestions? / Thoughts?

Regards,
-Avi

#2

Welcome to the forum @hiavi !

These messages are ok, represent chunks already sent/saved from previous attempts.

This message indicates that the backup has been interrupted (for some reason). The odd thing is that this kind of interruption occurs when something “manageable” happens, such as pressing ctrl-c. When something unexpected happens, :d: often can’t save the incomplete backup information. Then something sent an interrupt command.

It really looks like a problem with the HDD, but as you said you have already run a diagnostics, so let’s discard for now.

So let’s turn to the USB connection: 2.0 or 3.0? Is it in a USB hub?

The speed of a USB 2.0 connection is about 50 ~ 60 MB/s, so it seems from your statistics that it is a 2.0.

I would check the connection (cables, connectors, etc.).

Try running with the -v option enabled for more information:

#3

I am using a USB hub - mainly because only one of the USB port on my laptop is USB 3.0 and so I got a USB 3.0 hub (TECKNET Aluminum 3-Port USB 3.0 Hub with RJ45 10/100/1000 Gigabit Ethernet Adapter Converter LAN Wired USB Network Adapter for Ultrabooks, Notebooks, Tablets and More) so that I can connect both my source (Seagate external HDD USB 3.0) and destination (WD external HDD USB 3.0) can perform at similar speeds.

I checked USB read write speeds of both source and destination drives using

winsat disk -drive g

and while read speed was almost same, the destination drive was a slightly faster than the source drive - just 135.70 MB/s vs 138.17 MB/s.

Does that change anything?

If not I can run the command again with detailed logs/debug/verbose flags set and report back.

Regards

#4

The problem may be occurring when you try to access both drives at the same time using the hub.

But I think it’s better to execute with the -v option. It can give you / us more information.

#5

I was also thinking about this: could it be that the 2 drives are consuming more power that the hub can provide? (this is even worse if you have all the hubs connected + ethernet)

#7

Not being able to use two drives at same time defeats the whole purpose of using a USB hub :slight_smile:

I was not using the ethernet - just two USB 3.0 external HDDs.

Here is the output I got when I ran the command with additional logging and debug and verbose flags

2019-11-19 06:38:42.008 INFO STORAGE_SET Storage set to E:\MyDuplicacyBackup
2019-11-19 06:38:42.009 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_MY5TBWDBOOK-DUPLICACYBACKUPS_PASSWORD
2019-11-19 06:38:42.009 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_MY5TBWDBOOK_DUPLICACYBACKUPS_PASSWORD
Enter storage password:**********
2019-11-19 06:38:46.350 TRACE CONFIG_ITERATIONS Using 16384 iterations for key derivation
2019-11-19 06:38:46.486 DEBUG STORAGE_NESTING Chunk read levels: [1], write level: 1
2019-11-19 06:38:46.487 INFO CONFIG_INFO Compression level: 100
2019-11-19 06:38:46.488 INFO CONFIG_INFO Average chunk size: 4194304
2019-11-19 06:38:46.488 INFO CONFIG_INFO Maximum chunk size: 16777216
2019-11-19 06:38:46.488 INFO CONFIG_INFO Minimum chunk size: 1048576
2019-11-19 06:38:46.488 INFO CONFIG_INFO Chunk seed: 40df6338603f48696354342d7aae4504d09b4580fca89db5b5e28a2dcf6d1a4e
2019-11-19 06:38:46.488 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_MY5TBWDBOOK-DUPLICACYBACKUPS_PASSWORD
2019-11-19 06:38:46.488 DEBUG PASSWORD_ENV_VAR Reading the environment variable DUPLICACY_MY5TBWDBOOK_DUPLICACYBACKUPS_PASSWORD
2019-11-19 06:38:46.607 DEBUG BACKUP_PARAMETERS top: F:\MyOldBackups, quick: true, tag:
2019-11-19 06:38:46.607 TRACE SNAPSHOT_DOWNLOAD_LATEST Downloading latest revision for snapshot My5TBSeagate-MyOldBackups
2019-11-19 06:38:46.607 TRACE SNAPSHOT_LIST_REVISIONS Listing revisions for snapshot My5TBSeagate-MyOldBackups
2019-11-19 06:38:46.608 ERROR SNAPSHOT_LIST Failed to list the revisions of the snapshot My5TBSeagate-MyOldBackups: mkdir E:\MyDuplicacyBackup/snapshots/My5TBSeagate-MyOldBackups: The request failed due to a fatal device hardware error.

But if I run the command manually in a command window

mkdir “E:\MyDuplicacyBackup/snapshots/My5TBSeagate-MyOldBackups”

it ran fine.

#8

The problem is with the / , \ and " (and Windows limitations).

This works (with quotation):
mkdir “E:\MyDuplicacyBackup/snapshots/My5TBSeagate-MyOldBackups”

This doesn’t work (without quotation):
mkdir E:\MyDuplicacyBackup/snapshots/My5TBSeagate-MyOldBackups

And this works (without quotation but with \):
mkdir E:\MyDuplicacyBackup\snapshots\My5TBSeagate-MyOldBackups

You’ll have to edit your preferences files to something similar to (notice the slash):

"storage": "E:/MyDuplicacyBackup",

#9

Preferences file shows

“storage”: “E:\\MyDuplicacyBackup”,

the string added beyond that is all appended by the app - so how would I influence that?

#10

Oops, sorry, my ctrl-c ctrl-v error :flushed: I already corrected the post (yes, the string added beyond is appended by :d:)

Edit the preferences file to right (forward) slash:

“storage”: “E:/MyDuplicacyBackup”,

#11

I don’t think it is a forward/back slash issue. Windows accepts both as path separators.

It is a hardware issue, as the error message says. Can you post the full Data Lifeguard log here?

#12

One question: Why is the SNAPSHOT_LIST message ("Failed to list the revisions ") showing a command related to folder creation (mkdir) instead of folder reading?

#13

Even with mixed slashes? :point_down:

I think this confuses Windows neurons…

When using forward slash in the storage name (x:/storage), and :d: complements with the rest of the path with forward slash (snapshots, etc.), Windows understands that it is a single path (x:/storage/snapshots/etc).

But when you use backslash in the name of storage (x:\storage) and :d: complements the rest with forward slash, (x:\storage/snapshots/etc) Windows does not understand that this is a long path because it doesn’t know which part is the path.

Wouldn’t that be the reason?

#14

This does sound like a hardware issue and I’d suggest test the current USB setup without Duplicacy for the time being - perhaps by copying lots of big and small files between external HDDs until it errors out.

Check your Windows System logs with Event Viewer and see what disk errors are reported, because there are surely errors or warnings in there.

#15

Unfortunately I don’t see a full log file - all I saw was a dialog showing

image

When I re-launch Data Lifeguard Diagnostic for Windows, it just shows me the same test result and no detailed log file - is there anyway to make it generate detailed logs?

I can rerun the test OR if you suggest any other 3rd party tool, I can try that too.

#16

One of the possibilities is considerer is USB controller hardware (and to some degree interoperation with USB hub firmware) misbehaving. I have witnessed more than one instance when the external USB drive, in spite of having dedicated eternal power supply would still draw over max allowable current from the USB port (without negotiating) either overloading and shutting the port off (good outcome) or causing intermittent brownouts and failures – in my case it was brief unmounts and filesystem corruption – but the behavior depends on the controller and some may even not notice anything and just write bad data. Perhaps that is what you are witnessing.

The fact that ti did not occur during surface test may not reach much - its’ a high throughput test and likely puts the controller in a full power mode as opposed to bursty writes during duplicacy backup that could hit 201992 corner cases in boxes shitty power management.

Generally using USB media is not ideal for backup – you don’t have any control over the integrity of the data written and without bit-rot recovery you cannot rely on your backup anymore. Duplicacy will likely detect corruption on restore when then block would be undecryptable but that is while helpful is not useful as the data would be lost.

#17

A google search turned up this page: " the request failed due to a fatal device hardware error " help? - WD Portable Drives - WD Community

Note that the extended test passed while the WRITE ZEROS test failed:

Test Option: QUICK TEST
Model Number: WD My Passport 0820
Firmware Number: 1007
Capacity: 0.00 GB
SMART Status: Not Available
Test Result: PASS
Test Time: 05:29:33, June 23, 2016

Test Option: EXTENDED TEST
Model Number: WD My Passport 0820
Firmware Number: 1007
Capacity: 0.00 GB
SMART Status: Not Available
Test Result: PASS
Test Time: 05:29:40, June 23, 2016

Test Option: WRITE ZEROS
Model Number: WD My Passport 0820
Firmware Number: 1007
Capacity: 0.00 GB
SMART Status: Not Available
Test Result: FAIL
Test Error Code: 20- Delete Partitions error!
Test Time: 05:30:08, June 23, 2016

So maybe the WRITE ZEROS test will expose the hardware issue?

1 Like
#18

Another consideration is poor quality USB 3.0 cables - I’ve seen a fair few fail and ruin data.

Either way, I would distrust the WD util for testing - it only tests the integrity of HDD surface one drive at a time and not the interface which, in your case, exhibits issues when read from one and writing to another.

Looks through those Windows event logs. You will find errors in there, most likely related to the controller.

#19

Thanks everyone for the support - one of the HDD integrity tests showed bad sectors - so dumping the WD HDD :frowning:

#20

ah man, 5tb down the drain :(.