25 minutes ago, rogman said:

I'm up to 350MB files right now

Strange, since I thought the bigger the files get the more chunks the more threats. I am still at 2.8GB files - eventhough set to 100 threats it only uses 7-8. well, nothing to do than wait :)

Beta 132 is up and the big thing in it is an HTTP API.

@rogman Your dashboard plugin looks awesome! I have had a dashboard plugin of my own on the roadmap, but it has sat well down the list behind the Wine work and the monitor, and I also knew that it would hit a wall: there is no sensible way for a plugin to get data out of this container. The monitor's own feed is behind the web login, its shape is whatever the page needs that week, and I would be changing it under anyone building against it. An API was always the part that mattered, and the plugin was the easy bit afterwards.

Then you posted yours, and finishing the API properly became a thing worth doing. That is what this build is: it exists so your plugin has something solid to talk to. I will still finish mine at some point, but it is the smaller job of the two and there is no hurry, after all the API is designed for others to be able to make cool stuff with.

That goes for anyone, not only rogman. If you want to build something that talks to this container, the API is there for it, and I would rather you used it than scraped a page - it should be considerably more stable this way.

Your tile polls /monitor/api/status, which sits behind whatever Web Authentication the container is set to, so it only works with that turned off. That is not a limitation of your plugin, it is that there was nothing else to point at. There is now: /api/v1/status authenticates with a key instead of the browser login, so it works whether authentication is on or off, and it is stable rather than a page's internals. Same port, no extra ports to open.

It also carries a lot more than the page feed does, in raw numbers rather than the strings the dashboard draws, so you can format for yourself: bytes and seconds rather than "19.5 TB" and "3 days".

Turning it on

It is off until you make a key, and answers 404 until then, so nothing changes for anyone who does not want it. There is a new API tab in the web interface, or from a terminal:

docker exec backblaze-personal-wine bb-apikey create --label "dashboard" --scope read

The key is shown once. Then:

curl -H "Authorization: Bearer <key>" https://<host>:<port>/api/v1/status

Permissions are granted per operation. A status display gets read and nothing else: not the names of your files, and no ability to touch the backup. If you want something that can start or pause a backup, that is a separate permission again, and starting is separate from pausing.

Full reference, every field and what it means, is in the repository at docs/api-v1.md.

What anyone might do with it

Not just dashboards. Some things it would support today:

• A Home Assistant sensor, with an automation that tells you when the backup has not completed in a week.

• A phone notification through ntfy or Gotify when files start getting skipped, which is the one that would have actually saved me something.

• A Grafana panel, if you already run one, since everything comes out as numbers.

• A cron job that starts a backup after your array finishes a parity check.

• A Stream Deck button that pauses the backup while you are gaming, and starts it again after.

• Another Unraid plugin, if someone wants a different take on the tile.

The point is that the container should not care what is on the other end. If you build something with it and hit a field that is missing or wrong, say so and I will add it.

Fixes

Multi-part totals were wrong again, in a new way: a 221 MB file with 10 MB parts showing as "22/236". The part size is fixed for a file, but one bad reading could set a row's total for good. It cannot now.

Also in: the monitor says when a backup is paused rather than reading "Uploading" with nothing moving, a key created on the command line is visible to the service rather than silently invisible, and the dashboard reuses its connection instead of opening a new one every two seconds.

@gandalf15 on threads - setting 100 and seeing 7 or 8 is expected: that setting is a ceiling, not a target, and the client only opens what it has work for. Chunks of one file go out in parallel, but the client is not queueing a hundred at once. Where you are setting threads, this must mean you have turned the auto throttle off. Try moving the slider to faster backups if you haven't already, and maybe using the loading trick to see if Backblaze is causing odd things to happen due to lack of system pressure. My own system is currently uploading ~200MB files, which get about 20 threads at 90 Mbit/s. I've set Backblaze to manual throttle, faster backups and max 30 threads.

For your 16 MB/s at 17 ms, the arithmetic that matters is per connection rather than overall. Each connection is limited to roughly its send buffer divided by the round trip, and under Wine that buffer is 64 KB, which at 17 ms is about 3.8 MB/s per thread. Eight threads gives about 30 MB/s as a ceiling, so 16 is short of it but the same order. More threads would help you more than anything else, which is the opposite of what you would expect, and it is the send buffer rather than your line. Some of this may change in the future with the work I'm doing with Wine.

As always this is beta only. Stable is unchanged at 10.2.1. Quote the build number if you report anything.

This is awesome, I will convert the plug-in to full API access tomorrow and add in some of these new fields. I really love the compact view on the monitor too instead of seeing 40 chunks listed per file it's one nice line with blocks. I'm not some wizard programmer like you either so feel free to take what I've started with on the plugin and run with it.

The home assistant alerts is brilliant and that will be setup tomorrow also. Maybe a report on how many new files were created each week and how many backed up, did any fail. A monitor itself in HA, the sky's the limit now with this update!

Update: got the plugin working with the API, and everything is butter smooth. Really liking the possibilities with having API access.

It's still in beta as I iron out some of the settings panel, but here is a peek

I've abandoned my custom web monitor as the packaged one is far superior, and there's no point in having both.

Edited August 13Aug 13 by rogman
update with api access

@foz I was curious where you find out which files failed/skipped. Mine shows 5 failed, but on the desktop > settings > issues tab, it never lists anything there.

beta+132

@gandalf15 plugin has been updated to API version now; it should show the update if you just run the check for updates. Make sure to create and plug your key in.

https://raw.githubusercontent.com/rogleete/backblaze64-unraid-dash-monitor/main/backblaze64-monitor.plg

9 hours ago, rogman said:

@gandalf15 plugin has been updated to API version now; it should show the update if you just run the check for updates. Make sure to create and plug your key in.

https://raw.githubusercontent.com/rogleete/backblaze64-unraid-dash-monitor/main/backblaze64-monitor.plg

Update and installed. Works :)
I avoid daily container updates, since it has always to restart producing file lists and that takes some time :D

Submitted the plugin for app store listing, I think I did it all right, never done it before and had to review some guides. @foz I have no issues with handing this repository or code over to you when you get around to your plug-in so you can use it as a building block. You can fork it and I can decommission the current one, I don't need to be the author but I think it has a pretty good foundation and I spent a lot of time on the settings part of it to make it look nice and work in a hopefully very user friendly way.

Every day I have some failed uploads but never anything under failed files, I'm curious if these are different things. Are failed uploads simply chunks that failed and then re upload and clear or am I missing something? This could explain why the failed files tab never shows anything if it's not the actual file failing. I'm stumped on this one.

Overall big thanks for this container, I'm on Day 10 and at almost 60% of 17TB. This would have taken months without your fixes! Note I'm up to 650MB files and getting burst of 60MB/s but whole file average of 31MB/s with 67 threads.

The one thing I cannot get to work is a button that pauses or starts the backup, it just returns an error. I've tried troubleshooting it but have gotten no where. This is using an API key with read and control options.

Edited Saturday at 03:07 AM5 days by rogman

Sorry I've been away for a bit, life likes to keep me busy!

The Issues tab won't show them, which is why the monitor reads them itself. The client keeps its own list that nothing in the GUI surfaces:

docker exec Backblaze64 sh -c 'F="/config/wine/dosdevices/c:/ProgramData/Backblaze/bzdata/bzreports/bzlist_skipped_files.txt"; echo "=== reasons ==="; cut -f2 "$F" | sort | uniq -c; echo "=== files ==="; cut -f2,3 "$F"'

Substitute your container name if it isn't Backblaze64.

With five files it's worth reading the actual reasons rather than assuming, but under this container the common one is BZ_FILE_PERMANENT_BAD_PERMISSIONS, which means the container user couldn't read the file. That points at ownership or permissions on the mounted share rather than anything Backblaze has done. Mine was 770 files in a single directory that had ended up owned by root with 0700; a chown fixed it, and they cleared on the next scan.

The thing worth knowing either way is that skipped files aren't queued and aren't retried. They're just not backed up, and until the monitor started reading that file there was nothing telling you so.

Post the reasons column and I'll tell you what yours are.

1 hour ago, foz said:

Sorry I've been away for a bit, life likes to keep me busy!

The Issues tab won't show them, which is why the monitor reads them itself. The client keeps its own list that nothing in the GUI surfaces:

docker exec Backblaze64 sh -c 'F="/config/wine/dosdevices/c:/ProgramData/Backblaze/bzdata/bzreports/bzlist_skipped_files.txt"; echo "=== reasons ==="; cut -f2 "$F" | sort | uniq -c; echo "=== files ==="; cut -f2,3 "$F"'

Substitute your container name if it isn't Backblaze64.

With five files it's worth reading the actual reasons rather than assuming, but under this container the common one is BZ_FILE_PERMANENT_BAD_PERMISSIONS, which means the container user couldn't read the file. That points at ownership or permissions on the mounted share rather than anything Backblaze has done. Mine was 770 files in a single directory that had ended up owned by root with 0700; a chown fixed it, and they cleared on the next scan.

The thing worth knowing either way is that skipped files aren't queued and aren't retried. They're just not backed up, and until the monitor started reading that file there was nothing telling you so.

Post the reasons column and I'll tell you what yours are.

I will check and follow up but quick question... This sounds like a great feature to add to the web GUI if possible. It could be a fourth tab "Skipped Files" and list them with the reasons. Not sure without looking if it's easily doable or something that could be integrated into the API also?

Update:

=== reasons ===

1 # SkippedFilesReportStarted: 2026-08-15 04:07:29

=== files ===

# SkippedFilesReportStarted: 2026-08-15 04:07:29

Update: checked today, and current stats are

Ran the terminal script and still get the exact same output as above

=== reasons ===

1

1 # SkippedFilesReportStarted: 2026-08-16 13:26:37

=== files ===

# SkippedFilesReportStarted: 2026-08-16 13:26:37

opened the txt file directly in file browser

Edited Sunday at 06:35 PM3 days by rogman
Update results, another update

dashboard plugin is released in the App Store and in its final form (unless I can get pause/start) button to work. Must use API with read and read:files permissions to show the current file

Day 15 and I'm almost done, would have been another 200+ days without these amazing patches from Foz! You're a lifesaver!