![]() If you are a laptop user that shuts down your laptop or sleeps it frequently, or unplugs your external hard drive sporadically, the “slow” bzfilelist might never complete during the times your laptop is awake or when the external hard drive is plugged in. To make this even more complicated, there is the “DEFCON” logic. So in this case it notches up to 2 hours and 15 minutes worse case for files less than 100 MBytes, and 50 hours and 15 minutes for modified files larger than 100 MBytes. The bzfilelist takes less than the 15 minute offset from bztransmit on 95% of internal laptop drives, but it runs “slowly” on purpose (to not be noticed) so if it is crawling a 16 TByte external drive that might take longer than 15 minutes to detect the new or changed files, which means it pushed bztransmit back 1 additional hour. So if the file is brand new, the above logic holds, but if you are editing a 1 GByte home movie, to save your bandwidth and Backblaze’s version storage space the 2nd time it will be uploaded is 48 hours later plus the 1 hour and 15 minute delay seen above.ĪNOTHER way any file can be delayed more than the 1 hour and 15 minutes is if you have a “big” external drive. What can delay this even more: if the file is more than 100 MBytes, Backblaze changes the logic to only back this up “not more than” once every 48 hours. If you change a file and bzfilelist starts 59 minutes later, the file will appear in the Backblaze datacenter 1 hour and 15 minutes later. So if you change a file and bzfilelist happens to launch 1 minute later, the “delay” will be about 16 minutes for a small file. Slightly Longer answer: if you have a regular laptop with no external drives, a process called “bzfilelist” will kick off once per hour to DETECT any new and changed files, and 15 minutes after that runs a process called bztransmit will send the new or changed file to the Backblaze datacenter. How long after I change a file will it be backed up. So any situation like not having fully redundant networking is a straight up screwup, not a financial decision anymore.ĭisclaimer: I work for Backblaze and wrote a lot of the client. Our current situation is much more rational - we have solid cash buffers in our bank account, and we now can get equipment financed. ![]() Since we never raised any funding (we are employee owned and run, nobody sits on our board of directors except founders that still work at the company full time), and because equipment leases and business loans disappeared during the 2008 - 2010 financial crisis, it was a very “lean” time for Backblaze. Backblaze cut a few corners early on, like not having fully redundant networking, because we were so cash strapped at the beginning. :-)īut these types of emergencies are rare, and as time goes on getting more rare. A precious few customers who were watching their uploads contacted Backblaze support. Customers in the big “initial upload” were most affected, their upload bandwidth rate just magically dropped for 24 hours, then picked back up in speed later. If you were all caught up, your backup probably stayed caught up. This was never detected by the customer base, by and large, which was the idea. But at the time before the network failure we were using more than half the bandwidth, so for a 24 hour period (until we replaced the network gear that failed) we remotely told a subset of the “Personal Backup” clients to slow their uploads to keep from overwhelming the remaining network link. Now, that is not supposed to be a problem, we always want to run at full redundancy for the network. An example of when we had to do this in the past was when a piece of networking equipment suddenly failed, and we lost half our bandwidth capability coming into that one datacenter. ![]() In extreme situations, when our world goes sideways, we can choose to put a subset of the clients (or all of the clients) to sleep, or even slow their uploads. Ok, now, Backblaze has a few emergency remote control options on all of our “Personal Backup” customer clients, which is close to 1 million laptops and desktops now. Most of the time this goes undetected by the clients, and might be as short as 3 minutes of downtime where a few unlucky customer’s clients attempt to start a backup in the 3 minute window and quietly go back to sleep skipping 1 backup session and will resume 1 hour later. ![]() On Thursday afternoons at around 2pm-3pm California time we do a weekly “push” where that week’s software changes go out to all of our datacenters. In general, like 99% of the time our servers are up and fine and the lag is all about what occurs on the customer end. Im guessing it depends on busy their servers are.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |