25

I am running a daily backup with rsync. Starting some days ago, one of the files has been throwing this error during the backup:

rsync: read errors mapping "/home/folder/file.ext": Input/output error (5)
WARNING: /home/folder/file.ext failed verification -- update discarded (will try again).

What's the best course of action? Is it just a broken file? Or is there something wrong with the hard drive in the location of the file? Should I just delete it and copy one of the backed up versions into the file's location? Or is there something else/more that I should do?

18

The rsync error

 read errors mapping ....: Input/output error (5)

indicates the impossibility of rsync to read or write a file. The most likely causes of this error are disk defects, either in the SRC or in the TGT directory. Other possibilities however include insufficient permissions, file lock by anti-virus programs, and maybe other causes.

The first step toward a diagnosis is to try to copy the files manually. This may work if, for instance, the source of the error was a disk defect in the TGT directory; by repeating the operation at a later time, you will write into a different section of the disk, and the problem may have evaporated.

Alternatively, you may discover that you cannot access the file in the SRC directory. In this case I suggest that you employ any of the disk checking utilities available to your distro.

Insufficient privileges, anti-virus, are easier to diagnose.

Lastly, if you have a bad sector on your SRC directory, you may exclude that from future runs of rsync by means of

rsync -av --exclude='/home/my_name/directory_with_corrupt_files/*'
| improve this answer | |
  • Thanks! At the risk of this being another question, how do I find out if it's the SRC or the TGT directory if I can rule out privileges or anti-virus? – uncovery Nov 16 '13 at 14:40
  • An anti-virus locks files for some time. If that is the problem, re-trying the same command some time later should not present the same error. The matter of privileges is easy: use root account on both SRC and TGT machines. If you cannot do that, check that the files on which rsync fails are accessible to you, i.e. they belong to the account trying to access them, and if they don't that you have read access to them. If this solves your matter, pls remember to accept my answer, it is useful to other readers. – MariusMatutiae Nov 16 '13 at 15:53
  • You misunderstood my comment above. Nevermind, I will ask a new question. – uncovery Nov 17 '13 at 5:28
  • 2
    TGT is just target, right? Might be better to just say target, then. – Jasper Sep 17 '19 at 7:23
  • 1
    It seems that your answer gave birth to a whole article bobcares.com/blog/rsync-input-output-error_5 (without references, of course). – Yaroslav Nikitenko Dec 30 '19 at 13:00
5

I had a similar issue, I had a with fuse-mounted device via USB, which would frequently disconnect, causing IO errors. My backup could never finish because the IO errors would start mid-way into the rsync, and despite running rsync repeatedly, at some point the sync would not progress beyond updating existing files.

My solution was to use

--ignore-existing 

option. This way I could run the sync in a loop until seeing a 0 exit status.

Of course, in this case I didn't care about updates to existing files.

| improve this answer | |
0

I have 2 external drives I keep in sync, using rsync. I perform this task regularly on either of two machines, and frequently switch from one to the other for the sake of convenience. I have 4 machines running Debian 9, and use these drives on each of them.

This morning I used the following:

rsync -ahv --delete drive-x drive-y 

and was surprised to have a few hundred reported failures.

mostly: rsync: readlink_stat... failed: Input/output error (5)
also: rsync: rsync: recv_generator: mkdir ... failed: Read-only file system (30)

In the process to find out what happened, I remounted the drives twice, rebooted, ran rsync without --delete and basically my normal tries to fix something that has reliably worked for a long time. Even thought about installing rsync again. Before I would do that I decided to rsync the 2 drives on the other machine, which I run offline. rsync worked just the way it should.

Having read the material posted here, I installed clamav, updated the signatures, and scanned my home directory. I use this regularly on a different machine. I found 1 and only 1 PUA, and I deleted it. I always delete PUA's. I then remounted the two drives with this machine, and added different test files and folders to each drive.

I ran rsync -ahv --delete drive_x drive_y and everything worked fine.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.