Thanks @foz for this - I needed somewhere to backup by 50TB of Data.

I am currently running the beta branch and it has improved the visible speeds as before it kept looking like it was getting stuck but Unifi says that it is transferring data all be it at 8mbs.....

But now Its flying through my data at record speed but nothing is being uploaded as confirmed by unifi not detecting any traffic and the bb-monitor thing saying its only uploaded 3

I am going to leave it 24 hours to see if its just backblaze being weird and its just confirming if its backed up or not

Again thank you for your hard work!

The bb-monitor is a great addition! Here is what I'm seeing

edit: I do notice occasionally it will stick at 99% and say "finishing ...."

Edited August 5Aug 5 by rogman

@gandalf15 No problem, if its the same account and an inherited state, it should be able to figure our what is already uploaded from hashing.

@YourNekoWaifu That sounds like deduplication and or hash matching - if it still feels off, feel free to run bb-report and send me your logs, I can take a look.

@rogman Looking good - I'm currently getting my older, slower speeds for some reason, but after a lot of bug hunting, I think there's some trouble between me and Backblaze, Telia's transatlantic link is showing congestion and loads of retransmission, so hopefully my own low numbers are not related to any of the code.

There's movement on the Wine side of things, which may well be good in terms of overall future quality but probably not so great in terms of speedy deployment, I will update on this later.

I got an html .py file working with multiple color themes!

Drop it in root appdata folder than add this to container template

run this in unraid terminal

docker exec -d Backblaze64 python3 /usr/local/bin/bb-monitor-web.py --port 8099

edit: update web to show total backup status and eta. details in page tab too

@foz feel free to use this if it helps!

Edit: If you want to try this out, download the bb-monitor-web.py file and the 95-start-bb-monitor-web.sh file and put them in your Backblaze64 appdata root folder

Then add two variables to your container.

#1 is a Port: 8099 for the host and 8099 for container

#2 is a Path: /etc/cont-init.d/95-start-bb-monitor-web.sh for the container value and /mnt/cache/appdata/Backblaze64/95-start-bb-monitor-web.sh for the host value

The first one opens the port on which the web-based monitor is viewed. The second runs the script, which turns on the web monitor when the container starts

Edit: you can also view the site with /?compact=1 to get a minimal interface, which can be used on a homepage setup like Homarr, etc

95-start-bb-monitor-web.sh bb-monitor-web.py

Edited August 9Aug 9 by rogman

OK, a few updates: two releases today. The stable one is a pair of fixes. The beta one roughly triples my upload speed.

v10.2.1 fixes some little bugs: bb-monitor showed completion times in UTC while its own clock showed local time, so if you'd set TZ, the two disagreed by an hour in the same panel. Backblaze stamps its own logs in UTC no matter what the container's timezone is, and I'd been passing those straight through.

Every image now also stamps a build number. The :beta tag is mutable, so I figured it would become useful to know which beta. bb-version prints the number, and the monitor shows it in the corner. If you report anything, quote it so I know what you're running.

Beta build 103 carries a second Wine patch. On my connection, it takes aggregate upload from around 13 Mbit/s to 41. First, a correction. When I posted about the writability fix I said that once Wine reported writability correctly, the speed should all be there. I've now measured that properly, and I was wrong. Same host, same thread count, same files, ten-minute windows, alternating builds: my patch alone landed at 13.0, 13.9 and 13.9 Mbit/s across three runs, and with the second patch it went to 40.9.

Wine tells an application a socket is writable exactly once and then latches that fact. While the latch is set, it stops asking the kernel to watch the socket for writability at all. If the application learns "not writable" from a poll rather than from a send that failed, it then waits for a notification that can never arrive, because nothing is watching any more. It sleeps until its own timeout expires, every single time around the loop. My first patch fixed the answer Wine gives to select(). It never touched the notification path, and it turns out Backblaze's client uses both: I counted 44 WSAEventSelect and 46 select calls in a single short capture. So I was fixing one of the two paths it depends on, and not the one that governs its throughput.

This second patch is temporary. It clears that latch when a poll observes that the socket cannot accept a send. Real Windows does not do that. I tested it on Server 2022 and 2025 before writing any of this, and Windows only re-arms after a send actually fails. So the patch makes Wine diverge from Windows on purpose, which is why it is in the beta and not in the stable images, and why I am not submitting it upstream. CI now fails the build if a patched Wine ever turns up in a stable image, so that separation is enforced rather than something I have to remember.

The other similar design from the upstream of this project is a reasonable piece of work which found a real defect that mine did not address. Where mine differs is the trigger. Theirs infers "cannot accept a send" from the absence of POLLOUT, and Linux withholds POLLOUT well before the buffer is actually full, so that fires in cases where a send would have gone through fine. Mine asks the kernel directly whether it would accept the data. It also drops a redundant reselect, because the function already reselects every socket before it returns. Narrower trigger, one fewer moving part. Both of us are papering over the same gap, though, and neither version belongs upstream in wine as written.

The proper fix is a larger redesign that I'm working through over at WineHQ now. My measurements turned up some things that are not yet handled, so that discussion has somewhere useful to go. When it lands, the container patches can disappear and the stable images will operate as expected.

One other thing turned up along the way, and it applies to whichever build you run. The Backblaze client asks for a 64 KB socket send buffer itself. At my round-trip time that caps a single connection near 4 Mbit/s, no matter how clean your line is, and no patch changes it, because it is the client's own setting, and a Windows machine would hit exactly the same ceiling. What that means in practice: Backblaze scales by connection count, not by connection speed. If you are on a fast line and a long path, your thread count is the lever that matters. Mine is on 30. Be careful with this setting as wine can get funny with lots of threads.

Big thanks to @rogman for his initial feature request for bb-monitor to have a web version, and then the python build that followed, because the console has a habit of dying and he wanted to watch a session overnight. He also added overall backup progress with an ETA, and a theme picker, neither of which had occurred to me. I have taken his concept and I am building it into the container proper: it will be served through the existing web UI on port 5800 rather than needing a second port, which means it will inherit whatever authentication and HTTPS you have already configured instead of exposing your file names to anyone on your LAN. The plan will be a tabbed view so the VNC desktop and the monitor sit side by side, with a settings dialog for the themes and whatever else accumulates. That is going into the 10.3 line, and it will appear in a beta before it goes stable. Thank you rogman, this is a better project for it. I've also noted the 99% 'stickiness' - I suspect this is where the client is waiting for confirmation of a successful upload, while I've been poking around, I've been making lots of notes and believe that there are numerous improvements and features that can be teased out of the client.

As always, if you have an idea, an itch, or something that annoys you about this container, please say so. It does not need to be code. "This number is confusing" and "why does it do that" are both useful, and rogman's started as a question about a terminal window closing. Update or switch to the beta channel if you want to try the speed patch. Stable is unchanged in behaviour beyond the two fixes above.

Love to see how much happened since I left for a short holiday!

Here is my feedback: First Beta built: 8 to 10 MB/s

New released built from today (also Beta): 12-18 MB/s

Numbers are from built in bb-Monitor.

Speed increased indeed - the Threats count is usually at 6 ish, although I set it to 100. I dont know if the files are still to tiny (all around 2.2 GB according to bb-Monitor). it is definitly faster than before. For information: Running 10gbit line to the router, which is also 10gbit.

Also looking forward to even more improvements!

@foz Thanks so much for finding my web-based viewer useful. I only took what you had and added to it. I updated the file about 10x yesterday, so I don't know which version you looked at. My final edit is the final version, which fixed the time issue for recently uploaded files, added a files remaining part, and shows how long it's been running in the top bar. Overall, what you are doing is amazing work! I am definately getting faster speeds now at about 20MBs, but I'm also now transferring files over 200MB so they can split into 20+ threads.

A quick update: the upstream work has moved on rather than stalled. I have been going back and forth with the Wine maintainers about how the proper fix should be built, and I have just sent them a long reply conceding most of their objections to my original approach and asking them to pick the design. That is the right order. The workaround in the beta stays until whatever they choose lands, and then it goes.

While digging into that I found something else, and I want to be careful about it because I have not finished checking. There is a Windows call that asks the system how much data a connection can usefully hold in flight, and Windows works that out per connection. Wine answers it with a fixed 64 KB every time, and the Backblaze client appears to size its send buffer from that answer. If that holds up it would put a ceiling on each connection that gets worse the further you are from the datacentre, and it would be a separate fix from the one under discussion. I need to measure what real Windows returns before I say anything stronger than that, so treat it as a lead rather than a result for now.

@gandalf15 thank you, that is exactly the kind of before-and-after I was hoping for. 8 to 10 MB/s up to 12 to 18 MB/s is a bigger jump than I expected to see reported.

On the thread count: that number is Backblaze's decision, not the container's. Your setting is an upper bound, and the client picks how many to actually run based on what it has queued and how the transfers are going. I see it swing between 3 and 17 here across a single evening on the same settings, so 6 is not necessarily a problem.

What your numbers do tell me is that you are close to Backblaze in network terms. Six threads at 12 to 18 MB/s is roughly 16 to 24 Mbit/s per connection, and per-connection throughput is governed by the send buffer divided by round-trip time. To get that per thread you must have a fairly short path to their datacentre. Mine is 144 ms and I see about a fifth of that per thread. So your 10 gigabit line is not the limiting factor and neither is file size at 2.2 GB. If the thread count climbs on its own, expect the total to climb with it.

@rogman the version I have now is your final one. Compact mode was a good call, I'm looking to build this out further into an API so all sorts of consumers will be able to fetch status and other information on backups.

20 MB/s on 200 MB files sounds right for what the client does with larger files. It splits them further and runs more threads, which is the lever that actually moves the total.

More when I have the measurements. Thanks both.

I updated the web monitor with the beta build code, and I tried to add a spot that pings the upload server assigned to the account, but the upload servers aren't pingable from what I found. It tries to ping the server (ie pod-000-0666-00.backblaze.com) and fails but what it can do is ping the IP to the server it is activiely uploading to. If you hover over the ping ms, it will display the current IP, and if it can't resolve it, it falls back to backblaze.com. However, it does show the assigned server in the bottom bar. Is this useful? Probably not. Also made some security improvements

bb-monitor-web.py

Edited August 9Aug 9 by rogman

Ok, this is probably the final version I will make, but it has a lot of improvements.

Now only viewed over HTTPS with an auto-generated self-signed cert.

Prompts for a password on first view, which stores the password via a salted PBKDF2-SHA256 hash.

Here are the details and full instructions to set up, since it's a few posts up.

- - - - - - - - -

Backblaze 64 Upload Monitor

A live web dashboard for Backblaze64's own bb-monitor console tool.

What it does

• Live upload stats every 2 seconds — threads, transfer rate, chunk rate, session total, and connection state

• Overall backup progress (bytes and files done vs. total selected), with an ETA smoothed over your last 10 completed transfers

• Per-file progress bars for uploads currently in flight, and a log of recently completed transfers

• Memory and swap usage gauges, dashboard uptime, and a files-remaining counter

• Experimental TCP-connect latency check, preferring your live upload connection over DNS when one's active

• 13 color themes, remembered across visits, plus a compact view (?compact=1) for embedding in a dashboard tile

Security

• Your password is never stored — only a salted PBKDF2-SHA256 hash, checked with a constant-time comparison

• All traffic is served over HTTPS via a self-signed certificate, generated once and reused across restarts

• Every page and the API require that password once one has been set

• Filenames and other displayed data are HTML-escaped before rendering, preventing injected content via unusual filenames

• Forgot the password? Run in terminaldocker exec Backblaze64 python3 /config/bb-monitor-web.py --reset-password

- - - - - - - - - -

Setup:

Download the two files and place them in your root /Backblaze64/ appdata folder

Create two entries in the docker template

• #1 is a Port: 8098 for the host and 8098 for the container

• #2 is a Path: /etc/cont-init.d/95-start-bb-monitor-web.sh for the container value and /mnt/cache/appdata/Backblaze64/95-start-bb-monitor-web.sh for the host value

• The first one opens the port on which the web-based monitor is viewed. The second runs the script, which turns on the web monitor when the container starts

When you run it the first time, it creates a folder /appdata/Backblaze64/bb-mon-cred/ that stores the salted password and the self-signed HTTPS cert and a readme file

Here is what the readme file says:

# bb-monitor-web -- credentials & security notes

This folder holds everything the dashboard's login and HTTPS depend on.

It lives under /config specifically so it survives container restarts

and recreates -- don't move it outside /config, or you'll lose the

password and cert on every restart and have to redo setup each time.

## What's in here

- creds.txt -- password hash (see "How the password is protected" below)

- cert.pem -- the self-signed HTTPS certificate (public)

- key.pem -- the private key for that certificate (chmod 600)

- README.md -- this file

## How the password is protected

- The password itself is never written to disk anywhere, in any form.

- Only a salted PBKDF2-SHA256 hash (200,000 iterations) is stored in

creds.txt, as "salt:hash" -- both hex-encoded.

- Checking a login attempt uses a constant-time comparison

(hmac.compare_digest), so the check can't be timing-attacked to guess

the password one byte at a time.

- creds.txt and key.pem are both saved chmod 600 -- readable only by

the user the dashboard runs as.

## How access is gated

- Every page and the /api/status endpoint require HTTP Basic Auth once

a password has been set. The username you enter is ignored --

only the password is checked.

- Before any password is set, every request redirects to /setup, which

is the only reachable page. Once a password is set, /setup refuses

to run again (403) -- it can't be used to reset or hijack an

already-configured install. Use the reset command below instead.

- All traffic is HTTPS-only, using the self-signed certificate in this

folder. It's generated once and reused across restarts, so your

browser only needs to click through the "not trusted" warning the

first time, not on every visit -- it's not a fresh untrusted cert

each boot.

- Filenames and other Backblaze-derived data shown on the dashboard are

HTML-escaped before being displayed, so a file with an unusual name

can't inject a live tag into the page.

## If you forget the password

Run this from an Unraid host terminal (no need to stop the running

dashboard first -- it re-checks for credentials on every request):

docker exec Backblaze64 python3 /config/bb-monitor-web.py --reset-password

That deletes creds.txt. The very next page load will show the /setup

form again to create a new password. The HTTPS certificate is

untouched by this -- you won't get a fresh browser trust warning.

Hopefully some of you find this useful; it was fun to help create and again undoable without working with what @foz had already created!

95-start-bb-monitor-web.sh bb-monitor-web.py

Edited August 10Aug 10 by rogman
formatting, updated dark theme, typo in about section, updated ping to format used by Foz, updated about with Foz's dynamic build info, merged in Foz's mobile formatting. uses existing containers certs, port change, GB/TB/PB sizing

Beta build 107 is up, and my implementation of the web dashboard is now part of the container.

Click the WebUI button and you land on a tabbed page: the Wine desktop via VNC on one tab, the upload monitor on the other. Switching between them does not drop your VNC session, and the monitor tab does not start polling until you open it. It is on the port you already use, so there is no second port to map and nothing new exposed on your LAN.

The terminal bb-monitor has caught up too. It now has the same overall progress and ETA, files remaining, uptime, the assigned upload server, the sparkline, and a settings dialog with the same thirteen themes. Press s to open it, Tab moves between Preferences and About. Both monitors read from one shared data layer now, so a feature will appear in both rather than one trailing the other.

docker pull ghcr.io/iamfoz/backblaze-personal-wine:beta and you are on 107 (or if already running, you can just update in Unraid). It'll make its way to stable shortly, assuming we don't find any bugs.

@rogman The HTML escaping you added was a great catch. File names went into the page unescaped, so a file whose name contained markup could inject it into the dashboard. Fixed in this beta, and credited in the changelog.

On the ping work, where you said "Is this useful? Probably not." - it is. Per-connection throughput is the send buffer divided by the round-trip time, so RTT is the other half of the ceiling I have been going on about. With the 64 KB buffer, my 149 ms path works out at about 3.5 Mbit/s per connection, which is why thread count moves my numbers and line speed does not. The dashboard now shows RTT next to the transfer rate for that reason.

I did rework how it is measured though; rather than opening a connection to time it, it reads the figure the kernel already keeps. Every established connection carries a smoothed round-trip time, and there is an interface that exposes it for sockets the process does not own. There is no traffic at all when nothing is uploading, and the number describes the actual upload connections rather than a separate probe alongside them. Your instinct to prefer the live upload connection over a hostname was the right one and I kept it.

On the password and self-signed certificate: for a standalone script those were the correct call, and doing them properly with PBKDF2 and a constant-time comparison is good. The container does it differently only because it can; serving through the existing web interface means it inherits whatever WEB_AUTHENTICATION and SECURE_CONNECTION you already have, so there is one set of credentials rather than two.

No change on the Wine front since Friday. The maintainers have my reply and I am waiting. The 64 KB lead is still a lead: I have now confirmed the arithmetic on my own hardware, but I still have not measured what a real Windows box reports, and until I do it stays a suspicion rather than a finding.

The dashboard works on a phone, incidentally. I hadn't planned on working on it, but it turned out to be about an hour's work once the layout was already there.

As ever: if something in this is confusing, wrong, or annoying, say so. Quote the build number from the corner of the monitor when you do.

New Beta up and running.

I like the new monitor - its amazing.

Only one simple error:

Backup: 19973.2 GB/257524.9 GB

shows like this - which obviously cuts off the number.

Beside that all running normal. ETA: 171 d - have some time for more tests :D

@foz My monitor tab just stays stuck on this / beta+107,  SECURE_CONNECTION: 1, VNC_PASSWORD: Blank (if these matter)

small request, I was reviewing your bb-web code and could you please update the "dark" theme to these colors if possible (I had changed them because it wasn't truly dark, it was grey and it's my favorite theme)

html[data-theme="dark"]{

--bg:#000000; --panel:#1e1e1e; --border:#6a9fd8; --title:#7fb2e5;

--text:#d7e6ff; --hi-bg:#d4d4d4; --hi-fg:#161616;

--good:#3ddc6b; --warn:#ffd23d; --bad:#ff5a5a;

--track-bg:#0c0c0c; --track-border:#3a3a3a; --scanline:0;

Edited August 9Aug 9 by rogman
added build info

You can see where I changed from the stable branch to the beta branch almost in real time.

You're definitely on to something!

Beta 110 is up with two fixes from this thread.

@gandalf15 the clipped number was due to the size formatter stopping at gigabytes, so your 251 TB backup came out as "257524.9 GB" and ran off the end of the label. It goes up to petabytes now, so you should see "19.5 TB/251.5 TB" instead. Thanks for the screenshot.

The ETA of 171 days is doing what it should, incidentally. It weights your last ten completed transfers rather than the live sample, so it will settle as more finish. A first pass over a quarter of a petabyte really does take that long.

@rogman the dark theme is now your requested values, black rather than the dark grey I had. You were right that it was not really dark.

On the monitor tab sticking on "Waiting for the monitor service", I have a suspicion and one thing I would like you to check. Your earlier setup ran your script on port 8099 through a cont-init.d entry in the container template. The built-in service uses that same port, and cont-init.d runs before services start, so if those entries are still in your template your script takes 8099 first, the built-in one cannot bind, and nginx has nothing to proxy to. That page is what you get when the service is not listening, and it will sit there forever because it keeps polling and never gets an answer.

Run this and paste the output:

docker exec Backblaze64 sh -c 'pgrep -af bb-monitor-web; ss -ltnp 2>/dev/null | grep 8099'

If it shows something pointing at /config/bb-monitor-web.py, that is it, and the fix is removing the old Port and Path entries from your template. The container provides both now, so nothing is lost by dropping them.

If that is not it, this runs the same code in the foreground so any startup error shows up instead of disappearing into the supervisor:

docker exec Backblaze64 /usr/local/bin/bb-monitor-web --dump-rtt

I do not think SECURE_CONNECTION is involved. nginx talks to the service over plain HTTP inside the container regardless of what it serves to you, so TLS should not reach that far.

@DayspringGaming looking good, there is clearly an issue with the data paths in Wine that need sorting out, hopefully it won't be too long before I get a shape of the code that needs changing and I can submit something that fixes it. My original patches were designed to be small incisions; the change that might be coming will be a much bigger piece of work. Still, while that plays out, everyone can get good network speeds from the beta.

@foz I should have seen that but didn't check. It was the port. I just changed my custom one to 8098, and the built-in fired right up! Thanks for pointing me in the right direction! You didn't have to shout me out in the about; all the props go to you and the immeasurable hard work you have poured into this project to help the community out! You are a legend!!

@gandalf15 Man, I thought my 17TB was a lot....holy smokes :)

There's probably only one or two of you out there, but if you had installed my web-based viewer before Foz published the baked-in web viewer, it would break his. I updated the files so that it uses a different port and updated the instructions in case there is any use case for it, but I think what is packaged in now is the right approach. If you do use it, it will now utilize the container's existing HTTPS certificates instead of creating new ones and includes all the fixes and extra features Foz rolled out, like RTT ping time, GB/TB/PB sizing, and mobile browser formatting.

Got bored, started messing around with layouts for use with Homarr

Cards

Trader

Ascii

Hud

Newspaper

Thanks - updated.

I had this backup completed at one point in time with the virtio VM- sadly I did not inherit it and restarted once the unplugged problem was fixxed...

I will let it run - it will finish eventually :)

Thanks for the updates!

2 minutes ago, gandalf15 said:

Thanks - updated.

I had this backup completed at one point in time with the virtio VM- sadly I did not inherit it and restarted once the unplugged problem was fixxed...

I will let it run - it will finish eventually :)

Thanks for the updates!

You would only need them to send you 32 hdd's at $300 a pop to full restore

1 minute ago, rogman said:

You would only need them to send you 32 hdd's at $300 a pop to full restore

I made a test with the restore software - it works actually pretty well. I restored for a test one dir without problem. I set it up in a way that I can restore dir wise :) It ran pretty fast. But I get your point though

Beta 127 is up. There has been a few changes since 110, most of it from going through the files the Backblaze client keeps in bzdata to see what it already knows and does not show you.

The monitor reports what the client is doing rather than guessing from which processes are running. The client writes its own status out, and it turns out the field I was reading first (cur_state) says "transmitting" no matter what, including while it is building file lists. The useful one names the file in hand, and for a large file it says which phase it is in: preparing, part 12 of 21, then finishing. A file-list scan now shows a real percentage, directories indexed out of the total, with a running count of files found, rather than just the word "Scanning".

Chunked files can now be shown in a compact view. Every chunk of the large file being split has an index, a byte offset and a SHA-1 on disk, and that same SHA-1 turns up in each transfer's own record, so a thread can be matched to the exact chunk it is carrying. Chunks fill in where they actually sit in the file, out of order, with the ones in flight marked differently. Chunks that finished before you opened the monitor stay unmarked, because there is no way to tell those from ones not yet started. It is off by default, next to the theme picker.

Files Backblaze has given up on are now listed. The client keeps a list of files it has skipped with a reason, and it neither queues nor retries them, so nothing else tells you they are unprotected. When I turned this on against my own machine it found 770 skipped files. All of them were in one directory that had ended up owned by root with 0700 permissions, so the container user could not read it. About 28 GB I believed was backed up and was not. Under this container, the cause is nearly always ownership of the mounted source rather than anything Backblaze has done, and it is invisible until something asks for the list. If you run nothing else from this build, look at that number.

A first backup is still working through the set now says so, with how long it has been going and how far it has got, instead of looking like something is stuck. Mine reads day 67 and 12.9%. There is no "initial backup finished" flag anywhere, so this is worked out from how much of the set has never been sent.

Also in: the count of uploads for the day with failures broken out, the bytes compression has saved, and Backblaze's own measured throughput figure. It reports about 3.5 Mbit/s per connection for files over a megabyte here, and 244 kbit/s for small ones, which is a much worse case dominated by a round trip per file rather than by the socket buffer.

The web dashboard is mobile-friendly now, so it is usable from a phone.

Fixes

The "21/6594" part counts are fixed. The count was coming from a field that describes the part a thread happens to be carrying rather than the file's part size, and small readings turned filesize-divided-by-part into tens of thousands. It reads the configured part size instead, which is constant for a file. A total that wrong also meant the record never reached completion, so every later upload of the same file kept piling into it.

The compact chunk view showed a film at 0/21 while the client was busy producing file lists, for the same reason: the directory describing the large file being split is not cleared when that file completes. It also drew one row per thread rather than per file, so a dozen threads on one film gave a dozen identical rows.

File names with an apostrophe or an ampersand were coming out as raw XML, so "Mike Judge's" instead of an apostrophe. And the compact view toggle did nothing, because the strip it was meant to control was being drawn regardless of the setting.

Small files were never appearing in Recently Completed. They are gone before a poll can catch a thread carrying one, and Backblaze pushes them in bundles rather than one at a time, so there is no per-file record of them in the log either. They are now taken from the client naming each one as it works through them, and listed without a thread, size or rate because none of those exist for a file handled that way. That tells you the client moved on from the file, not that a transfer was confirmed.

@rogman Those Homarr layouts look cool, having some templates for various dashboards might be nice - something to go on the backlog.

Glad the 8099 clash turned out to be it, and good call moving yours to 8098 and writing up the conflict for anyone else who had the earlier version installed. On the credit: it is staying where it is - the web dashboard is in the container because of your initial idea, I think its important to show credit where due!

@gandalf15 Thanks for the restore test info, data is always useful!

As always, everything above is beta only. Stable is unchanged at 10.2.1 and stays there until this has had a decent run. Quote the build number if you report anything, bottom right of both monitors and from bb-version.

Got this up and running. The only issue is that it hooks into bb-monitor-web.py to get the data, not the native container. I'm trying to fix that so it works for everyone.

Now working on the native Beta install; no extra files or anything needed.

Here is the collapsed style

Settings panels

You can install this by going to Plugins > Install Plugin >

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

--Click Install

This is not published in the app store, so you have to install manually via the URL.

If I can get it working with the untouched container and figure out how to make it auto-refresh, it may be worth publishing.

Edited August 11Aug 11 by rogman
auto-refresh working / fully working on default container install - no extra files or config required

11 hours ago, rogman said:

Got this up and running. The only issue is that it hooks into bb-monitor-web.py to get the data, not the native container. I'm trying to fix that so it works for everyone.

Now working on the native Beta install; no extra files or anything needed.

Here is the collapsed style

Settings panels

You can install this by going to Plugins > Install Plugin >

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

--Click Install

This is not published in the app store, so you have to install manually via the URL.

If I can get it working with the untouched container and figure out how to make it auto-refresh, it may be worth publishing.

Also that is amazing - installed! Thank you very much!

May I ask you, what size of files you get? I still never get over 8 threats somehow. Often the file hangs at 99% and it creates downtime. My RTT is 17ms - server should be fast enough - but still it "only" uses 16 MB/s

22 minutes ago, gandalf15 said:

Also that is amazing - installed! Thank you very much!

May I ask you, what size of files you get? I still never get over 8 threats somehow. Often the file hangs at 99% and it creates downtime. My RTT is 17ms - server should be fast enough - but still it "only" uses 16 MB/s

I'm up to 350MB files right now. I also set threads to 75 in settings (not on auto)

I also noticed my setup has never used a swap drive; it all runs in RAM. I don't know if that's just because of the amount of free RAM available and if that factors into threads at all.

Edited August 11Aug 11 by rogman
threads