I have been battling the Lost four hour lock error around Producing file lists for the past 3 days.

I attempted:

• manually creating an empty lock file, as reccomended by @Shadowrunner

• restarting, updating and restoring from an appdatabackup

• renaming all files related to the Todo andtransmit processes (mostly .dat files) to .bak and let Backblaze recreate them

• run bb-doctor with --fix multiple times

• many, many times of letting it produce file lists before it immediately locks up again

Container
  Image:     beta
  build:     version=beta
  build:     revision=52a80851b6819e0ebeff94dc635df7d313d242c3
  build:     build=181
  build:     variant=beta-ubuntu26
  build:     built=2026-09-14T10:00:08Z
  Wine:      wine-11.14

Backblaze client
  Installed: 10.0.3.1075
  Available: 10.0.3.1075 (via ca000)
  Status:    up to date

@foz any help is greatly appreciated. Let me know if you need one of the various diags.

edit: resolved, backup is running again (for now), but it seems like this error can come up again anytime, if a shutdown is somehow unclean and with lock file.

backblaze64-diag-202609172259.zip

Edited September 18Sep 18 by anna

7 hours ago, anna said:

I have been battling the Lost four hour lock error around Producing file lists for the past 3 days.

I attempted:

• manually creating an empty lock file, as reccomended by @Shadowrunner

• restarting, updating and restoring from an appdatabackup

• renaming all files related to the Todo andtransmit processes (mostly .dat files) to .bak and let Backblaze recreate them

• run bb-doctor with --fix multiple times

• many, many times of letting it produce file lists before it immediately locks up again

Container
  Image:     beta
  build:     version=beta
  build:     revision=52a80851b6819e0ebeff94dc635df7d313d242c3
  build:     build=181
  build:     variant=beta-ubuntu26
  build:     built=2026-09-14T10:00:08Z
  Wine:      wine-11.14

Backblaze client
  Installed: 10.0.3.1075
  Available: 10.0.3.1075 (via ca000)
  Status:    up to date

@foz any help is greatly appreciated. Let me know if you need one of the various diags.

edit: resolved, backup is running again (for now), but it seems like this error can come up again anytime, if a shutdown is somehow unclean and with lock file.

backblaze64-diag-202609172259.zip

Any idea what resolved it?

45 minutes ago, rogman said:

Any idea what resolved it?

Also wondering - had to do an unclean shutdown and now its forever stuck on producing file lists.

I was only 18TB through the 50TB backup......

I upgraded to the latest, blindly and without checking here first, oops! Have been spoiled by all of the cool new features @foz (and @rogman too) keep adding, and am now hitting this same issue. Darn! Endlessly stuck on producing file lists too - Unsure if the container update was even related or if a simple container restart would have also done it as the Backblaze client also updated.

I've been digging through the logs but haven't yet found a clear culprit! I did see someone also filed an issue on GitHub as well (https://github.com/iamfoz/backblaze-64-personal-wine-container/issues/12), hopefully one of us can figure out a reproducible way to get it back up and running until foz is around!

It seems to coincide with beta 181 but did that release same time as a backblaze update

Hey all, busy as usual so apologies for the delay, but I've got to the bottom of the "producing file lists" problem, with thanks to everyone who posted logs here and on GitHub.

The cause is the Backblaze client itself, version 10.0.3.1075, installed by the auto-update function. Backblaze released 1075 in the same week as beta 181, and the container's updater installs the newest client on every start, so anyone who restarted since about 14 September got it. Under Wine, 1075 loses its own four-hour lock on every backup pass. The lock file is on disk; the client's check seems to miss it. The pass aborts at the transmit step, bzserv starts another a few minutes later, and that one does the same. Meanwhile, large files keep uploading through the chunk path, so the rate looks fine and bb-health says OK. The GUI stays on "Producing file lists" as that's the stage every pass restarts from.

To @rogman's question about the coincidence: it was both at once, and I've separated them. I ran 1075 on a container with the monitor unable to touch Wine at all, and it failed the same way. 10.0.1.1069 on the same image completes passes. The GitHub reporter's bundle shows the same thing from the other side: every push line before their switch carries 10.0.1.1069, and their startapp.log shows the container installing 1075 at the moment they pulled the new image.

@Shadowrunner was close. The file stays on disk throughout, and the client fails its own check for it. Creating it by hand doesn't help for the same reason, and the "Failed to grab fourHourLock" lines that follow are the next passes finding the lock the dead one left. @anna, I'd expect yours to come back; a lucky pass doesn't necessarily indicate the client is working.

The fix is in the beta that's building now:

• The container pins the client to 10.0.1.1069 by default and installs it over whatever is there, in place. Pull :beta, restart, and the next pass should complete. There's a new variable, BACKBLAZE_VERSION; set it empty when you want the updater back.

• The Status tab, the terminal monitor, bb-doctor, the metrics and notifications now warn when passes are losing the lock, so this can't hide behind a healthy-looking upload rate again.

If you don't want to wait, this does the same thing on the image you have. It copies the 1069 files over the install and runs Backblaze's installer. Backblaze64 is the template's default container name; substitute yours if you changed it:

U="$(docker exec Backblaze64 stat -c '%u:%g' /config)"
docker exec -u "$U" -e HOME=/config -e WINEPREFIX=/config/wine/ Backblaze64 sh -c 'cd /config/wine/dosdevices/c:/ && curl -fsSL "https://secure.backblaze.com/api/install_backblaze?file=bzinstall-win32-10.0.1.1069.exe" -o install_1069.exe && rm -rf bzextract1069 && mkdir bzextract1069 && 7z x -y -obzextract1069 install_1069.exe >/dev/null && d="$(dirname "$(find bzextract1069 -iname bzdoinstall.exe | head -1)")" && b="/config/wine/drive_c/Program Files/Backblaze" && cp "$d"/bz*.exe "$d"/*.dll "$d"/*.xml "$d"/*.gif "$d"/*.ico "$d"/*.txt "$b/" 2>/dev/null; cd "$d" && wine bzdoinstall.exe -doinstall "$(winepath -w "$d")"; echo "exit=$?"'

Then set Disable Auto-Update to true in the container template before it restarts, or the updater puts 1075 straight back.

Please don't delete Program Files\Backblaze to force a reinstall. The machine identity lives in bzinstall.xml in that directory. Without it the client treats your server as a new computer and you have to inherit your backup state, which I learned the slow way tonight. Copying over the top keeps it.

To check a pass is completing, this shows the last few pass events from the transmit log:

docker exec Backblaze64 sh -c 'cd "/config/wine/dosdevices/c:/ProgramData/Backblaze/bzdata/bzlogs/bztransmit" && grep -h -E "STARTBACKUP|Finished B reading|TransmitFilesInOneTodoFile|Lost four hour lock" "$(ls -t *.log | head -1)" | tail -8 | cut -c1-120'

Healthy is STARTBACKUP, then Finished B reading, then TransmitFilesInOneTodoFile, and no Lost four hour lock after it.

This will keep everything working alongside the most current beta, I will of course be investigating what is causing trouble with the new client and seeing if its something we can ameliorate.

If you're still having problems, let me know, and I'll investigate further.

Edited September 19Sep 19 by foz

Follow-up on the "producing file lists" problem: I've found why client 10.0.3.1075 fails under Wine, fixed it in the beta, and the beta now runs 1075 with passes completing. Stable has a fix of its own. Details and what to do below.

What 1075 does differently. Its service, bzserv, checks on each backup pass every ten seconds by opening the bztransmit process. The pass locks its own process down so that nobody can open it. On Windows, the service gets in anyway, because it runs as the system account, which holds a privilege that overrides that lock. Wine didn't honour that privilege, so the check failed, bzserv decided the pass had died, deleted the four-hour lock and started a new pass, and the old one, still running, gave up when it found its lock gone. 1069's service never does the check, which is why it always worked. So one correction to my last post: the lock file was not on disk the whole time. bzserv was deleting it, and tracing which process did that is what led to the cause.

The beta's Wine is built from source, so I've added the missing behaviour there. On my server, a 1075 pass now runs from STARTBACKUP through to TransmitFilesInOneTodoFile with no lock error, and the pass-check command from my last post shows the healthy sequence. The current :beta has that fix, Wine 11.18, a newer base image, and no client pin, so it follows Backblaze's newest client again.

Stable uses Wine from WineHQ's packages, which I want to receive the patches via inclusion in the source, so stable v10.2.2 (out today) pins the client to 10.0.1.1069 and stops the updater. If you're on stable and restarted since mid-September, you have 1075 too, and updating the container puts 1069 back on its own. No template changes needed.

If you're on the beta:

• If you did the manual rollback and set Disable Auto-Update to true: pull :beta, then either leave that setting to stay on 1069, or set it back to false and restart to move to 1075. Both work on the new beta.

• If you'd rather hold one exact version, the BACKBLAZE_VERSION variable does that and wins over the update settings. The template you installed from doesn't have it, so add it by hand with "Add another Path, Port, Variable, Label or Device" on the container's edit page. Leave it empty to let the image decide.

@anna, the lock error after an unclean shutdown is different from this one. A pass that dies without releasing its lock leaves the next passes failing to grab it until the client clears it, which it does by itself after a while. The repeating one, every pass, every minute, was 1075.

If passes still don't complete after updating, run the pass check command from my last post and paste the result, along with a diag bundle.

@foz Thank you for the fix and detailed explanation of what the cause was. Backup is fixed and working now. Is it possible that when the backblaze client updates that generates a notification event similar to the container update? This could help pinpoint similar issues in the future and combined with your new static version variable it could be useful.

@foz testing build 199: pinning to client 10.0.1.1069 resolves the lock-up issue as predicted. i can also confirm that on the same build and client 10.0.3.1075, the process runs cleanly from STARTBACKUP through TransmitFilesInOneTodoFile with no lock error. running the bz transmit grep command shows:

INFO: BZT_C13: TransmitFilesInOneTodoFile: successfully called BzEncryptWithRSAPubK

FindFirstEmptyPodParcel_DoNotBlock (processId=636) called by TransmitFilesInOneTodo

two suggestions:

• running bb-doctor on my now working install same day as lock-ups occurred, it reports:

[FAIL] the client lost its four-hour lock 6 times in the current log; no backup pass completes

the lock file is on disk and the client's own check says it is not. Client 10.0.3.1075; seen with 10.0.3.1075 under Wine.

set BACKBLAZE_VERSION=10.0.1.1069 on the container and restart: the pinned version is installed over the newer one.

i think it'd be worth tweaking this behavior so that once the issue is resolved, bb-doctor reports that afterward, just for clarity's sake? maybe that's just me though.

• other thing i wanted to report is that on my end, log timestamps don't seem to follow the docker TZ variable. i have TZ="Europe/Berlin" set, but logs are consistently 2 hours behind. no big deal, just thought to mention it.

regarding your question @rogman / @YourNekoWaifu honestly, your guess what file deletion exactly fixed it is as good as mine. i had client version 10.0.3.1075 pinned to beta build 181 which did still lock up, just as @foz predicted, but wiping most of the bzdata folder (aside from bzinstall.xml and a few other required files) and giving it a fresh start did the trick temporarily. especially now that a new build is out and given you can nuke your install don't replicate just because it worked on my end, please. the new build is safe to upgrade to :)

thank you @foz for your great work and taking the time to investigate.

@foz Thank you for adding client update notifications! Looks like in beta 207 the status tab broke (for me)

I just thought of something else. Now that you've developed this container into a full feature suite with notifications, api keys, etc. Would it be possible to have a settings export/import that pulls all the api keys, notification endpoints, various settings, etc., for easy backup/import vs copying the entire appdata folder?

Here's a tip for everyone. I had a single file that wasn't backing up or being skipped (it just didn't get looked at for some reason), and I found out if you hold ALT and click the Restore Options button on the Desktop, it will force a file scan. Might be useful for others.

Edited September 20Sep 20 by rogman
idea

New beta build with the things reported over the last day or so, and some other odds, ends and bugfixes.

@rogman, the Status tab went blank in build 207 due to a stray apostrophe in one of the notices that broke the page's script, that's been fixed. As per your request, client update notifications are in.

Warnings on the Monitor now have an X to dismiss them, one per warning, and warnings dismissed on the Status tab no longer show on the Monitor band either. Two can't be hidden, because both mean nothing is being backed up: a safety freeze, and passes losing their four-hour lock. Dismissed warnings stay listed in Settings until you press Reset warnings.

Settings now has one "Warnings and events" list in place of the Events list under Notifications and the separate Warnings box. Each warning has a Show box and, where there's a matching notification, a Notify box. Reset warnings puts dismissed warnings back without touching those choices.

On a phone, the "Preparing" and "Finishing" line in Uploading now wraps instead of pushing the panel off the screen. The Status panel title no longer sits on the top bar, and the warnings list is one card per warning rather than a stack of loose lines.

The Backup client section in Settings fills in once the first client reading arrives. It used to ask once when the page opened and then give up, so a page opened in the first minute after a restart stayed empty until you reloaded it.

@anna, on the timestamps being two hours behind: Backblaze writes its own log files in UTC, whatever TZ is set to. The dashboard converts to local time where it shows log events, and the container's own logs follow TZ, so it matters where you saw it. If it was in the raw Backblaze logs, through the Tools tab, bb-report or a shell, that's expected. If it was on a dashboard screen, in the terminal monitor or in one of the bb-* tools, tell me which one and what time it showed against the time it should have been, and I'll fix it. All the 'pretty' user-facing UX should show you everything in your local timezone (or whatever you've set your TZ to).

Pull :beta and it's all there. As usual, any issues or requests, let me know. As I mentioned previously, I've pushed a fix for the client issue to stable, but if all of this work in the beta is holding up, I'll look to do a proper release soon, as there's now quite a gap between the two now.

Good day everyone

Love to see the progress! But on the same time my client got really slow somehow.

The only problem i get with bb-doctor is drive D mismatch on BZ Folder. No idea why....

Maybe @foz you can take a look? All the time it is on Preparing File.xyz. And it only uses 2 to 3 threats - although it is idling a long time between the finishing and new start.

Something I can do?

I attached the zip - thank you!backblaze64-diag-202609211714.zip

@rogman A settings export and import function has been added to the system. It allows you to specify an encryption password to export and import API tokens and notification service strings as well. It also stores Backblaze's own configuration and will restore that to a fresh container too, but this will not store or restore the backup state itself - that remains in appdata and/or the drive .bzvol directories and must be backed up separately or you need to use the inherit state function.

@gandalf15 Thanks for the bundle. It has two issues, and the second is the one that needs to be fixed first.

Your backup has been stopped since 03:11 this morning, not just slow. At that moment, the client failed to write to its own data folder and to the scratch folder on D:, lost its four-hour lock, and no pass has run since. Those errors are between 03:01 and 03:11, which looks like the Unraid mover moving files out from under the client. Check the mover schedule, and make sure the appdata share and whatever share holds Backblaze's scratch folder are set to cache only. Then restart the container, and update to the current :beta while you're at it: it now notices a dead service or a stuck pass and restarts them, whereas build 199 sat there saying all was OK.

The slowness is the scratch folder. Backblaze's large-file path deletes and rewrites every chunk through that folder on D:, an shfs user share, before each upload child starts, and that is why only two or three threads are ever busy and "Preparing" takes so long. Point the client's temporary data drive at a cache-only share, or better a disk path, and the parent stops being the bottleneck.

On the D: warning: that one was my check's fault, and it's fixed in the current :beta. bb-doctor looked for a volume ID incorrectly, so it warned about D: on a stray token and said nothing about the drives with a real problem. Your own client log lists F: and G: as not attached, with no volume ID, which means those two are not being backed up whatever the settings window shows.

Run bb-doctor on the new build and it will say, per drive, which of four states it is in: the client knows the ID under another letter, the client has a different ID for that letter, the drive is stamped for a different computer identity, or the client has no record of the drive at all. For the middle two there is a value the client itself wrote elsewhere, and bb-doctor --fix restores it into the drive's .bzvol stamp, keeping the old stamp beside it. Restart the container afterwards so the client re-reads it. For the last one there is nothing to restore: untick and re-tick the drive in the client's settings, and expect that drive's upload to start over. Whatever it says, never delete the .bzvol folder on a drive. Backblaze's own README in there says the drive's backed-up files go with it.

While you have it running, --fix also now starts the Backblaze service if it has died, stops a pass that is stuck waiting on a lost upload child so a fresh one starts, and rewrites the supportedOS manifest if it is missing. Plain bb-doctor reports all of those without changing anything.

3 hours ago, foz said:

@rogman A settings export and import function has been added to the system. It allows you to specify an encryption password to export and import API tokens and notification service strings as well. It also stores Backblaze's own configuration and will restore that to a fresh container too, but this will not store or restore the backup state itself - that remains in appdata and/or the drive .bzvol directories and must be backed up separately or you need to use the inherit state function.

@gandalf15 Thanks for the bundle. It has two issues, and the second is the one that needs to be fixed first.

Your backup has been stopped since 03:11 this morning, not just slow. At that moment, the client failed to write to its own data folder and to the scratch folder on D:, lost its four-hour lock, and no pass has run since. Those errors are between 03:01 and 03:11, which looks like the Unraid mover moving files out from under the client. Check the mover schedule, and make sure the appdata share and whatever share holds Backblaze's scratch folder are set to cache only. Then restart the container, and update to the current :beta while you're at it: it now notices a dead service or a stuck pass and restarts them, whereas build 199 sat there saying all was OK.

The slowness is the scratch folder. Backblaze's large-file path deletes and rewrites every chunk through that folder on D:, an shfs user share, before each upload child starts, and that is why only two or three threads are ever busy and "Preparing" takes so long. Point the client's temporary data drive at a cache-only share, or better a disk path, and the parent stops being the bottleneck.

On the D: warning: that one was my check's fault, and it's fixed in the current :beta. bb-doctor looked for a volume ID incorrectly, so it warned about D: on a stray token and said nothing about the drives with a real problem. Your own client log lists F: and G: as not attached, with no volume ID, which means those two are not being backed up whatever the settings window shows.

Run bb-doctor on the new build and it will say, per drive, which of four states it is in: the client knows the ID under another letter, the client has a different ID for that letter, the drive is stamped for a different computer identity, or the client has no record of the drive at all. For the middle two there is a value the client itself wrote elsewhere, and bb-doctor --fix restores it into the drive's .bzvol stamp, keeping the old stamp beside it. Restart the container afterwards so the client re-reads it. For the last one there is nothing to restore: untick and re-tick the drive in the client's settings, and expect that drive's upload to start over. Whatever it says, never delete the .bzvol folder on a drive. Backblaze's own README in there says the drive's backed-up files go with it.

While you have it running, --fix also now starts the Backblaze service if it has died, stops a pass that is stuck waiting on a lost upload child so a fresh one starts, and rewrites the supportedOS manifest if it is missing. Plain bb-doctor reports all of those without changing anything.

Thank you - so I have multiple problems :D

Actually, D: is a cache-only drive (appdata) - I still switched it to another.

After the update though, every drive has now the same error. I guess that is not good?:

warn] D: the client knows this drive as D:, not D: (id v00c0263c5d874217562a6010214)
         the drive letter changed. Map the folder back to drive_d so it is D: again, or the
         client treats it as a new drive and starts its upload over.

Turns out it’s not a problem with your drives; it's a bug in the check I wrote, sorry.

Your client keeps one volume record for every drive that has ever been assigned a particular letter, and the check compared your stamp against the first record instead of all of them, then found it under D: anyway and printed nonsense.

The ID in that warning is the one your own client log reports as attached, so D: is fine. The fix is building now; pull :beta again in half an hour and bb-doctor should read every drive properly.

Good to know D: is cache-only. Then the write failures at 03:11 weren't the mover on that share, and the thing to look at next is where the client's own data folder lives, which is C: inside appdata, and whether anything moved or locked files under /config at that time.

3 hours ago, foz said:

Turns out it’s not a problem with your drives; it's a bug in the check I wrote, sorry.

Your client keeps one volume record for every drive that has ever been assigned a particular letter, and the check compared your stamp against the first record instead of all of them, then found it under D: anyway and printed nonsense.

The ID in that warning is the one your own client log reports as attached, so D: is fine. The fix is building now; pull :beta again in half an hour and bb-doctor should read every drive properly.

Good to know D: is cache-only. Then the write failures at 03:11 weren't the mover on that share, and the thing to look at next is where the client's own data folder lives, which is C: inside appdata, and whether anything moved or locked files under /config at that time.

Thank you - updated it.

All Errors on the drives are gone now.

I set the temp drive to C (appdate is cache only). I will see how performs now. So far it feels like it prepares a bit faster - but the chunked upload is still the same: it starts one threat that is uploaded within a few seconds - then idles up to 10 seconds - before it starts the next one.

I just wonder, why it always idles that long - this is the real game breaker sadly.

It says around 10 Chunks per /60s.

Thanks for confirming. The ten-second idle is the parent process reading the next chunk. Your log from before the change shows the client had sixteen upload slots open, and each child finished its 10 MB chunk in about three seconds, but the parent only handed out a new chunk every two seconds. Before each launch it reads the next 10 MB from the source drive, hashes it and stages it, and two seconds for 10 MB is a 5 MB/s read. However many threads you allow, the parent cannot feed them faster than it can read.

Your drives are mapped through /mnt/user, so every read goes through Unraid's shfs layer, and long sequential reads like these are what it is slowest at. Change the container's drive mappings to the disk or pool path underneath, /mnt/cache/share or /mnt/diskN/share rather than /mnt/user/share, and do the same for the temporary drive. That takes shfs out of the read path. Then watch the chunks per minute on the Monitor; the parent's cadence is what should change.

Before changing anything, pull :beta again to update to build 236 and run bb-doctor. The Source drives section now reads 64 MB from a large file on each drive and prints the speed, with how many chunks a minute the pass can stage from it. Under 20 MB/s on the drive your big files live on and the mapping should fix it. If it comes out fast, the bottleneck is somewhere else. In this case, if you could give me another diagnostic bundle, I'll investigate further.

3 hours ago, foz said:

Thanks for confirming. The ten-second idle is the parent process reading the next chunk. Your log from before the change shows the client had sixteen upload slots open, and each child finished its 10 MB chunk in about three seconds, but the parent only handed out a new chunk every two seconds. Before each launch it reads the next 10 MB from the source drive, hashes it and stages it, and two seconds for 10 MB is a 5 MB/s read. However many threads you allow, the parent cannot feed them faster than it can read.

Your drives are mapped through /mnt/user, so every read goes through Unraid's shfs layer, and long sequential reads like these are what it is slowest at. Change the container's drive mappings to the disk or pool path underneath, /mnt/cache/share or /mnt/diskN/share rather than /mnt/user/share, and do the same for the temporary drive. That takes shfs out of the read path. Then watch the chunks per minute on the Monitor; the parent's cadence is what should change.

Before changing anything, pull :beta again to update to build 236 and run bb-doctor. The Source drives section now reads 64 MB from a large file on each drive and prints the speed, with how many chunks a minute the pass can stage from it. Under 20 MB/s on the drive your big files live on and the mapping should fix it. If it comes out fast, the bottleneck is somewhere else. In this case, if you could give me another diagnostic bundle, I'll investigate further.

Now I got your point - sorry if I am a bit slow...

I did the update and I changed the /mnt/user/appdata/Backblaze64/ to /mnt/zfs_nvme_cache/appdata/Backblaze64/ for the /config.

If I need to mount every drive it will be a bit problematic - I run 15 data drives :S

Lets see if that improves it a bit. If not, I will add all the drives this weekend and restart uploading.

I will have to let it run some hours before it is through the tiny files - after that I will check and if necessary post a diagnostic.

Again a big Thank you!

Edited September 23Sep 23 by gandalf15

First of all it was indeed faster - 20MB/s it was. preparing went also faster pointing it directly to the cache and not over mnt/user/.

My estimation to complete the backup went from 360 to 130 days.

Why do I say was?

Well I decided to delete the backup - add all disks directly as a volume. It makes more sense, if a disk fails, I can replace it and use unraids parity. if another fails, I have a 2nd parity. If another one fails: I can download the failed disk backup and should get everything back.

Therefor I start from scratch now - all pointed directly not over mnt/user/...

I will report back when it went through the tiny files how it compares.

7 minutes ago, gandalf15 said:

First of all it was indeed faster - 20MB/s it was. preparing went also faster pointing it directly to the cache and not over mnt/user/.

My estimation to complete the backup went from 360 to 130 days.

Why do I say was?

Well I decided to delete the backup - add all disks directly as a volume. It makes more sense, if a disk fails, I can replace it and use unraids parity. if another fails, I have a 2nd parity. If another one fails: I can download the failed disk backup and should get everything back.

Therefor I start from scratch now - all pointed directly not over mnt/user/...

I will report back when it went through the tiny files how it compares.

Oh no, this makes sense and now you have me debating redoing it per disk also 😅

6 minutes ago, rogman said:

Oh no, this makes sense and now you have me debating redoing it per disk also 😅

Wait until I tell you how fast it is - maybe it wont be faster

I was getting 500-600 Mbs but do I want to start 16TB over. It's probably worth it to do per disk recovery

4 minutes ago, rogman said:

I was getting 500-600 Mbs but do I want to start 16TB over. It's probably worth it to do per disk recovery

I am not sure. I can only say my backup was over 16TB that I deleted (more like 30).

Still not sure if my idea makes sense to be honest. I first went by share since I told myself "if I lose a disk - I can restore the share into the share and it only downloads what was gone". This also makes sense somehow. It is maybe even better than my "per Disk idea"

In theory you should only ever have one disc die at a time. So the individual disc backup makes recovering a lot easier than figuring out what was stored on which drive. If you add a new disk in the future add a new drive letter, the downside is your limited to 24 discs. Which is never going to be an issue for me.

Since it's unlimited storage I left the share backup alone and added per drives. We'll see how long it takes, then I can always uncheck the share drive letter