![]() I don’t really know the details of how Arq works. Regardless, the backup of data from your boot drive is likely involves the most disk I/O and most noticeably affects performance. Just going by the logs, it shows it’s backing up the active /Users directory, not from the snapshot, meaning the backup client has to also deal with files that are locked for use by other processes. I see Arq creates an APFS snapshot of /System/Volumes/Data but it doesn’t show it being used. 1,067K, and probably far fewer that have changed between runs. That’s likely because that drive has about one-third as many files, 369K vs. Looking at your Arq logs, it takes over two hours to create a backup of /Users but your Photos drive takes only half an hour, even though it’s almost three times as much GB. B2 has a command-line client but it provides an API so anyone can write their own client, Arq can use it as a backup destination. Backblaze B2 cloud storage is separate.ī2 is pay-for-what-you-use cloud storage that’s not just for backups but also for hosting files it’s comparable to Amazon S3 standard or Wasabi. ![]() But having tens of thousands of operations execute locally on the server, rather than over a WAN, can behave much better.īackblaze used backup is unlimited storage used exclusively by their backup client software. I have a hypothesis that each of these blocks may be incurring a round trip from Mac to AWS to be freed. You can see from the Arq logs that Arq is spending countless hours clearing blocks that have been freed by the thinning process. Is my memory wrong about that? So…ĭoes that mean you can no longer bring your own storage to BB?Īnd does BB, in fact, use a client/server architecture, where some processing is done on the server side? If so, that has the potential to be a huge performance benefit. But I THOUGHT BB used to have an option to let you bring your own storage, but that some time later they offered their own B2 storage to form a all-in-one offering. I never studied BB at any length, save the articles here on TidBITS over the years. Thanks for touching on this, which is the next area I wanted to cover! That is, whether there is a client/server architecture for Back Blaze. Yes?Īs such, can anyone provide performance data about how BB handles, say 1-2TB of data into the Cloud? (Eg, how many hours a day is it running, how does it affect system performance, etc?)īackblaze operates with what I would call a client app on the Mac side, which communicates with a Backblaze server app that takes care of things on the storage side, in their data center. So now I’m considering alternatives, and BackBlaze appears to be the favorite child these days. I have been working with the developer, but I’m not optimistic he will be able to fix it. (CPU and Network and memory do not appear to be busy during this operation). But when it actually goes to purge the linked data blocks, the process I believe they call “cleanup”, it spends an inordinate amount of time. It has a “thinning” process which keeps hourly backups for 24 hours, daily backups for 30 days, etc. Here is a sample run with I/O throttling DISABLED:Ģ 08:00:05 EDT Storage location: AWS (S3:/akiauenjtrxfwvdeqwuf-arq)Ģ 08:00:05 EDT Backup plan: Back up to AWS (D2758EBB-E649-4832-AE6D-XXX)Ģ 08:00:05 EDT Preventing computer sleep while backing upĢ 08:00:31 EDT Creating APFS snapshot for Macintosh HD - Data (/System/Volumes/Data)Ģ 08:00:31 EDT Created APFS snapshot for Macintosh HD - Data (/System/Volumes/Data)Ģ 10:18:43 EDT /Users: Created a new backup record.Ģ 10:18:43 EDT /Users: 482.871 GB, 1,067,779 files backed upĢ 10:46:46 EDT /Volumes/Photos Image 2: Created a new backup record.Ģ 10:46:46 EDT /Volumes/Photos Image 2: 1,391.454 GB, 369,503 files backed upĢ 10:46:46 EDT Total scanned: 1,874.325 GB, 1,437,298 filesĢ 10:46:46 EDT Total uploaded (compressed): 2.371 GB, 2054 filesĢ 10:46:46 EDT Thinning backup records according to backup plan settings.Ģ 10:46:47 EDT Thinning backup records: Deleting backup record 09:21:10 +0000Ģ 10:46:48 EDT Thinning backup records: Deleting backup record 06:08:51 +0000Ģ 10:46:48 EDT Removing unreferenced dataĢ 10:47:39 EDT Total stored size before cleanup: 2,029.852 GBĢ 18:08:55 EDT Total stored size after cleanup: 2,027.527 GBĢ 18:08:55 EDT Removing APFS snapshot for /System/Volumes/DataĢ 18:08:55 EDT Removed APFS snapshot for /System/Volumes/Data And in spite of the options to Throttle Disk I/O and other resources, I almost always have to pause it to keep my iMac from being unusably slow. Depending on when the runs take place, the iMac can effectively be backing up ALL THE TIME. A typical incremental run can take 10 hours, thought it varies widely. ![]() But it seems to have a performance / optimization problem. I’ve been using Arq for a number of years since CrashPlan’s demise.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |