rogman

@foz I'm not seeing any errors but when I switched to per disc backup, one of my drives N: doesn't show up in the status tab and says nothing is marked for backup but it's already backed it up. Doctor scan reports nothing selected for backup. Update: Installed beta 269, and the issue appears resolved now.

The individual disc backup is now complete! I added the cache drive so it backs up daily before mover relocates them to the array discs. Can't stress often enough how thankful I am for what you've created for us Foz! I do feel like it will be slightly easier to manage a bad disk replacement with this approach instead of figuring out what was on the disc.

Update on switching to direct drives instead of array pool. It got to 85% and when I woke up today it was back down to 20%. No idea what happened but we are back a few days of deduplication checks now 😮‍💨

Folder depth is set to 4 and now getting measurements on all drives. Nice update with the memory reporting

What's puzzling is I've never seen such high RAM usage until I changed to the single drives and it's checking each file for deduplication. The container says it's using 35GB, but my Unraid dashboard says I'm only using (17.5GB total on system). Unraid dash vs container stats

@foz, not an issue but curious how many levels the scanner looks through for the read speed check? I'm trying to find in in github code just haven't tracked it down yet. [ ok ] M: /drive_m readable, 2 top-level entries sampled M: read speed not measured: no file over 64 MB within three levels of /drive_mLast question: I always get a warning for having no swap. I have a swap drive set in the client, but I guess it never has to roll over to use it, so it generates a warning? I don't think it's an issue, but it always makes me think something is wrong when the scan outputs a warning, Host resources [ ok ] 62 GB host RAM [warn] no swap - a memory peak becomes an out-of-memory kill, which is what leaves the stale lock behind [ ok ] process table healthy (0 zombies)

The only downside I see is that it will not back up a file until Mover moves it from the cache to the array disk. Mine is weekly so not that big of an issue. It's chomping through these files and marking each one as "already backed up" but oddly it's using 35GB RAM for the process; I've never seen it over 7GB.

So it appears that backblaze is smart enough to know that the files have already been uploaded previously even under a different drive letter and it's only scanning them. This should go pretty quick

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

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.

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

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

@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.

@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.

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

Any idea what resolved it?

so the file is named "lock_bzfileid_4_hour_lock.lck" and it doesn't exist in any of the appdata backups (confirmed restarting container removes this file). I did notice that it created the file by itself after the container starts but very soon after deletes the file. I tried creating one manually but now the log says -- 1464 - BzTransmitUtils.cpp:9401 [GrabFourHourLock()] ERROR: Failed to grab fourHourLock lock, lock file "\\?\C:\f051f04fada2\e24b5ef1a7f8\634395f2b58c\607d14790a24\2a2f7dfe63bf.lck" 2026-09-15 22:39:15.532 1464 - DoBackupPass.cpp:1669 [FailBackupOperationOnNonEmptyErrorStr()] ERROR: Failure while processing -prepare_bzcombs: Failed to get four hour lock

I will check on that. I didn't do the restore until after the issue, it was my last attempt to fix the issue

. I went as far as a restore from daily app data backup from 3 days ago. Still cycles and sticks on producing file lists

@foz I'm stumped on this one, my backup hasn't uploaded in two days. It will cycle between idle / preparing / producing file list. No errors at all just a growing list of files waiting for backup. backblaze64-diag-202609151230.zip

You're almost at the point the wine web GUI will be obsolete and everything can be done on the Web pages. I truly thought there was nothing else you could think of and every update it's fun to see what's changed. The push update comes in that an update was installed and it's like Christmas opening to see 🤣 Edit: reading your changes answered my question about the Z: mapping, thank you! I'm curious if others have had that issue of removing or changing mapped drives and they are removed from the container settings but the symlinks still exist in the app data folder, can that be fixed by running bb-doctor --fix and it safely remove those non used links?

@foz Got a question for you and a tip for others. I removed a drive map from my Docker template because I no longer needed that folder backed up. I ran bb-doctor, and it said I had an unmapped drive that showed as a warning. I couldn't see this drive because I removed it from the template. However, I looked into the AppData folder structure and found where drives are mapped and simply deleted that old one from the list, and the warning cleared. It was found here That's the tip for everyone. My question is: I never mapped the Z: drive, and I don't remember when I first noticed it. It is not a folder I'm backing up, but when you look in it, you see the container file structure. Is it safe to delete this folder from the \dosdevices\ folder, or is it supposed to be there? The folder shows root as owner

@DevanteWeary If you are synced and backing up, it should be safe to switch to beta. You can run bb-doctor from the Tools tab when you're up and see if any warnings/errors show up.

I was going to look into bbnotify.py, and when I pulled it up, it said just modified. Saw the Pushbullet info inside and ran to check for an update Great feature adding the manual entry field. At this point, it's not what this container does, but rather what it does not do?! I can't think of anything else. 10/10

@foz You are amazing, it's working now!