Frequency of session rotation (observed) = 1 new session every 5-6 minutes. Maximum number of concurrent connections (configured) = 64 (but we've tried 8,12,16,24,32). Max number of concurrent sessions (observed) = 68. SSL policy = no-inspection (the factory policy). Destination IPs = Multiple (but we have all of them in an address group). Also, we have the TCP timeout on this policy set to 2 hours. There is hardly any other traffic on this network and the CPU never even reaches 10%. The firewall is a 61F, which we know has an inspection limit of 700Mbps, but we have the backup capped at 500Mbps, and we've created a policy rule that exempts these jobs from inspection altogether (Fortinet verified the policy was created correctly and is correctly matching the traffic). We do have a ticket open with Fortinet but, TBH, I think they're running out of ideas because it's gotten to the point where they're not even reading the notes/updates anymore and we we're losing hope in a good resolution. We know it's the firewall because if we bypass it, then the jobs work fine (all of them). This is corroborated by the firewall logs which then contains thousands of the "no session matched" errors (presumably from the server retrying before it gives up). What's real interesting, is no matter how many connections it had open, *all* of them fail at the exact same time. Nevertheless, we were lucky enough to get a capture during one of the times when the job failed quickly, and it does show data being transferred and then suddenly stops. 
This also makes captures extremely difficult because even if we slice to header, it's still 16K packets per second. Sometimes a job will run for 5 minutes, and sometimes it'll run for 2 days. The biggest problem trying to troubleshoot this is that it never fails at the same place. Less than 0 bytes transferred the last 60 seconds". Even in the backup logs, we can see it was in the middle of sending the multi-part upload, then suddenly it logs the error " Operation too slow. This is very strange, because on the sniffer we can see the transfer was actively going. The firewall shows an implicit deny because of " no session matched". No matter which one we start, it always starts just fine but eventually we will begin seeing a flood of TCP retransmits, and shortly after, the job fails. The jobs are all set to manual, and never run together. The backups are broken into different jobs with the largest being ~12TB, and the smallest being ~400GB (total for all is ~40TB). We are using MSP360 to transfer to Backblaze (B2). If you have extremely large files that are slowing down or clogging your backup, you may want to consider excluding the large files from backup.We have a large transfer that we are sending through our FortiGate but it always fails because the sessions are getting dropped on the firewall. So, if a large file is changed multiple times throughout a several day period, only 1 version of that file will be uploaded every 48 hours.
Versioning of large files is limited to one every 48 hours. The only time it'd use the internal drive is if the external is unavailable. This means that when that external is connected and available, Backblaze will set its temporary folder to that external drive, and perform its chunking operations on there - avoiding your internal drive. If you have an external drive, you can set a "temporary data drive" in the Backblaze settings to one of your external drives with ample space.
Once all pieces are transmitted and confirmation is received from the servers, the chunks are deleted, and the next file is processed. Each chunk will be checksummed, packaged and prepared for transfer (that's up to 0.1x the space of the original file, but typically less). The file will be copied in 10 MB chunks to a temporary Backblaze folder (that's 1x the space of the file). Let's say you have a 10 GB video file that needs to be backed up. This allows the smallest files on each system to be uploaded in batches, significantly improving upload rates due to reductions in overhead.įiles that are larger than 100 MB are parsed into 10 MB chunks for transmission. #BIGGEST BACKBLAZE BACKUP SOFTWARE#
The Backblaze software uploads files sequentially from smallest to largest. By default Backblaze does not have any file size restrictions:
0 kommentar(er)
