36

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?

Improve this question

4 Answers 4

Reset to default
27

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
6
  • 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
    Commented Nov 16, 2013 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
    Commented Nov 16, 2013 at 15:53
  • You misunderstood my comment above. Nevermind, I will ask a new question.
    – uncovery
    Commented Nov 17, 2013 at 5:28
  • 3
    TGT is just target, right? Might be better to just say target, then.
    – Jasper
    Commented Sep 17, 2019 at 7:23
  • 3
    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
    Commented Dec 30, 2019 at 13:00
8

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
2

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
2

I had this problem, and I successfully used ddrescue to recover my files. It's a great tool from GNU, which you can install in Ubuntu via

sudo apt install gddrescue

Basically, use cp to copy a folder. The errors regarding input/output error, you copy-paste them in vim or your favourite text editor. Remove the error message, so that only the file location is present per line. Then read the file line-by-line and apply ddrescue, like so

while read f; do
    ddrescue $f ~/folder/$f
done < corrupted_files.txt

Kudos to this answer on Stack Overflow for the nice line-by-line file-reading.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .