Leaderboard

David, your condescending comments aren't needed here. Martin (and others, myself included) are frustrated at this slowness, and a little venting is not out of order. I don't understand why you feel the need to carry water for Dantz - if you don't have anything positive to contribute, you aren't required to post.

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 "

CherylB, I think you misunderstand what I've been saying in this thread. Instant Scan was not supported for APFS volumes as of May 2018, and I don't think that's going to change with Retrospect 16—because the macOS facility it depends on (called fsEvents) wasn't implemented in the same way for APFS as it was for HFS+. But, according to what Retrospect Tech Support told insont per this October 2018 post, "In our next full release of Retrospect the client scan APIs will be completely overhauled .... For local backups you can help speed things up by changing your current api settings .... Client API changes are being worked on and preliminary testing shows them being upwards of 10 times faster than they are currently." IMHO that means non-Instant Scan will be speeded up so much you won't miss Instant Scan. I'll update this post with links to other posts when I have time.

insont and cgtyoder and CherylB, I just discovered, while writing a post discussing this problem (among others) in my authorized Retrospect thread on the Ars Technica Mac forum, that this Knowledge Base article has been temporarily hidden from view (I found it again through my link in a prior post in this thread) while having been updated to refer to Retrospect 16 as of 5 March 2019. I take this as confirmation that the engineers have now completed what must have been a substantial effort in changing a lot of 30-year-old code, which the developer(s) of younger backup applications such as the one insont mentioned have not had to go through. OK, IMHO you've now got a definite date (probably 6 March) when the non-Instant lengthy APFS scan problem will be—at least preliminarily—fixed. If you still want to vent, feel free to do so. If you want instead to file Support Cases, those would provide retroactive justification for Retrospect engineers having made the effort. But IMHO it's time to make good on "I promise to stop complaining once Retrospect shows any sign of at least trying to do something about this."

insont and cgtyoder and CherylB, I haven't been denying that long scans are a real problem for Retrospect administrators backing up Mac drives formatted with APFS. I'm really sorry you folks have this problem. It's not a problem for me, because my two modern Macs are running macOS 10.13 High Sierra (just upgraded last week at the urging of Apple Support—keeping the machine's only drive still formatted with HFS+) and macOS 10.12 Sierra. One reason for my OS backwardness is that I had a deep-seated mistrust of APFS; I felt—and still feel—that a brand-new filesystem was a big challenge for Apple. That feeling was later confirmed by my reading here (along with other places) that Apple didn't publish full documentation on APFS until sometime in 2018. As I said 8 months ago in this thread, the developers of another backup application turned out to be also having problems with their equivalent of Instant Scan not working for APFS. But, as I tried to make clear in my latest previous post, the reason Retrospect has slowness of non-Instant scanning is probably because it has been using 32-bit Mac APIs for the last 30 years. Now here's something "positive" I can contribute. A couple of hours ago I phoned Retrospect Inc. Sales. A senior salesperson there told me the engineers are working on this problem, and that it's likely to be fixed in version 16. If you feel it's necessary to put additional pressure on Retrospect Inc., my advice is for each of you to submit a separate Support Case. Here's why and how to do that. Just copy your individual post(s) in this thread into the Description of Your Issue, which IMHO should be categorized as a Problem rather than as a Backup Error.

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.

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

lhlo (demerits for picking a cutesy-poo "handle" for which I can't figure out whether the first letter is upper-case 'I' or lower-case 'l'), First, read the boxed-in paragraph below the screenshot at the top of page 448 in the Retrospect Windows 9.5 User's Guide. If that paragraph describes what happens when your Member is full, un-check the checkbox and increase the "Use At Most" number of GB appropriately. Second, if that doesn't work, do what it says on pages 449-451 of the UG under "Adding a Disk to a Backup Set". Add the new Member on the same disk as existing Member, and give it the appropriate "Use At Most" number of GB. This post describes that as the workaround for an earlier version of Retrospect Windows. So this is your "poor second choice", but next time you'll remember to set the "Use At Most" percentage appropriately when adding all new Members.

It all depends on what the problem is. If it was introduced at the file system level, e.g. a disconnect while writing data, then fine. The problem will be with the volume presented to Disk Utility and will (since this is a hardware RAID) be present on both drives. Fix the volume, fix the problem. If it's a disk problem then no, don't go there! One disk should be showing as "failed" -- simply pop, replace, rebuild RAID. Perhaps worth noting that RAID =/= backup -- it will protect (somewhat) against hardware failure, but not e.g. data corruption. And personally, I wouldn't trust *any* volume, RAID or not, that "unexpectedly" unmounted. Get that sorted before continuing!

bradp015 and Lennart_T, bradp015 can as of Retrospect Mac 14.6 do what he suggested in his OP, so long as he is simultaneously backing up a different Favorite Folder on the same drive in each script. He could divide his whole disk into Favorite Folders, which only apply to Retrospect, and have his two scripts back up the Favorite Folders in a different order. Alternatively bradp015 could do what Lennart_T suggests, with a Backup script and a Copy script. However he should be sure to assign the same Activity Thread, in the Summary tab for the Scripts, if he schedules the two scripts so that they could possibly overlap in execution. If he doesn't make sure to do that, the Copy script will ignore new or changed files that are being backed up—since it uses a Catalog File that is not updated for the Media Set until the end (barring any optional Comparing) of the Backup script run. P.S.: On 10 January 2017 I suggested in this Product Suggestions—Mac OS X thread that a modest enhancement to Retrospect would enable overlapping a Backup to a particular Media Set with a Copy Backup or Copy Media Set from that same Media Set as the source. That enhancement assumes that the Copy script would be scheduled at least a minute after the Backup script. On 2 April 2017 I converted that suggestion into Support Case ##54601 for a Feature Enhancement. That Support Case has been closed, with no evident action taken on it by Retrospect engineering since then. Considering that Retrospect 15 now enables multiple Activity Threads (Execution Units for Retrospect Windows) even for the Desktop Edition, IMHO Retrospect engineering should reconsider that enhancement for Retrospect 16.

No, there isn't. No, you can't. Both the source as well as the destination must be different for scripts to run concurrently. You could run a normal backup script from the source computer(s) to media set A. Then you could run a "Copy Backup" script from Media Set A to Media Set B. That way the source computer(s) is/are not involved and free for other uses.

Ok, problem solved (or worked around). I followed the advice from this old thread, even though this is a NTFS drive under Windows : But I also removed all the tickboxes under the Windows Security backup options in the script. Disabling both (which I don't really need anyway) does solve the problem and a re-run doesn't backup anything anymore that was already backed up before.

CherylB, Congratulations, a search of the Forums shows you are the first administrator reporting error code -808 for Retrospect Mac. Nobody has reported this error code on Retrospect Windows for about 9 years, but the most appropriate thread—one for a Backup—seems to be this one. The now-two-Retrospect-variant-expert Lennart_T then suggested "I don't know what caused it, but you should recreate the catalog file to rectify" in the second—and last—post in that thread. Ununnilium never reported whether that worked. However 15 days later, in another thread concerned with running out of RAM during a Catalog File Rebuild, he/she reported "As a followup, I noticed that the backup set [Retrospect Windows term for a Media Set] was created."

I got that feedback from support recently as well and reported it in another post here. Frankly, when using SSD's in clients, I don't see a huge advantage to ISA. Whether in incremental or full backup. It is a CPU hog and space hog. Maybe also duplicates processes already in place (in the case of APFS). I will compare again in 15.6 with ISA disabled to confirm this. Once turned off, intend to leave it that way. Locally, on HFS+ formatted (HDD) drives, maybe some advantage, but since the server does its thing quicker locally and is essentially unattended, I don't care too much. My 2¢... Henry

insont, That's good, because I just found a 15 May 2018 Knowledge Base article change confirming what you've been saying. The paragraph "Mac Customers: Please note that Instant Scan is not supported with APFS." has been added below the first paragraph in the KB article "Instant Scan Frequently Asked Questions". which is under the catch-all heading "Resources" in the KB . That first paragraph begins with the sentence "Retrospect 10 for Macintosh and Retrospect 8 for Windows introduced a new feature called Instant Scan." This section of the permalinked old version of the Wikipedia article says those versions were introduced in 2012, so the original article almost certainly dates from sometime shortly after that year up through April 2015—when the companion article "Instant Scan Advanced Options" was published. Sorry to have previously expressed doubt, Martin. Pretty sneaky announcement there, Retrospect Inc. ; you didn't even point Martin to it in your final reply to his Support Case.

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

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