Some kind of disk I/O error occurred disk I/O error

Support
#1

Hi,

I’ve been successfully running backups for a while however have recently noticed that my backups are failing due to this very non specific error. Some kind of disk I/O error occurred disk I/O error

Details:

  • No logs are generated when the error occurs (no new logs since the first failed run a while back)
  • This error is only affecting two out of the five different backups I have scheduled, the others run successfully.
  • I am backing up into Backblaze B2
  • Every operation that I attempt on a given backup seems to fail with the same error.
  • Running as a Docker service on UnRaid 6.5.3
  • Duplicati version 2.0.3.3_beta_2018-04-02
  • My disks seem fine, I can’t find any sign of data corruption or performance problems.

None of the other forum posts with this issue have solutions, so I’d like to help work this out for everyone facing the same very generic error message.

Cheers,

#2

Hello @jamesishoward and welcome to the forum!

Please (if possible) post all lines of the error. Commonly there’s some sort of exception and a big stack trace.

Examples:

Backup falied: Some kind of disk I/O error occurred
Some kind of disk I/O error occurred

and the message itself is not in Duplicati source. SQLite seems to be the usual source (per Google search).

If this is SQLite seeing an error, it has both the very non-specific error code, and better ones which look like:

Extended Result CodesExtended Result Codes

Stated more precisely, I think the exact words are from a library that connects with the low-level SQLite code but which didn’t have wording for extended result codes, last I looked (or I might be wrong about the details).

If the complaint is SQLite and is per-job, you can find the path to the job SQLite database on the job menu.

Database management explains some of the things you could try, such as moving the database elsewhere. Obviously you must be careful if a backup is important. Ideally, you’d have a bad one you cared less about.

If the logs you refer to are per-job logs (About --> Show log or –log-file, those are kept in the job database. Setting up a separate log with a heavy –log-level could possibly catch something that’s going on, and you could also watch live with the log level of your choice in a different tab that’s at About --> Show log --> Live.

Does any of this give you a start on figuring out what’s going wrong? You could possibly trace system calls, searching for an actual I/O error (there might also be system logs), but I don’t know if you would locate one.

Thanks for offering to help. You might have already read the two forum posts I cited that were never solved.

#3

There are no logs being generated and saved that I can see through the Duplicati interface for any attempts to run backups beyond the first one that failed a while ago. I’ve included that log here though for reference. (I replaced any explicit references to files with generic bracketed descriptions)

 Failed to process path: <path>/<video file>.mp4
 Mono.Data.Sqlite.SqliteException (0x80004005): The database disk image is malformed
 database disk image is malformed
   at Mono.Data.Sqlite.SQLite3.Reset (Mono.Data.Sqlite.SqliteStatement stmt) [0x00084] in <ed1ed41ea9fd47469f0cf8317466f376>:0 
   at Mono.Data.Sqlite.SQLite3.Step (Mono.Data.Sqlite.SqliteStatement stmt) [0x0003d] in <ed1ed41ea9fd47469f0cf8317466f376>:0 
   at Mono.Data.Sqlite.SqliteDataReader.NextResult () [0x00104] in <ed1ed41ea9fd47469f0cf8317466f376>:0 
   at Mono.Data.Sqlite.SqliteDataReader..ctor (Mono.Data.Sqlite.SqliteCommand cmd, System.Data.CommandBehavior behave) [0x0004e] in <ed1ed41ea9fd47469f0cf8317466f376>:0 
   at (wrapper remoting-invoke-with-check) Mono.Data.Sqlite.SqliteDataReader..ctor(Mono.Data.Sqlite.SqliteCommand,System.Data.CommandBehavior)
   at Mono.Data.Sqlite.SqliteCommand.ExecuteReader (System.Data.CommandBehavior behavior) [0x00006] in <ed1ed41ea9fd47469f0cf8317466f376>:0 
   at Mono.Data.Sqlite.SqliteCommand.ExecuteDbDataReader (System.Data.CommandBehavior behavior) [0x00000] in <ed1ed41ea9fd47469f0cf8317466f376>:0 
   at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader () [0x00000] in <7537df9abae74be8a2feb0796914eeae>:0 
   at Duplicati.Library.Main.Database.ExtensionMethods.ExecuteScalarInt64 (System.Data.IDbCommand self, System.String cmd, System.Int64 defaultvalue, System.Object[] values) [0x0004e] in <ae134c5a9abb455eb7f06c134d211773>:0 
   at Duplicati.Library.Main.Database.ExtensionMethods.ExecuteScalarInt64 (System.Data.IDbCommand self, System.Int64 defaultvalue) [0x00000] in <ae134c5a9abb455eb7f06c134d211773>:0 
   at Duplicati.Library.Main.Database.LocalBackupDatabase.AddBlock (System.String key, System.Int64 size, System.Int64 volumeid, System.Data.IDbTransaction transaction) [0x000ae] in <ae134c5a9abb455eb7f06c134d211773>:0 
   at Duplicati.Library.Main.Operation.BackupHandler.AddBlockToOutput (Duplicati.Library.Main.BackendManager backend, System.String key, System.Byte[] data, System.Int32 offset, System.Int32 len, Duplicati.Library.Interface.CompressionHint hint, System.Boolean isBlocklistData) [0x000a1] in <ae134c5a9abb455eb7f06c134d211773>:0 
   at Duplicati.Library.Main.Operation.BackupHandler.ProcessStream (System.IO.Stream stream, Duplicati.Library.Interface.CompressionHint hint, Duplicati.Library.Main.BackendManager backend, Duplicati.Library.Utility.FileBackedStringList blocklisthashes, Duplicati.Library.Utility.FileBackedStringList hashcollector, System.Boolean skipfilehash) [0x000d8] in <ae134c5a9abb455eb7f06c134d211773>:0 
   at Duplicati.Library.Main.Operation.BackupHandler.HandleFilesystemEntry (Duplicati.Library.Snapshots.ISnapshotService snapshot, Duplicati.Library.Main.BackendManager backend, System.String path, System.IO.FileAttributes attributes) [0x00472] in <ae134c5a9abb455eb7f06c134d211773>:0
#4

The --log-file doesn’t go through the Duplicati interface. It goes right to the disk path you name.

I used to do this (and --log-level) on the server, but it seems to also work when used on the job.

The “Live” log isn’t specifically saved, but are you saying there’s nothing seen when you use it?

There are a few Duplicati examples of your latest stack trace. Maybe you can find some ideas…

Forum #2159 on MacOS. Unknown ending.

Forum #1905 on Windows with some SQLite information, and SQL repair that user did by hand.

GitHub #1585 turned out to be an actual failing drive, so was closed.

GitHub #2937 turned out to be I/O errors, but recreate was too slow.

GitHub #3358 on Windows did a database reset and backup restart.

I worry about your reported disk errors. I’m not sure where all such errors are logged, but you might try Viewing the System Log or Need help? Read me first!. or Checking disks or check in the Unraid forums, however if you’ve already done all that sort of thing, all I can say is your database either has damage or problems at this instant are making it think it has. You can try copying it, recreating it (may be slow), etc.

If you install sqlite3, that’s probably another way to do a PRAGMA integrity_check and other SQL things.