When doing a backup with
rscync to a USB stick, I sometimes get for one or another file the error message
rsync: [receiver] write failed on (FILENAME) : No space left on device (28)
rsync: [sender] write error: Connection reset by peer (104)
I'm using the command
rsync -ra -T /tmp --delete FROM_DIR TO_DIR --info=del
This is weird, because the USB stick has a reported capacity of 235 GB, of which 79 GB are available. The data being backed up has a total size of about 100 GB, and each individual file is below 300 MB, most of them about 3-5 MB. During the backup process, most of the files have not changed between the original and the backup; just a few dozen ones actually need an update, but of course it could be that rsync always writes all files in this scenario (since the backup is not done over the network).
Can this type of error messages be explained with my settings, or do I have to assume that the USB stick is faulty?
The source for the backup is on an external hard disk (i.e. rsync copies some of the directories from one external disk to the backup device).
The errors occur only when the backup device is this particular USB-stick. When I use for the backup another external hard disk (which has much more free space), there is never a write error.
Since all other parameters are the same (source disk, disk for temporary files), the only "real" difference is that the device which causes less problems, happens to be a USB device, and it has much less free space than the other backup devices (hard disks, SSD).
I would like to find out if the amount of free space in the USB-stick could be the explanation for the error (and why), or if I need to assume that the USB stick is faulty (how can I check this?).
I did the following rudimentary checks for the quality of the USB-stick:
Running the Windows utility
CHKDSK ... /r
Running the external utility FakeFlashTest in the non-destructive mode. In this mode, it calculates the free space as reported by the USB drive (which roughly matches the one I got before), and then creates a a file of exactly this size, thereby filling up the drive.
Both tests went well without error. From this, I tend to conclude that there is something in the way
rsync is operating, which makes it necessary to have much more space at the destination drive available than a single file would occupy.