Backup restore fails with Input/output error


So, I did a complete backup of my Ubuntu MATE system and installed vanilla Ubuntu so I could see if all the GNOME improvements were real... and now I can't restore from my backup. I get "Restore Failed. Giving up after 5 attempts. Error: Error splicing file: Input/output error."
I had an encrypted backup on a physical drive, not on Google or any cloud provider. Does the switch from MATE to GNOME have anything to do with it, maybe?


Personally, I doubt the switch from Mate to Gnome is related.

There was a discussion about the "splicing" error here a few days ago, in this thread:

I have had that error particularly with large files. I've never pinned down if it is a buffering problem, or just that a huge file is more likely to evidence a random error.

My guess is your backup had file errors in it. Was it a plain backup? Or in a format with checksum/restore capabilities like .tar or even .zip?


It was in .gpg format. It looks like duplicity-full.<date and time>.manifest.gpg

The backup is about 120 GB in size, but I've done restores that size before. It seems to stop when importing my Virtual Studio Code preferences from ~/.config, which I didn't even know it was backing up. Since there are about 2300 files in the backup, maybe I could somehow figure out which one is the offender and delete it?


Hello Leoj03

I went the other way once in 2014, I never did go back though. :slightly_smiling_face:

If I were in your position I would consider having a second backup made with Grsync. Look at the video on this post:

Restoring from a Grsync backup might work for you.


The problem is, I already reinstalled, so my Deja Dup backup is my only backup.


Since Deja Dup is powered by duplicity, you can try restoring manually via the Terminal:

duplicity restore file:///path/to/backups/ /path/to/extract-to/

Or like this:

duplicity restore --file-to-restore / file:///path/to/backups/ /path/to/extract-to/

The other way to extract the files is to look into the difftar files, which are just regular tarballs - but encrypted with GPG:


So this might be another way is to decrypt and extract the contents:

gpg duplicity-full.XXXXXXXXXXXXXXXX.vol1.difftar.gpg
tar -xvf *.difftar

If there's many of them, they will span across multiple files as this backup method stores files that changed since the last one. It's possible the I/O error could occur again (in which would suggest a hard drive issue)

Deja Dup likely won't accept them if you were to modify the tarballs and re-encrypt them (gpg -c), since that would invalidate the signatures.

I manually use a shell script that uses rsync to backup. grsync which @alpinejohn suggests is actually a frontend for rsync.


I think the Input/output error is an external drive error, since I copied the backup files to my internal hard drive and didn't get it, but now it gets stuck while backup up ~/.config/Code, which I think is my Virtual Studio Code config. It stayed stuck on that for about two hours. Sometimes it just says "Failed for an unknown reason," but that goes away if I reboot.


Hello Leoj03

This is a work-around.

Duplicity makes compressed backups - so you need duplicity to read them back onto a system.
You might consider the following if all else fails:

  1. Install Mx Linux on a computer (Debian-based and installs almost everywhere).
  2. Install Synaptic package manager.
  3. Via Synaptic install duplicity.
  4. Point duplicity to the backup location and try to restore.
  5. If the restore works, make a Grsync uncompressed backup.
  6. Use the Grsync uncompressed backup to try to restore to your original computer.

Sound crazy? Perhaps. But if all else fails it might work.


@alpinejohn Before I go and install Linux on some computer I don't have available for Linux...
When I try to do it from the command line with gpg --multifile --decrypt duplicity-full.XXXXXXXXXXXXXXXX.*.difftar.gpg I get an error saying Fatal: zlib inflate problem: invalid stored block lengths. I've tried looking this up, but I can't find anything to help. I think that if I can find the bad file, maybe I can remove it, but that command doesn't tell me what file it's on. Also, as I said before, Deja Dup gets stuck on some file in ~/.config/Code but doesn't say anything. However, I noticed a small exclamation point on the icon that went away when I closed the window.


Hello Leoj03

My last idea - have you tried reaching out to the duplicity maintainer/team [] ? If you are fighting to recover your only copy of your data the measure is surely justified. They wrote/maintain the code. If anyone can help, I would imagine its them.

Good luck.


@alpinejohn Thanks, but I think I have a solution. If I go to a specific folder, right-click, and choose 'Restore missing files,' I can get back the files I want. It seemed to be messing up on some VSCode config file that I didn't even really want, so I think that this will work fine. Thanks to everyone who offered instruction and advice!