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

Support
1

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.

2

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.

3

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:

afbeelding
afbeelding1612×876 56.9 KB

afbeelding
afbeelding1580×567 25.9 KB

4

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.