nj2359
commented
8 months ago Forgot to mention I pay for 1 year retention, which is why files older than 30 days become exempt from purging.
Closed nj2359 closed 7 months ago
nj2359
commented
8 months ago Forgot to mention I pay for 1 year retention, which is why files older than 30 days become exempt from purging.
smccloud
commented
8 months ago I can say, this is a known issue.
https://github.com/JonathanTreffler/backblaze-personal-wine-container/discussions/82
JonathanTreffler
commented
8 months ago Can log collection be done this way since no windows taskbar exists?
Wine can show a taskbar and I remember seeing it with this docker, but that was a while (and a few wine versions) ago, but there should still be a way to show it. I don't know any more details, but maybe this information helps with finding a solution.
EDIT: Whether or not wine shows the taskbar seems to have something to do with Virtual Desktop Mode: https://github.com/JonathanTreffler/backblaze-personal-wine-container/issues/71#issuecomment-1858456821
Gathering logs the old way I've opened a support case before for the same issue. Previously, backblaze support would send a bzGather.zip file which contained a Gatherlogs.bat file, which would collect the logs required for support. This was easily run from the command line in the wine container.
Gathering logs the new way I just opened a new support case for the same issue and now backblaze support wants me to obtain logs via the windows taskbar icon. Instructions here - https://help.backblaze.com/hc/en-us/articles/14750756786075 Below is an image of the instructions from the link above
Can log collection be done this way since no windows taskbar exists? Or is there an alternative workaround to trigger the software to send the logs to support? If any of us need support, we can't really disclose that we're running backblaze in a wine environment because it is not supported. So I don't want to ask if I can use the original bzGather.zip method because I assume questions will be asked as to why I want to take a more cumbersome approach for log collection.
For those interested, here is more info on the re-upload issue. I've been having an issue where a 500GB file keeps being re-uploaded because a change in the file is apparently detected, even though no change has occurred. This is indicated by purge_FK appended to the end of each line, for each completed chunk, for the file in question, in the bzdone log files, located in /config/wine/drive_c/ProgramData/Backblaze/bzdata/bzbackup/bzdatacenter For those not familiar, In that directory, you'll see many files named like this bz_done_20231221_0.dat which contain the upload history for every file sent. Large files will have many lines for each 10Mb chunk uploaded. The number of 10Mb chunks required to equal the file size will indicate how many lines appear in the log file for the file in question. So a 200GB file could be roughly 20,000 lines logged. A new bzdone log file is created periodically and older bzdone logs are retained. the bztodo log file contains the next files in the upload queue. Here is an internal Backblaze in depth video describing exactly how the logging works https://youtu.be/MOlz36nLbwA?si=ONJY2uGaRetofnKg&t=1073
This has happened before, as I've had the issue with almost all files over 200GB. Support never actually did anything, we just waited the issue out. Not sure if anyone else is having a similar issue.
The re-uploading will consume all the bandwidth for days or weeks and hold up the transfer of other files as the large ones keep re-uploading over and over. This is the response from Backblaze regarding the previous case I opened for the re-uploading of large files.
**"Files are purged in the event of a rare file hash collision, where two files share the same hash. In such cases, both files are discarded, and the version from your computer is designated as the master file. We never assume the correctness of our version; instead, we rely on yours.
The notification of a purge on a specific file, denoted as purge_Fk, confirms that the purge has been executed. If the purged file is currently active, meaning it hasn't been stored and is younger than 30 days, it will be replaced with a verified file from your system.
Files removed from your drive for more than 30 days are exempt from purging. They are no longer part of your live data set but are incorporated into the Extended Version History data set. These files are not continuously compared to the live data set, ensuring their immunity from the purging process."**