![]() If you later delete that same file from your laptop it appends an ADDITIONAL LINE that starts with a "-". If you add a file to your backup, it appends a line that starts with a "+". ![]() These never shrink (by definition), and never change, it is a PERFECT history of everything that occurs in your backup. Now, the way the backup program started 14 years ago was one bz_done file for each day you backup. That's why you have to wait until "midnight" where "midnight" is around 5pm California time. On midnight LONDON TIME the new file is created "bz_done_20201206_0.dat" (notice the "06" for the 6th of December) and all file names of files that are backed up from that point onward go in this new bz_done file. You can think of bz_done files like there is one bz_done file for each day you backup (I'll explain more down below) but the NAME of your bz_done file today will be something like "bz_done_20201205_0.dat" which means it is backing up in the year 2020, the month 12 (December), and day "05". The code "pauses" when the bz_done file is still 200,000 bytes "short" of the 2 GByte limit. We don't know what your filenames are and we do not want to know, and this way we can work comfortably in and around the files without seeing your filenames.Īt least one post suggests it will magically sort itself out at midnight In our datacenter they are named the 83 characters of hex. ![]() It needs to decrypt this file in order to show you the files to restore, AND TO LOCATE THEM IN OUR DATACENTER. If you set a private encryption key, Backblaze absolutely does not know your filenames. When your client sends the bz_done file to the server, it first reads it into RAM, compresses it, ZIPs it, then it encrypts it AND THEN transmits this encrypted bundle through HTTPS (double encryption protection). If you want to know what the other columns are, there is a decoder ring here (meant to be printed on an 8.5" by 11" piece of paper horizontally "fit to page"): When you sign into the web page and browse your files, it builds the "file tree" by reading your bz_done file (that was sent by the client to the server). Each line is a map of the "fguid" (hex 83 character string that locates your file in the Backblaze datacenter - file globally unique identifier) and the filename of where the file sits on your computer. Ok, so if you are REALLY careful, make a COPY of the bz_done file and want to see what is inside it, open THE COPY in WordPad on Windows (not Notepad) or with TextEdit on the Macintosh, turn off all line wrapping, and make your text editor AS WIDE AS YOU CAN MAKE IT on your screen and you will see there is one text line for each file that you backup. If you ever modify a bz_done file, you have to uninstall, reboot, make sure there are no bz_done files on your system, then re-install and DO NOT USE anything called "Inherit" - because "Inherit Backup State" would download the corrupted bz_done files and your backup wouldn't work any more than if you had not uninstalled and re-installed. I wrote all the code that deals with the bz_done files, and I personally would NEVER attempt to modify those files and expect my backup to work ever again. Please never modify a single byte in the bz_done files or your backup is destroyed. Ok, so this is really super important and I'm not kidding around. RIGHT NOW when the client or server has to unzip, the maximum RAM it would take is 2 GBytes, if we increased that to 8 GBytes it might crash on some wimpy computers, so the best fix is "many more still small" ZIP files. Another fix would be to update the ZIP library on the client, but that has other implications. ![]() The idea was it could be "_1" for the second file in that day, and "_2" for the third file of that day and so on. If you notice, the files are named "bz_done_20201205_0.dat" and the "_0" in front of the ".dat" is completely unused. One way would be to have multiple bz_done files per day (each less than 2 GBytes), and the file names reserved space for this ALREADY. There would be several ways to fix this limitation, it is just that so few customers hit the limitation it doesn't come up much. The limitation is that library the client links with to ZIP the files cannot handle larger than a 2 GByte files to ZIP. Those files are ZIPPED up and sent to the server, and make up the very basis for how you restore. It's a VERY silly reason (I fully admit this), but bz_done files are the "database" of all the files you have backed up. Why does Backblaze care about the size of bz_done files at all? Disclaimer: I work at Backblaze and wrote the code that pauses the backup when the bz_done file is too large.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |