Hi all,

This is the support thread for Backblaze 64 (iamfoz/backblaze-64-personal-wine-container).

What it is

Backblaze 64 runs the 64-bit Backblaze Personal Backup 10.x Windows client under Wine, packaged in a jlesage GUI base image so you get a web/VNC desktop in your browser. It's a fork of @JonathanTreffler's Backblaze Personal Wine container, re-engineered for the 10.x client (which dropped 32-bit and pre-Windows 10 support). It downloads the official Backblaze client from Backblaze's own servers at install time - no Backblaze software is redistributed in the image. I've done no proper benchmarking, but the slimmed-down machine template seems snappier running on my Unraid VM. I had been reliant on the upstream project and grew concerned when there was no movement since last December to resolve the issues with the new client. I am actively using this project myself and plan to ensure it continues to operate properly as new versions of the client are released.

Note: This project is not affiliated with Backblaze, Inc. Please check that this use complies with the Backblaze Terms of Service before relying on it.

Who it's for

Unraid (and other Docker) users who already pay for Backblaze Personal Backup and want to back up their array/shares with the unlimited Personal Backup plan, instead of running it on a separate Windows/Mac machine. Some tinkering may be required if you have a complex permissions setup - this is a community volunteer project, not a commercial product. My own use case is I moved several USB-attached drives connected to a Mac Mini into a JBOD USB enclosure and then used Unraid to manage the file storage. The previous system was being backed up by Backblaze and there has been no material change in the data or volume being backed up.

Installing on Unraid

Option A: Community Applications (once listed): open the Apps tab, search for Backblaze (it appears as Backblaze64), and click install.

Option B: Add the template URL manually: on the Docker tab, click Add Container, and paste this into the Template field:

https://raw.githubusercontent.com/iamfoz/backblaze-64-personal-wine-container/main/templates/backblaze-personal-backup.xml

Key settings in the template:

• Config (/config) → /mnt/user/appdata/Backblaze64 - persistent Wine prefix + Backblaze config. Must survive restarts.

• Backup Source (Drive D) (/drive_d) → map the host path you want to back up. Must be read-write - Backblaze writes a .bzvol folder into each drive's root to track it. Repeat with /drive_e, /drive_f, etc. for more locations.

• UID/GID default to 99 / 100 (nobody/users), which matches Unraid user-share ownership. Change only if your data is owned by a different user/group.

Accessing the GUI and signing in

Open the WebUI on port 5800:

http://<YOUR-UNRAID-IP>:5800

(Port 5900 is also exposed for a direct VNC client if you prefer.)

First-run flow:

1. On first launch, you may see Wine setting itself up / updating for a couple of minutes - let it finish.

2. The first screen of the Backblaze installer renders a bit rough under Wine, but it works. Type your Backblaze account email into the field and press Enter. (If the screen looks blank, hover the mouse over the white pixel in the top-left corner - it'll clear and the UI will draw.)

3. Enter your password and press Enter. Tip: the web interface clipboard helps, but odd characters/keyboard-locale mismatches can mangle input - a long password without special characters is the most reliable.

4. Let Backblaze analyse your drives, then click OK.

5. Recommended: if your config folder lives inside your backup source (the default on Unraid), add an exclusion to avoid an upload loop. Open Backblaze Settings → Exclusions → Add Folder, navigate to My Computer → (D:) → appdata → Backblaze64, and click OK.

6. As with any normal install, buy/assign a license for this computer in your Backblaze dashboard.

Known limitations

• Cosmetic "Permission Issue … bzdata\bzreports" warning. A false positive - Backblaze's self-check misbehaves under Wine, but it writes there fine and backups run normally. Safe to ignore.

• amd64 only. linux/amd64 is fully supported; arm64 is not currently supported.

• A previous "unstyled control panel" issue (black background / blank dialogs) is fixed - the container now creates the hyphen-named skin-asset aliases at startup, so the panel renders correctly on first launch.

Reporting bugs

Please search existing issues first, then open one here if needed:
https://github.com/iamfoz/backblaze-64-personal-wine-container/issues

PRs welcome if you find a fix; it helps everyone.

Credits

Huge thanks to @JonathanTreffler, whose Backblaze Personal Wine Community Container this is forked from; to @Atemu, the project's original author; and to @jlesage for the GUI base image.

Happy backing up!

Edited June 20Jun 20 by foz

The backup source (/drive_d) needs to be updated to (/drive_d/) within the template for it to actually recognize the folder.

Thank you very much - after almost a year without backup I can finally backup again to my already paid License!

Could you please explain how to bypass the problem that the uploader thinks more threats are not necessary?

I dont understand how to do that.

Has anybody had success with the process completing Backblaze scans for hard drives? It appears to be stuck or crashing on some loop while scanning files to backup.

It was already quite tedious for me to inherit a backup state, get any drives to show up, etc.

7 hours ago, spacemanspiff1968 said:

Has anybody had success with the process completing Backblaze scans for hard drives? It appears to be stuck or crashing on some loop while scanning files to backup.

It was already quite tedious for me to inherit a backup state, get any drives to show up, etc.

Yes - I deleted my old backup (did not think of inherit the state). The scanning took quiet some time - I let it run over night - I just let it do its thing. It scanned 274,855,068 MB (yes, the number is right), and also a lot of small files (1 Mio really small files). It progressed fastly towards the end and was stuck long there. Just give it time.

On 6/14/2026 at 11:56 AM, gandalf15 said:

Could you please explain how to bypass the problem that the uploader thinks more threats are not necessary?

I dont understand how to do that.

I'm also having the slow upload speeds issue. I understand that for some reasons, you need to put load on the CPU threads to make the backblaze client create more threads: https://github.com/JonathanTreffler/backblaze-personal-wine-container/issues/212#issuecomment-3250106214

But I have no clue about how to do that on the wine docker container.

Any help would be greatly appreciated.

Edited June 16Jun 16 by Opawesome

On 6/14/2026 at 11:56 AM, gandalf15 said:

Could you please explain how to bypass the problem that the uploader thinks more threats are not necessary?

I dont understand how to do that.

I tried to increase the CPU load with this command: yes > /dev/null & and it indeed allowed other threads to launch. Once the threads were launched, I killed the "increase CPU load command" with: pkill yes . At any time, you can check the current number of backblaze threads with the command: ps aux | grep bzthread | wc -l .

I'll further investigate, but this might be a good base for a workaround.

53 minutes ago, Opawesome said:

I tried to increase the CPU load with this command: yes > /dev/null & and it indeed allowed other threads to launch. Once the threads were launched, I killed the "increase CPU load command" with: pkill yes . At any time, you can check the current number of backblaze threads with the command: ps aux | grep bzthread | wc -l .

I'll further investigate, but this might be a good base for a workaround.

Thank you - no idea what this command does (the yes > one) but before using it I had 50 threats, after it, it went up to 81.

Maybe something that could be built in on start up to "get it going from the beginning?"

On 6/11/2026 at 5:53 PM, chutson said:

The backup source (/drive_d) needs to be updated to (/drive_d/) within the template for it to actually recognize the folder.

I noticed that when adding a drive to the template, the drive won't show in Wine on the first start of the docker container, but it will after you restart the container. I've notices that it doesn't make a difference whether you set the path to /drive_x or /drive_x/

On 6/11/2026 at 4:53 PM, chutson said:

The backup source (/drive_d) needs to be updated to (/drive_d/) within the template for it to actually recognize the folder.

9 hours ago, Opawesome said:

I noticed that when adding a drive to the template, the drive won't show in Wine on the first start of the docker container, but it will after you restart the container. I've notices that it doesn't make a difference whether you set the path to /drive_x or /drive_x/

Thanks both, I'd popped in a simple patch to add that trailing slash, but this extra bit of information helped me track down what the actual issue was.

The trailing slash is a red herring: Wine treats /drive_d and /drive_d/ identically, so that wasn't the cause (good catch on noticing it made no difference). The real issue is timing in the container's startup.

The container maps your host folder to a Wine drive letter by creating a symlink (dosdevices/d:). Wine only scans its drives when the wineserver starts - and the script was creating that symlink slightly too late, after the server had already come up. Initially, the drive is not visible on the first launch. However, on the next start, the symlink already existed before the server started, so it appeared. That's why restarting the container "fixed" it.

I've moved the drive mapping to run before the wineserver starts, so a mapped (or newly added) drive now shows on the first launch with no restart. It's committed and will be in the next image release.

Until then, the workaround is the one you already found: after adding a drive, restart the container once.

On 6/16/2026 at 4:17 AM, spacemanspiff1968 said:

Has anybody had success with the process completing Backblaze scans for hard drives? It appears to be stuck or crashing on some loop while scanning files to backup.

It was already quite tedious for me to inherit a backup state, get any drives to show up, etc.

On 6/16/2026 at 11:20 AM, gandalf15 said:

Yes - I deleted my old backup (did not think of inherit the state). The scanning took quiet some time - I let it run over night - I just let it do its thing. It scanned 274,855,068 MB (yes, the number is right), and also a lot of small files (1 Mio really small files). It progressed fastly towards the end and was stuck long there. Just give it time.

This is the way - it just takes a while to complete, and is probably exacerbated by some issues that slow some of these processes down that I am hopefully on the path to fixing. My own installation is very large and took about 48 hours to complete this initial process. If anyone stands this up and is concerned, it is normal for this part of the process to take a while.

13 hours ago, Opawesome said:

I tried to increase the CPU load with this command: yes > /dev/null & and it indeed allowed other threads to launch. Once the threads were launched, I killed the "increase CPU load command" with: pkill yes . At any time, you can check the current number of backblaze threads with the command: ps aux | grep bzthread | wc -l .

I'll further investigate, but this might be a good base for a workaround.

12 hours ago, gandalf15 said:

Thank you - no idea what this command does (the yes > one) but before using it I had 50 threats, after it, it went up to 81.

Maybe something that could be built in on start up to "get it going from the beginning?"

Really useful find, thanks for digging into it. That CPU-load trick pushing the thread count up (50 > 81) is a great data point, and it fits something I've been investigating: I think the root cause is an issue in Wine itself, in how it wakes/schedules these upload threads, rather than anything specific to Backblaze.

Rather than bake a permanent CPU-burner into startup as a workaround, I'm currently testing a Wine patch that may fix it properly at the source. Early signs are promising; I'll report back once I've validated it. It will be submitted upstream to the Wine project, hence the careful testing. Should they not want to take it, if my own testing doesn't unearth anything troublesome, I'll include a patched version of Wine in with this project.

In the meantime, your stopgap is a clever one for anyone who wants to get things moving now: yes > /dev/null & to spin things up, then pkill yes once the threads have launched (and ps aux | grep bzthread | wc -l to watch the count). Appreciated!

Progress update: root cause and fix for the ~140 KB/s upload limit

For everyone following the slow-upload limitation, I've tracked it down and have a working fix. Technical write-up below.

Symptom: single-stream uploads under Wine top out around 140 KB/s regardless of bandwidth. It only affects app-limited senders — ones whose send() calls keep succeeding without ever filling the socket buffer. Backblaze's uploader bztransmit uses libcurl, which is exactly this pattern, so large checkpoint uploads never finished inside the client's 600-second upload timeout.

Root cause: it's a difference in socket writability reporting between Wine and Windows.

• On Windows, select() reports a connected TCP socket as writable whenever send() it would still accept data — i.e. as long as the send buffer has any room.

• Wine derives its writability from the host poll(). On Linux, POLLOUT isn't set until the socket's send queue drains below ~2/3 of SO_SNDBUF. So while the buffer is between ~2/3 full and full, Windows says "writable", but Wine says "not writable" even though sends are still succeeding.

libcurl's event loop does a non-blocking select() writability check before it waits on an FD_WRITE event. FD_WRITE is edge-triggered and isn't re-armed until a send actually fails with WSAEWOULDBLOCK. On Windows, the pre-check returns "writable" and curl sends immediately; under Wine it returns "not writable," so curl falls through and blocks on WSAWaitForMultipleEvents for its full ~1000 ms timeout - once per ~64 KB burst. That's where the 140 KB/s comes from. (curl documents the underlying Windows behaviour in curl issue #6146: https://github.com/curl/curl/issues/6146.)

The fix: a small change in wineserver's poll_socket() server/sock.c) — report a connected stream socket writable when its send buffer still has room (TIOCOUTQ < SO_SNDBUF), matching Windows. That's it; one block. (For the curious: I also tested the obvious-looking second theory - that Wine should re-arm FD_WRITE on every send. Turns out real Windows does not do that; it only re-arms after WSAEWOULDBLOCK, per MSDN. So that change would have made Wine less like Windows, and I dropped it. The writability fix alone is sufficient.)

Validation:

• ws2_32:sock conformance test (the invariant "select reports writable iff send would accept data"): passes on real Windows, fails on unmodified Wine (~230 of ~660 sends reported not-writable while still succeeding), passes with the fix.

• Real backup, end-to-end: a checkpoint that previously hit the 600 s timeout uploaded in ~80 s under the patched build.

What's next: rather than ship a privately-patched Wine in the container straight away, I've filed it upstream (Wine bug 59893: https://bugs.winehq.org/show_bug.cgi?id=59893) and sent an RFC to wine-devel proposing the server/sock.c change plus the conformance test. The one open design question is that TIOCOUTQ is Linux-specific, so I want the maintainers' steer on the mechanism before opening the merge request. If it lands upstream, the container just picks it up from a future Wine release; no fork to maintain. If they decline, I'll

bundle the patched build into the image.

I'll update this thread when there's movement upstream.

Unrelated tip: backup stuck / "Failed to grab fourHourLock" / needs a restart to run

If your backup wedges (the log spamming Failed to grab fourHourLock, or the container only backing up after a restart) on lower-RAM hosts this is almost always an out-of-memory kill, not a Backblaze fault.

What happens: bztransmit gets OOM-killed mid-pass while it holds the 4-hour backup lock. The lock file is left behind, so every following pass fails to acquire it and the engine spins. Check the host kernel log - on Unraid that's the Unraid terminal (or SSH), not inside the container:

dmesg -T | grep -i 'killed process.*bztransmit'

If you see kills there, that's it. The engine's memory scales with the number of files it tracks - the file-id index and the "build todo list" phase can climb to 3-4GB on a large set, which is enough to get reaped on an 8GB box.

Fixes, roughly in order of effect:

• Restart the container once to clear the stale lock and resume.

• Cut the tracked file count: exclude large regenerable or duplicated trees - caches, package dirs, and especially backup-archive folders, which can add millions of files from a single migration.

• Drop your Backblaze version-history retention to 30 days if you don't need more - deleted files stay in the index until they age out, so long retention keeps memory high.

• Lower the backup thread count. Each thread is another bztransmit process; with the upload fix above, a single stream is fast, so you don't need many - 1–2 is plenty on a memory-constrained box, and Automatic can over-provision.

• If you can, give the host more RAM.

Post your dmesg output and rough file count if you want a hand narrowing it down.

@foz , you're the goat. Plain and simple. I've been waiting for years for this fix... Those very last moments of wait are like a torture :)

Looking forward for that fix!

I just hope it wont take months until its implemented.

Thank you very much!

Edited June 20Jun 20 by gandalf15

Update: Problem seems to have resolved itself - post left in place for informational purposes

Hi @foz

I'm trying to inherit a backup state from a previous install.

The Inherit Backup State popup window contains an Email: field (which can't be ineracted with/edited ... fine - it's the right email 😉)

Clicking Sign In fails with an error popup: Error Please contact Backblaze support with the error code: Horse

Any suggestions on getting the Inherit process to work ?

It's a large backup set, and I'd really rather not have to go through the whole rigmarole of transferring client licence to the new "trial" instance, away from the old backup-state/client, delete the existing state and redo the whole lengthy upload from scratch all over again.

EDIT:

Issue has maybe/possibly resolved itself.

I was poking around in .\wine\drive_c\ProgramData\Backblaze\bzdata\bzlogs\bzbui\ logs and found:

2026-06-21 09:59:57 576 - bzbui_win32.cpp:3012 [TransferBackupStateDialogCallback()] ERROR: Cannot retrieve IBS Authentication Helper context

I went back to Backblaze window to retry the Inherit process to see if the error could be duplicated, and this time it let me sign in, and seems to have completed succesfully...

Logging into the Backblaze website Overview now shows the extant backup being currently used again, and the new "trial" instance being renamed to "old_inactive_MYCOMPUTERNAME (Divorced)"

The container client has now generated a correct looking filelist of only things new/updated since last backup state of ~2 week ago and seems to be uploading at a reasonable pace.

Rather than delete this post, I'll leave it in case anyone else has the problem, and just waiting/retrying automagically fixes the issue for them too. 😊

Edited June 21Jun 21 by kurai

12 hours ago, kurai said:

Hi @foz

I'm trying to inherit a backup state from a previous install.

The Inherit Backup State popup window contains an Email: field (which can't be ineracted with/edited ... fine - it's the right email 😉)

Clicking Sign In fails with an error popup: Error Please contact Backblaze support with the error code: Horse

Any suggestions on getting the Inherit process to work ?

It's a large backup set, and I'd really rather not have to go through the whole rigmarole of transferring licence from old to new backup-state/client, delete the existing state and redo the whole lengthy upload from scratch all over again.

Hi @kurai, thanks; the screenshot confirms the client side is healthy (you're on a valid trial), so we can rule that out.

That narrows "Horse" here to the one remaining cause: the client couldn't complete its handshake with the Backblaze datacenter when you hit Sign In on the inherit. With a healthy trial, that's almost always a connection timeout rather than a block and a large backup set makes it more likely, because the inherit has to pull your existing backup state from the datacenter and that can run long enough to time out.

A few of things to check first, since timeouts are often transient:

1. Just retry the inherit a few times. A fair number of Horse-on-inherit cases clear on the second or third attempt once the state pull gets through.

2. Make sure nothing sits between the container and Backblaze - a VPN, proxy, or DNS filter on the Docker host or connecting network can break the specific datacenter call even while normal sign-in works.

3. Confirm that you are transferring a like-for-like OS backup - my own original backup was on a Mac Mini, so I unfortunately had no choice but to start fresh. The one advantage of this is that it discards any garbage the backup has collected over time. The only potential issue here is how long your backup takes to complete - if it goes beyond 30 days, then you may want to pay for a second license until you complete the backup and then discard the original.

If it keeps throwing Horse, let's look at what it actually logged so we're not guessing. Right after a failed attempt, grab the newest transmit log (from your Unraid terminal):

docker exec <your-container> sh -c 'd="/config/wine/dosdevices/c:/ProgramData/Backblaze/bzdata/bzlogs/bztransmit"; f=$(ls -t "$d"/*.log | head -1); echo "$f"; tail -150 "$f"'

Post the output (feel free to redact your email/any long ID strings); the line at the failure timestamp will show which datacenter it hit and whether it was a timeout or an actual error, and that tells us whether it's something we can fix on the container side.

I really do not want to complain about your improvement. Actually its not even your cause - but wineHQ seems to not even look at the bug. If I scrool the Bug List, there are Bugs open since 2010.

Chances you push an update yourself? Maybe on a side branch?

Thanks foz!

Thanks for the kind words, and no offence taken. It’s a fair concern.

A bug that’s been open since 2010 says more about that particular bug than it does about WineHQ’s bug tracker as a whole. Old reports often stick around because they’re obscure, difficult to reproduce, or simply not affecting enough people for anyone to spend time on them. It doesn’t mean they’re being ignored. What usually gets a bug moving is someone putting in the work.

In this case, that’s exactly what’s I'm doing - I didn’t just file a report, I wrote the fix for the bug, following Wine’s coding and submission guidelines, along with a conformance test that’s been validated against real

Windows to make sure the behaviour matches Windows itself. I sent it to wine-devel as an RFC first, then submitted the merge request. It’s passed Wine’s automated test suite, and I’m currently discussing it with the maintainers responsible for that part of the code to address any feedback before it goes in. So it isn’t sitting unnoticed in a queue. It’s under review, and I’m actively working through the process.

As for pushing an update myself, that’s effectively what this is part of. The aim is to get the fix into Wine proper so everyone benefits from it instead of maintaining a separate patch. In the meantime I keep the coainer up to date. I’ve already tested it against the latest Wine point release to make sure everything still works correctly on the versions the image is built from. If for whatever reason, WineHQ declines to include th fix in their release, that's when I will consider making the patch part of this software release and maintain it myself (e.g. continue to ensure it works with the current release of Wine).

While we're waiting, here’s something I’ve been working on that I’m thinking about including in a future release:

It’s a live upload monitor built into the container. There’s nothing to configure.

It opens a full-screen terminal dashboard showing:

• Live estimated upload speed.

• Per-file progress, including filenames, sizes and progress bars for each active upload thread.

• A rolling list of recently completed files, including their size and upload speed.

• An overview of the current backup session, with active threads, chunks per minute, session totals, and memory and swap usage.

• Scrollable upload viewport when lots of files are uploading, and adaptation to almost any terminal size.

If that’s something you’d find useful, let me know in the thread. If there’s enough interest, I’ll include it in an upcoming release. You don't need to write a reply if you don't want to - just liking this message is enough.

Edited July 3Jul 3 by foz
Text disappeared

Thank you very much - that sounds really good and also professional!

I only saw the wineHQ bug report sitting there and nothing happen, did not know what happens behind the scene.

That Dasboard looks amazing! Can not wait to test that out too.

This means, I will continue to play the waiting game :)

5 hours ago, foz said:

In this case, that’s exactly what’s I'm doing - I didn’t just file a report, I wrote the fix for the bug, following Wine’s coding and submission guidelines, along with a conformance test that’s been validated against real Windows to make sure the behaviour matches Windows itself. I sent it to wine-devel as an RFC first, then submitted the merge request. It’s passed Wine’s automated test suite, and I’m currently discussing it with the maintainers responsible for that part of the code to address any feedback before it goes in. So it isn’t sitting unnoticed in a queue. It’s under review, and I’m actively working through the process.

Thank you so much again for all this @foz . You're definitely the goat.

5 hours ago, foz said:

If that’s something you’d find useful, let me know in the thread. If there’s enough interest, I’ll include it in an upcoming release. You don't need to write a reply if you don't want to - just liking this message is enough.

WOW. That dashboard is basically what is probably lacking the most in the backblaze client. I'm speechless. Count me in amongst the interested people.