Jump to content

insont

Members
  • Content count

    16
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by insont

  1. I'm backing up a couple of Macs and Retrospect seems to place an inordinate load on them. My Macbook Pro 17", for instance, is hyperventilating several hours per day even though I hardly use it. I had Crashplan until they cancelled the service, and even though they backed up every 15 minutes, it was totally inconspicious and effective. Retrospect is a steamroller compared to that. Admittedly, Retrospect backs up more files, but still. Every now and then backups went smoother, and that was when Instant Scan did its work (as verified in the logs), but most of the time Instant Scan simply bogs down the machines but doesn't actually work. I had a week-long exchange with Retrospect support about this, trying to figure out why Instant Scan is totally ineffective, but once they escalated, I was told Instant Scan is no more. Not that it's having problems, no, that it has been abandoned. Does that mean my Mac backups will continue to be so grossly overloading the machines? I'll quote verbatim the last message I did get from Retrospect below. To me it sounds like Retrospect on MacOS will forever remain a dog. (I should mention that Instant Scan already didn't work before I upgraded to 10.13 and APFS. I also assume Retrospect support meant to say "APFS" and not "AFP", which makes no sense in relation to 10.13. And makes no sense in any case on the local machine where Instant Scan works. Or maybe they actually did mean AFP and then I understand even less.) "Dear Martin, Retrospect Engineering Reply can be found below. Instant scan doesn't work on AFP, and most likely customer is using AFP if they are on OSX 10.13.We recommend disabling instant scan in ALL cases, we are disabling instant scan by default in future versions of Retrospect.Thank you for using Retrospect,The Retrospect Support Team "
  2. David, That was truly horrible. /Martin
  3. David, Yes, I know that Retrospect doesn't implement instant scan anymore, but they sure do scan. Not so instant, though. And yes, Arq doesn't do fsevent monitoring, but where the full scan on Retrospect is comparable to the full scan in Arq, there's a nine-fold difference in scanning speed. Nine. At least. And yes, Retrospect has said they're going to fix it, but after seeing no sign of that for eight months now, can I not be excused for getting really irritated? Especially since Arq (and other products) show that this problem is clearly solvable? And considering that Retrospect cost me around ten times the price of Arq, the price-performance ratio between the two is 1:100. I promise to stop complaining once Retrospect shows any sign of at least trying to do something about this. And so far, nothing. /Martin PS: my name really is "Martin". "Insont" is only a handle. I thought that was obvious by now.
  4. Meanwhile, Retrospect finished on the same machine. "Preparing to backup" took 2 hours and 54 minutes, and the actual backup of 5.5 GB took another 6 minutes for a grand total of exactly three hours. Arq did the same job in 21 minutes. The reason Retrospect found 5.5 GB to backup while Arq only backed up 890 MB is because Arq runs successfully every hour, while it can take days for my machine to be on long enough for Retrospect to get past the "Preparing to backup" to actually do a backup. But, as I already said, the huge difference is in the scanning, and both products scan about the same volume of data.
  5. I did a cursory comparison between Retrospect and Arq on my iMac just now. Retrospect is set to backup the whole disk, with some exceptions, and usually is in the scanning phase ("Preparing for backup") for hours, then doing the actual backup for a couple of minutes or longer, depending. This while running a CPU at above 100% (right now, for some reason, it's down at 10% during scanning). If I sleep the machine, the scanning is restarted from the beginning when I wake it up again. So if I don't use the machine for more than an hour at a time, Retrospect in effect never gets anything done. Except heating the room, that is. Note that this is a 1 TB Apple SSD with APFS, 4-core i7, a GBit net with copper and fiber, and the destination is a Synology 1517+ on the local net. Both Retrospect and Arq, in this comparison, back up to the same Synology. MacOS 10.14.3. Retrospect 15.6.1. Arq 5.15.2. (I also run several laptops, which I've mentioned before, but this time I'm on this iMac.) Arq, on the other hand, doesn't have a separate scanning phase; it scans and uploads at the same time. So it always gets something done right away. I have it set to only backup the home directory, but that is about 85% of the total size of data on the drive. While it was running, it took about 35% of a CPU, with no noticeable warming up. The whole scan and upload took 21 minutes, scanning 586 GB and uploading 890 MB. And, as I said, totally unobtrusive. By default it backs up hourly. Now, that's what Retrospect should do, as well. The separate scanning phase seems to be the fundamentally bad idea here. And it's excruciatingly slow to boot. Something else they should copy: Arq can use SFTP to the backup store. So even if you have a local NAS, you can backup without mapping the drive, which makes it way less likely that crypto malware destroys your backups as well. Yes, I know you can unmap network drives in Finder once you've set the credentials in Retrospect, but I've had that fail a couple of times. I don't like it. I figure it will be a lot less likely malware will see and be able to connect to an SFTP destination. Arq also has S3, so I can use both Retrospect and Arq with Wasabi. In summary: Arq is painless where Retrospect is painful. And Arq is safer, having SFTP. (I may have missed something in Retrospect, though.) Do note, however, that I'm currently anti-Retrospect biased, so I'm probably blind to the advantages of Retrospect over Arq right now. But that's humanity for you. /Martin
  6. Backing up my MacOS machines is still taking 3-5 hours every time, always with a heavy CPU load. And any interruption makes it start all over again, so in practice I have to leave the machines on all day just for Retrospect. I've reduced the backups to one day a week simply because I can't stand feeling (and hearing) all that hot air. Meanwhile I tried ArqBackup and it has none of these problems on the same machines. It blows through the backups in no time. It runs every hour with no noticeable CPU load. If a one man product like Arq can do this on APFS, why can't Retrospect? The performance difference is completely surreal. Arq seems to be very similar to Crashplan in this respect. Or rather, similar to practically anything except Retrospect. I'm starting to wonder if all that money I spent on three years of support on Retrospect wasn't wasted. It sure looks like they don't really care. No solution of any kind has appeared yet and this has been going on for quite a while now. If it wasn't for that investment, I'd have thrown out Retrospect by now. Sorry about that. I needed to vent. /Martin
  7. Henry, Well, I'm certainly seeing a difference. Going from 2 minutes on a Windows machine to 2 hours or more on a Mac with a built-in SSD, with comparable backup sizes. That's two hours spent in "preparing for backup". So let's hope that is due to (the lack of) Instant Scan, else it's beyond useless, if it never gets fixed. Possibly this only happens to some people, of course, but it's happening on all my Macs on APFS (four of them), and not on virtual and real Windows machines (three of them). Am I really the only one seeing this? /Martin
  8. Well, I did write support to ask if they had plans to fix Instant Scan in the future or if they'd given up on MacOS, and got some encouraging news: /Martin
  9. The latest Retrospect doesn't seem to implement Instant Scan either. I can't even enable it anymore. I have to leave laptops on for hours just to get anything backed up at all. See this log from today, from a Macbook Air where the scanning and snapshot took three hours, then the actual copy around two minutes. Tomorrow, it's going to scan for three hours again... unless I forget and close it, which will make the whole thing repeat. It's not reasonable to consume three hours just for file scanning for every backup on a relatively small computer. (And to think Crashplan used to run backups every 15 minutes, each one taking seconds. Without significantly loading the CPU.) + Normal backup using After8 at 2018-09-20, 17:36:11 (Activity Thread 2) 2018-09-20 17:36:12 : Finished scanning backup set data files To Backup Set After8 Martin... - 2018-09-20 17:36:11 : Copying Macintosh HD on after8 (2) 2018-09-20 19:59:26 : Found: 2268745 files, 497287 folders, 316,4 GB 2018-09-20 20:00:04 : Finished matching 2018-09-20 20:01:50 : Selector "Martin's machines" was used to select 2 225 329 files out of 2 268 745. 2018-09-20 20:07:04 : Copying: 935 files (709,7 MB) and 0 hard links 2018-09-20 20:09:20 : Building Snapshot... 2018-09-20 20:09:21 : Checking 497 287 folders for ACLs or extended attributes 2018-09-20 20:40:57 : Finished copying 336 384 folders with ACLs or extended attributes 2018-09-20 20:41:11 : Copying Snapshot: 2 files (239,6 MB) 2018-09-20 20:41:26 : Snapshot stored, 239,6 MB 2018-09-20 20:41:26 : Comparing Macintosh HD on after8 (2) ... 2018-09-20 20:42:07 : Execution completed successfully Completed: 935 files, 705,2 MB, with 52% compression Performance: 549,5 MB/minute (371,1 copy, 1 057,8 compare) Duration: 03:05:55 (03:03:21 idle/loading/preparing) /Martin
  10. I'm doing "copy backups" to the cloud (Wasabi) since the end of last year. I noticed on the invoices I got from Wasabi that there was no inbound traffic for months already, since around March. I have three scripts doing these copy backups, running daily and I found all of them terminated every time with the error "no snapshot found". As far as I can see, source, destination, schedule, selection, and options were correct. I couldn't make these scripts copy anything even when hitting "run". Finally, I just deleted the scripts and recreated them with the exact same parameters and now it works. I don't know what went wrong and I was very slow to notice, but I'm posting this as a warning. Check your cloud "copy backups" to see if they're really running. On a side note, it would be nice if the dashboard had some way of telling me when this happens. I couldn't see any indication of it. I don't think copy backup status is displayed there. This isn't a question, it's meant as a heads-up and warning. Martin Edit: through Wasabi I discovered the backup scripts stopped working exactly on new year. The last backups were on Dec 31 on all three scripts.
  11. I've submitted a report now.
  12. David, Since I'm on a maintenance contract, I used the latest version. Problem is, I don't remember when 15 came out, but I upgraded two or three weeks after it was released. Wasn't that around March something? So, v14 must have been running when backups stopped working. Right now I'm on 15.1.2. If there is a bug related to the year rolling over, I guess we'll have to wait another five months to see if it happens again. You mention 7 March 2018, any particular reason? Or do you refer to my initial "since around March"? As I added in my edit, the backups stopped working between December 31 and January 1, not March. Martin
  13. David, Nice detective work. Yes, what you found seems very likely to be the explanation. As long as that API problem persists, Retrospect can't do all that much about it. (Except if it's only a problem of identifying file deletions I would expect it not to be that disastrous. If the agent tries to back up a deleted file that is still in the scan index, it could just skip it. At least that's what I would assume. The inserts and updates seem to work right, so... but there could be more to it than that, of course.) Let's hope Apple gets its act together, though, and get this fixed.
  14. David, Retrospect Engineering didn't reply directly to me; it was forwarded by the support engineer. I thought that was obvious from the quote where they mention me in third person. I just picked up the whole support thread from Retrospect Support and copy/paste it below. It's completely unedited, I left all references in. Start reading from the bottom. BTW, I have the problem on several machines, but I concentrated on one for the support case.
  15. David, I copied verbatim what Retrospect support sent me. How can I prove that to you? And yes, I created this login specifically to post about this, since the reply from Retrospect upset me. I didn't expect, however, to be accused of lying in the process. About "recent visitors block is disabled" I know nothing. I haven't touched my profile from the default. I'm sorry if I broke some kind of rule by not doing that. BTW, since you doubt my veracity, I'd suggest you ask Retrospect support if this is true. Either they confirm what I just said, making me somewhat happy, or they backtrack and say they are going to support Instant Scan in the future or that I misunderstood, and I'm even happier. To me their reply seems not quite thought through and not good for the product, so you asking could make them think again. Oh, and the case is nb 00061949 that contains this exchange, including the message I quoted. You're welcome to reference that. Martin
  16. I just created a new thread about this. Retrospect told me Instant Scan isn't supported on APFS and seemingly won't be in the future either. (I just noticed this thread after I did the other post.)
×