The restore fails immediately with the following error: Index was outside the bounds of the array

Hi everyone,

I am experiencing a critical issue during my initial setup of Duplicati. While the backup process to Google Drive completes without any reported errors, the restore process fails consistently with a technical error.

Setup:

  • Duplicati Version: Duplicati with - 2.2.0.3 - 2.2.0.3_stable_2026-01-06 (Running in Docker via lscr.io/linuxserver/duplicati:latest)

  • OS: Debian-based NAS

  • Backend: Google Drive (via AuthID)

  • Encryption: AES-256 (Built-in)

The Issue: After a successful initial backup of approximately 2GB of data (Docker configs and system files), I attempted a restore test.

  1. I selected a single small log file (~100KB) to restore.

  2. I chose a specific restore path that has full write permissions (/config/restore-test/).

  3. The restore fails immediately with the following error: Index was outside the bounds of the array.

Steps I have already taken:

  1. Database Repair: I ran the “Repair” button. It completed, but the restore still failed with the same error.

  2. Database Recreate: I deleted the local database and let Duplicati recreate it from the cloud files. The recreate process finished successfully, but the restore still results in the same IndexOutOfRangeException.

  3. Permissions Check: I confirmed the container has write access to the restore folder. When I try to restore to a Read-Only mount, I get a proper “Permission Denied” error, but when pointing to a writable volume, I get the Array Index error instead.

  4. Clean Slate: I have manually emptied the Google Drive folder, wiped the local /config folder, and started a fresh backup. The first restore attempt on this brand-new backup immediately threw the same error.

Logs: The logs show a System.IndexOutOfRangeException during the Run() -> ... -> DoRun() sequence.

This is a fresh install and I am worried about the reliability of the backups if the very first restore test fails on a basic index error. Is this a known bug with the current Beta/Docker image or is there a specific setting in the Google Drive backend that causes this?

Any help would be greatly appreciated.

Welcome to the forum @Lucas

I typed message into forum search box, got below. You can compare, test:

Restore failing on every attempt

From my point of view, the workaround helps but there is a bug to be fixed.
The message is kind of generic. There’s one in the Issues, but it’s different.
Hopefully your report or the other will help characterize this problem better.

That’s super vague. Can you find anything with actual path to the problem?

Since it fails immediately, About → Logs → Live at Error level might be nice.

About → Logs → Stored might have something already there. Click on error.

Harder are options log-file=<file> log-file-log-level=information.

Thank you for your welcome and input! I just tested a restore from version 2 of the backup, and that passed. I had some heavy iowait queue that I resolved, I suspect it might had something to do with it.

About → Logs → Live seems to be empty, it only shows stored:

Live log, once turned on, shows live activity, errors, etc. If no activity, it’s empty.
I don’t know if it would have gotten any more. Your stored looks like the other in

Duplicati.Library.Main.Operation.Restore.VolumeDownloader

except they managed to find a little more. They said later that it was Backblaze.
So apparently it’s not just on Google Drive. Maybe I should test from OneDrive.

Alternatively, you could experiment if you have any other destinations available.
You’d have to move the backup files, but won’t need to mess with job database.

The point of this error looks like the new restore, so legacy-restore may help.

EDIT:

and note the talk over there of space issues. New restore can be /tmp-hungry.
Even if that’s it, error message could use improving, and error line isn’t known.

My small OneDrive file restore on Windows worked fine, but Temp is part of C:
If you suspect a /tmp problem, the other issue talks about --tempdir option.

Just thought I’d check in to say I had exactly the same “Index was outside the bounds of the array“ error when attempting for restore from an ssh destination. The files were uploaded from a Windows 11 client, and restored to a different PC, also Windows 11. legacy-restore allowed the restore process to work.

Hi @triatic, welcome to the forum :waving_hand:

We have been chasing this error for a while and not figure out how to reproduce it. The stack trace is pretty clear, but there is no array access in the code, so something is eluding us.

Could either of you try these two setups:

  • Set --restore-channel-buffer-size=1 to ensure it is not zero
  • Set --restore-volume-downloaders=1 to ensure we only have one process downloading at a time
  • Set --log-file-log-level=ExplicitOnly, --internal-profiling=true and --log-file=./path-to-file.txt

The first is a guess to a possible cause, and the second should give us some log messages and timing data that could possibly explain where in the code the error occurs.

Thanks @kenkendk

The resulting logfile was huge, but these are the last few lines:

2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.BlockManager-CheckCounts]: Trying to acquire m_blockcount_lock for block 32811
2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.BlockManager-CheckCounts]: Released m_blockcount_lock for block 32811
2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.BlockManager-BlockHandler]: Decremented counts for block 32811 and volume 255
2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.BlockManager-BlockHandler]: Received block request: Download
2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.BlockManager-BlockCacheGet]: Getting block 5661 from cache
2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.BlockManager-BlockCacheGet]: Requesting block 5661 from volume 110
2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.VolumeManager-VolumeRequest]: Got a request for block 5661 from volume 110
2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.VolumeManager-VolumeRequest]: Block 5661 not found in cache, requesting volume 110
2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.BlockManager-BlockHandler]: Retrieved data for block 5661 and volume 110
2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.BlockManager-BlockHandler]: Passed data for block 5661 and volume 110 to FileProcessor
2026-03-03 16:29:11 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.VolumeManager-VolumeRequest]: Waiting for volume request or response
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Backend.GetOperation-DownloadSpeed]: Downloaded duplicati-b2e71749897404bbf862726ba42772251.dblock.zip.aes to C:\WINDOWS\SystemTemp\dup-72410025-4b15-499e-a560-e8949afb839f (49.65 MiB) in 00:00:11.2631643, 4.41 MiB/s
2026-03-03 16:29:21 +00 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: Get - Completed: duplicati-b2e71749897404bbf862726ba42772251.dblock.zip.aes (49.65 MiB)
2026-03-03 16:29:21 +00 - [Profiling-Timer.Finished-Duplicati.Library.Main.Backend.Handler-RemoteOperationGet]: RemoteOperationGet took 0:00:00:11.264
2026-03-03 16:29:21 +00 - [Error-Duplicati.Library.Main.Operation.Restore.VolumeDownloader-DownloadError]: Error during download
System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at Duplicati.Library.Main.Operation.Restore.VolumeDownloader.<>c__DisplayClass3_0.<<Run>b__0>d.MoveNext()
2026-03-03 16:29:21 +00 - [Verbose-Duplicati.Library.Main.Operation.Restore.VolumeDecryptor-RetiredProcess]: Volume decryptor retired
2026-03-03 16:29:21 +00 - [Verbose-Duplicati.Library.Main.Operation.Restore.VolumeDecryptor-RetiredProcess]: Volume decryptor retired
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.VolumeDecryptor-InternalTimings]: Read: 12929ms, Decrypt: 0ms, BlockVolumeReader: 0ms, VolumeWrapper: 0ms, Write: 0ms
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.VolumeDecryptor-InternalTimings]: Read: 12929ms, Decrypt: 0ms, BlockVolumeReader: 0ms, VolumeWrapper: 0ms, Write: 0ms
2026-03-03 16:29:21 +00 - [Verbose-Duplicati.Library.Main.Operation.Restore.VolumeManager-RetiredProcess]: Volume manager retired
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.VolumeManager-InternalTimings]: CacheSet: 0ms, CacheEvict: 0ms, Query: 0ms, Backend: 0ms, Request: 0ms, Wakeup: 0ms
2026-03-03 16:29:21 +00 - [Verbose-Duplicati.Library.Main.Operation.Restore.VolumeDecompressor-RetiredProcess]: Volume decompressor retired
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.VolumeDecompressor-InternalTimings]: Read: 12930ms, Write: 0ms, Decompress allocate: 0ms, Decompress instantiate: 0ms, Decompress lock: 0ms, Decompress read: 0ms, Verify: 0ms
2026-03-03 16:29:21 +00 - [Verbose-Duplicati.Library.Main.Operation.Restore.VolumeDecompressor-RetiredProcess]: Volume decompressor retired
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.VolumeDecompressor-InternalTimings]: Read: 12930ms, Write: 0ms, Decompress allocate: 0ms, Decompress instantiate: 0ms, Decompress lock: 0ms, Decompress read: 0ms, Verify: 0ms
2026-03-03 16:29:21 +00 - [Verbose-Duplicati.Library.Main.Operation.Restore.BlockManager-RetiredProcess]: BlockManager Volume consumer retired
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.BlockManager-InternalTimings]: Volume consumer - Read: 12930ms, Set: 0ms
2026-03-03 16:29:21 +00 - [Verbose-Duplicati.Library.Main.Operation.Restore.BlockManager-RetiredProcess]: BlockManager Block handler retired
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.BlockManager-InternalTimings]: Block handler - Req: 12909ms, Resp: 0ms, Cache: 10ms, Get: 3ms
2026-03-03 16:29:21 +00 - [Verbose-Duplicati.Library.Main.Operation.Restore.FileProcessor-RetiredProcess]: File processor retired
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.FileProcessor-InternalTimings]: File: 0ms, Block: 18ms, Meta: 0ms, Req: 29ms, Resp: 9003ms, Work: 0ms, VerifyTarget: 2931ms, Retarget: 0ms, NotifyLocal: 29ms, VerifyLocal: 0ms, EmptyFile: 0ms, Hash: 1039ms, Read: 126ms, Write: 0ms, Results: 0ms, Meta: 0ms
2026-03-03 16:29:21 +00 - [Verbose-Duplicati.Library.Main.Operation.Restore.FileProcessor-RetiredProcess]: File processor retired
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.FileProcessor-InternalTimings]: File: 0ms, Block: 4ms, Meta: 0ms, Req: 20ms, Resp: 10251ms, Work: 0ms, VerifyTarget: 1835ms, Retarget: 0ms, NotifyLocal: 20ms, VerifyLocal: 0ms, EmptyFile: 0ms, Hash: 906ms, Read: 111ms, Write: 0ms, Results: 0ms, Meta: 0ms
2026-03-03 16:29:21 +00 - [Verbose-Duplicati.Library.Main.Operation.Restore.BlockManager-RetiredProcess]: BlockManager Block handler retired
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.BlockManager-InternalTimings]: Block handler - Req: 12903ms, Resp: 0ms, Cache: 14ms, Get: 0ms
2026-03-03 16:29:21 +00 - [Error-Duplicati.Library.Main.Operation.Restore.FileLister-FileListerError]: Error during file listing
CoCoL.RetiredException: The channel "" is retired
   at CoCoL.Channel`1.WriteAsync(T value, ITwoPhaseOffer offer)
   at Duplicati.Library.Main.Operation.Restore.FileLister.<>c__DisplayClass1_0.<<Run>b__0>d.MoveNext()
2026-03-03 16:29:21 +00 - [Error-Duplicati.Library.Main.Operation.Restore.BlockManager-BlockCountError]: Block count in SleepableDictionarys block table is not zero: 59414
First 10 blocks: 16759, 6358, 23249, 23247, 23244, 23241, 23239, 23237, 23235, 23233
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.FileLister-InternalTimings]: Get files: 83ms, Write files: 13151ms, Get folders: 0ms, Write folders: 0ms
2026-03-03 16:29:21 +00 - [Error-Duplicati.Library.Main.Operation.Restore.BlockManager-VolumeCountError]: Volume count in SleepableDictionarys volume table is not zero: 59414
First 10 volumes: 239, 119, 114, -1, 171, 215, 203, 214, 226, 56
2026-03-03 16:29:21 +00 - [Profiling-Duplicati.Library.Main.Operation.Restore.BlockManager-InternalTimings]: Sleepable dictionary - CheckCounts: 0ms, Get wait: 0ms, Get write: 0ms, Set set: 0ms, Set wake get: 0ms, Set wake set: 0ms, Cache evict: 0ms
2026-03-03 16:29:21 +00 - [Profiling-Timer.Finished-Duplicati.Library.Main.Operation.RestoreHandler-RestoreNetworkWait]: RestoreNetworkWait took 0:00:00:12.936
2026-03-03 16:29:21 +00 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: DROP TABLE IF EXISTS "Fileset-F8BD5C4ADD37924DB266AD18CCD962CE"
2026-03-03 16:29:21 +00 - [Profiling-Timer.Finished-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: ExecuteNonQuery: DROP TABLE IF EXISTS "Fileset-F8BD5C4ADD37924DB266AD18CCD962CE" took 0:00:00:00.003
2026-03-03 16:29:21 +00 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: DROP TABLE IF EXISTS "Blocks-F8BD5C4ADD37924DB266AD18CCD962CE"
2026-03-03 16:29:21 +00 - [Profiling-Timer.Finished-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: ExecuteNonQuery: DROP TABLE IF EXISTS "Blocks-F8BD5C4ADD37924DB266AD18CCD962CE" took 0:00:00:00.003
2026-03-03 16:29:21 +00 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: DROP TABLE IF EXISTS "FileProgress-F8BD5C4ADD37924DB266AD18CCD962CE"
2026-03-03 16:29:21 +00 - [Profiling-Timer.Finished-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: ExecuteNonQuery: DROP TABLE IF EXISTS "FileProgress-F8BD5C4ADD37924DB266AD18CCD962CE" took 0:00:00:00.000
2026-03-03 16:29:21 +00 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: DROP TABLE IF EXISTS "TotalProgress-F8BD5C4ADD37924DB266AD18CCD962CE"
2026-03-03 16:29:21 +00 - [Profiling-Timer.Finished-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: ExecuteNonQuery: DROP TABLE IF EXISTS "TotalProgress-F8BD5C4ADD37924DB266AD18CCD962CE" took 0:00:00:00.000
2026-03-03 16:29:21 +00 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: PRAGMA optimize
2026-03-03 16:29:21 +00 - [Profiling-Timer.Finished-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: ExecuteNonQuery: PRAGMA optimize took 0:00:00:00.263
2026-03-03 16:29:21 +00 - [Profiling-Timer.Finished-Duplicati.Library.Main.Controller-RunRestore]: Running Restore took 0:00:01:51.063
2026-03-03 16:29:21 +00 - [Error-Duplicati.Library.Main.Controller-FailedOperation]: The operation Restore has failed
System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at Duplicati.Library.Main.Operation.Restore.VolumeDownloader.<>c__DisplayClass3_0.<<Run>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at CoCoL.AutomationExtensions.RunTask[T](T channels, Func`2 method, Boolean catchRetiredExceptions)
   at Duplicati.Library.Main.Operation.RestoreHandler.DoRunNewAsync(IBackendManager backendManager, LocalRestoreDatabase database, IFilter filter, CancellationToken cancellationToken)
   at Duplicati.Library.Main.Operation.RestoreHandler.RunAsync(String[] paths, IBackendManager backendManager, IFilter filter)
   at Duplicati.Library.Main.Controller.<>c__DisplayClass23_0.<<Restore>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Duplicati.Library.Utility.Utility.Await(Task task)
   at Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Func`3 method)

Thanks, I will digest it.

One quick question: do you have low temporary disk space?
We are chasing an idea where C:\WINDOWS\SystemTemp\ is low on disk space and this causes SQLite to misbehave and return incomplete results. If you have plenty of free disk space we can close that idea quickly.

No, I have plenty of free disk space.

Thanks! Then we can rule that one out.

Is it possible for you to zip the whole logfile and share it with me?

If not, I am looking for all lines containing:

Duplicati.Library.Main.Operation.Restore.VolumeDownloader

There should be some lines before the failure one, as I can see the download has completed immediately before the crash, and only the VolumeDownloader should start the download.


Also, could you let me know the exact version of Windows and the culture/language setting?

Actually. I think we found the issue!

It has already been fixed in the latest canary build, and will be fixed in the next beta/stable release.

It was caused by a method used to create some diagnostics numbers that are no longer being used.

The only instance not included in my paste is this:

2026-03-03 16:29:10 +00 - [ExplicitOnly-Duplicati.Library.Main.Operation.Restore.VolumeDownloader-DownloadVolume]: Downloading volume 262

I’m using Windows 11, version 10.0.26100.7840. Language/locale is United Kingdom.

Anyway, I see you might have found the issue, I look forward to the next build!

1 Like

I’m glad to hear this. I am still getting this error as well (from Restore error: "Index was outside the bounds of the array"). Would it be possible for you to let me know the version that fixes this so I can watch for it in the unRAID docker update? Thank you.

Assuming you use image from https://hub.docker.com/r/linuxserver/duplicati

Release: 2.2.1.0 (Beta) 2026-03-05 in development looks like it has this fix.
That’s based on the Mar 4 post and a look in source.

1 Like

Hi, I just got this issue too. Do I need to rebuild the database as a workaround given the age of the database anyway? Thanks

Using the legacy-restore option was sufficient for me.

1 Like

No, the error is in the new restore flow.
It happens if you run more than one restore without restarting Duplicati.
The workaround is using legacy-restore as @triatic mentions.

You can also update to the latest beta release as @ts678 suggests:
Release: 2.2.1.0 (Beta) 2026-03-05

1 Like

I am using the Docker version of this, so all I need to do is to simply restart the container between each Restore?

Yes, that should work.

1 Like

Thanks, can confirm that the issue still persists in latest Docker image/container from linuxserver but restarting the container between each restore attempt (be it successful or failed) helps to workaround this issue

Hoping for the Docker image to have the update soon to resolve this fully