Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. C'mon, henry-in-florida, you ought to know by now that you need to give your version of Retrospect and the version of macOS you're running it under when you start a Forums thread. I had to look at your attached log file to see that you are running Retrospect Mac 15.6.1.105, and I still don't know whether you are running it under macOS 10.13 High Sierra or 10.14 Mojave. You shouldn't make us work that hard. On pages 62-63 of the Retrospect Mac 15 User's Guide, paragraph 3 for Refresh says: So there's a bug in the latest version; you know why and how to create a Support Case. Did Refresh ever actually work this way? Until Retrospect Inc. engineers fix the bug, IMHO you'd be better off Removing and then Adding your "client" Source, checkmarking the volumes you want backed up per this post, and then re-checkmarking the "client" in the Sources tab of each appropriate Script and—after Saving—dragging the "client" into the appropriate sequence in the Summary tab of that Script and Saving again. Your workaround in item 5 of the OP may have done the job, but it probably took more time than what I've said in the preceding sentence.
  3. Last week
  4. Found that when I changed the name of the source drive, even if the sources are refreshed to recognize those new source names, subsequent backups seem to revert the sources to what they were and then the backups fail because that device no longer exists. My workaround was to refresh the source list and then immediately run a script using those devices. Somehow that seems to work... For now. Here's the step by step in case you want to reproduce: Change the source name ( in my case I'd reformatted the source drive in APFS and renamed it) of a device in the Retrospect Multi-Server backup plan. Go to Retrospect and refresh the source computer to register the names of the drives. Wait 24 hours. Run the backup script with the sources. The source names revert over time (and running other automated backups) to the old names ALL BY ITSELF, those new source names previously existing in the dropdown list disappear, the old names replace them and any backup scripts using the old drive source names obviously will continue to fail, lacking manual intervention. After the workaround above- reset the source list by refreshing sources (Sources>select the source machine>Refresh) and immediately perform a backup. N.B., two anomalies reading through the log. The log shows "First Access" for the device "GenieMBP", even though previous backups of the device WERE COMPLETED previously that same day. Guess it means first access of those SOURCE DRIVES? The script also changed the source drive to something that existed ALL BY ITSELF during previous backups (Macintosh HD) prior to failing on the missing drives. Retrospect log_190219.rtf
  5. DavidHertzberg

    No more instant scan on MacOS?

    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 we won't miss Instant Scan. P.S.: I even have hopes that the speed of actual Mac Client data backup will increase with Retrospect 16, because of the changeover to 64-bit APIs. This February 2018 post by dittberner@dbr3.de says he got much faster backup of his Windows server files when he switched from Retrospect Mac to another application; he says further down the thread "The other product is not comparable (much more expensive and other functions)." dittberner@dbr3.de later PM'd me (signing it with his male first name) the name of the other client-server backup application; its developer was founded 18 years after Dantz Development Corp., and its 64-bit application—meaning it won't back up sources booted with anything earlier than OS X 10.8—"is ideal for businesses in the Media and Entertainment industry". IOW, my hypothesis in this February 2018 post in the dittberner@dbr3.de thread seems to be true only if you assume that the client-server application stays with the same set of APIs—rather than change its APIs from 32-bit to 64-bit.
  6. DavidHertzberg, thank you for the detailed information. I have filed a support case and hope the March 6 upgrade to v. 16 (or v.16.1) will be helpful in speeding up Instant Scan and other backups.
  7. DavidHertzberg

    No more instant scan on MacOS?

    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."
  8. Lennart_T

    Error -1104 (device not ready)

    From the error it looks like it is your C: drive that causes the problem ("can't read error"). If it was the destination, the error should say "can't write error" or something like that. I would check the C: drive, both the S.M.A.R.T. status as well as doing a surface scan. (Windows CHKDSK does not do a surface scan.)
  9. freddo7

    Error -1104 (device not ready)

    Just an update to my topic. I had the Ext HD connected to the following device: [2nd Gen]TP-Link 9-Port USB 3.0 Hub with 7 USB 3.0 Data Ports and 2 Smart Charging USB Ports. Compatible with Windows, Mac, Chrome & Linux OS, with Power On/Off Button (UH720) I decided to run the back up job connected directly to the computer and it completed and it is currently comparing the back up. So it may an issue of the hub. The hub is A/C powered.
  10. O/S - Windows 10 Home 64 bit Retrospect 12.6.1 Desktop for Windows. Back up device - Western Digital Elements (3TB) I got the following error message for an incomplete back up. Could the issue lie with the external hard drive? - Fred + Executing Immediate Backup at 2/17/2019 14:40 2/17/2019 14:40:23: Finished scanning backup set data files To Backup Set Backup Set H... - 2/17/2019 14:40:22: Copying Windows (C:) 2/17/2019 14:41:31: Found: 311,602 files, 52,167 folders, 158.8 GB 2/17/2019 14:41:31: Finished matching 2/17/2019 14:41:33: Copying: 244,513 files (149.2 GB) and 67,088 hard links [*] --ERR-- (18044) BackupReadCloseAsync: err=-1104 File "C:\Users\freis\Google Drive\Yes Montreux Video Project\Montreux Sessions\DVD - NTSC\Yes Montreux Sessions 2016 Edition DVD NTSC\VIDEO_TS\VTS_02_1.VOB": can't read, error -1104 (device not ready) Trouble reading files, error -1104 (device not ready) 2/17/2019 15:30:04: Execution incomplete Remaining: 112110 files, 57.9 GB Completed: 132403 files, 91.4 GB Performance: 1934.7 MB/minute Duration: 00:49:41 (00:01:18 idle/loading/preparing)
  11. DavidHertzberg

    Automating cleaning tapes

    CherylB, Assuming you are using Retrospect Mac 15, try reading "Storage Devices" on pages 38-41 of the Retrospect Mac 15 User's Guide, and doing what it says for Clean Drive After ... in the "Options" paragraph on pages 40-41. What documentation did you read in which "The documentation says you control click on the drive and set it there"? BTW, if you haven't upgraded to Retrospect Mac 15.6.1.105 for both your "backup server" and your Mac Retrospect Client(s), you should do so. Prior point releases of this software don't have all the features, and in particular 15.5 and 15.6.0 are "bad releases" in which previously-working facilities stopped working properly. As I've said in another thread, this doesn't mean you won't get slow scans of APFS drives until at least Retrospect Mac 16 is released—and you should disable Instant Scan for APFS drives (see newly-added second paragraph).
  12. DavidHertzberg

    No more instant scan on MacOS?

    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.
  13. Retrospect documentation says you should be able to configure the system to clean tape drives after every 400 hours of use. The documentation says you control click on the drive and set it there but there is no option to select for auto cleaning. Where can I find more information on configuring this automatic feature? Thanks for any suggestions.
  14. Martin is definitely not the only one experiencing over-lengthy backups. We use incremental backups and the instant scanning often takes multiple hours and sometimes overnight. I will discuss this with our team and try turning off ISA but am hoping the release of v.16 repairs this.
  15. David, That was truly horrible. /Martin
  16. 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.
  17. DavidHertzberg

    No more instant scan on MacOS?

    insont, You are evidently not a programmer, at least not one who has worked on complicated applications that keep several programmers busy. Although I have never worked for Retrospect Inc. or its predecessor organizations, I'm reasonably sure that changing every single Mac-related API structure and call in both the Engine and Client programs is a big job. That's why this Knowledge Base article is dated 23 May 2018. Therefore it's not surprising that the changes will be introduced with the release of Retrospect 16, which—if past years are a guide for major releases—will be in early March 2019. Your complaining about the amount of time the change is taking won't make it happen any faster. I'm curious; do you practice this technique with your fellow workers and friends? Does it produce results, or does it just give you the reputation of being a pain in the a**e? As I've pointed out in my "boilerplate" posts on filing a Support Case, Retrospect Inc. people don't normally read these Forums. I seriously suggest that you consider switching to the "push" backup application you have mentioned in this thread, so you can try this method of interaction on Stefan Reitshamer. And, since its a "personal" backup application, good luck in on getting your "backup server" device to not overload when 7 different "client" machines try to backup to one destination at the same time.
  18. Earlier
  19. 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.
  20. DavidHertzberg

    No more instant scan on MacOS?

    insont, Allright, allready, Retrospect doesn't implement Instant Scan for APFS volumes—as I pointed out in this post in the thread. The "push" backup application you mention no longer implements Instant Scan using Mac fsevents at all, as someone who is pretty obviously Stefan Reitshamer said on Twitter in 2016 (which is before Apple introduced APFS). I've already pointed out Retrospect Inc.'s expressed intention to speed up overall backup—probably in Retrospect 16—in this post just above your latest two posts in the thread. IIRC the "push" backup application you mention by default doesn't back up all the files that Retrospect does. But I'm too busy to Google for that now. I have now confirmed that Retrospect used to be able to backup to an SFTP/FTP destination, but abandoned that in Retrospect Mac 8 in favor of a WebDAV destination and an AFP/SMB destination—announced in the UG for Retrospect Mac 10. In a 2012 blog post Retrospect Inc.'s then-Director of Marketing said "SFTP/FTP is just not a good protocol for backups .... doesn't support mid-point file access—so Retrospect would need to download the entire container file just to restore a single file from the backup .... As a result, Retrospect 6 needs to write much smaller container files, which generates additional overhead and complexity, and reduces performance." Remember that Retrospect is an enterprise client-server backup application, which gives it different requirements from a "personal push" backup application. However this Knowledge Base article says, as of 2017, that FTP/SFTP can be a R.V. backup destination—so maybe you should switch to that product if your "backup server" runs Windows and you're willing to do without "client" backup. P.S.: Corrected first sentence of 3rd paragraph to say that FTP destinations were dropped in Retrospect Mac 8 and AFP/SMB destinations were added in Retrospect Mac 10, with WebDAV destinations added in Retrospect Mac 9 (for which there is no UG—only an Addendum). P.P.S.: Replaced second sentence of 3rd paragraph, because I found Kristin Goedert's 2012 Retrospect Blog post.
  21. 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.
  22. 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
  23. Nigel Smith

    Cannot "move" disk media set

    The RAID itself shouldn't go to sleep. The disks will spin down, but the card itself should remain active and the volume should stay mounted on the Mac. Is it possible that the Mac itself went to sleep (if it happens again, check the OS logs for the sleep event)? I wouldn't set any backup server to auto-sleep, just to be sure (let the display sleep if one is attached, but not the computer) and would just do it manually if e.g. I had no backups to do over the weekend. I'm all for energy saving, but not when it turns an important system into a flakey one! 🙂 If it's not set to sleep then you are down to normal troubleshooting. AFAIK (David? Lennart?) Retrospect accesses an external volume via OS calls rather than directly as it does with tape drives. So you can test with Finder copies of similar size or larger as the first step.
  24. DavidHertzberg

    No more instant scan on MacOS?

    insont, What you are saying about a competing "push" backup application is actually good news, because IMHO it means that Stefan Reitshamer has been able to speed up APFS backup. The reason for the speed difference is that, since Reitshamer's application was developed much more recently than Retrospect, it undoubtedly uses 64-bit structures rather than the 32-bit ones that Retrospect still uses as of Mac version 15. Retrospect is apparently going to switch to 64-bit structures as of Mac version 16, which is why the engineers created this KB article. As I've pointed out here, especially in the P.S., the consequent tradeoff loss of Instant Scan will probably—by itself—add 10% to the duration of backing up a modern Mac. However that 10% may well be more than overcome by the increased speed of backing up made possible by the switch to 64-bit data structures. I'd wait until the release of 16.0, probably in March, to see what the results are. Even better, I'd wait until the release of 16.1 later this spring—to give the engineers time to fix the inevitable early-discovery bugs. P.S.: A reason for Retrospect Inc. to have stuck with the 32-bit structures is that it enables Retrospect Mac to do backups and restores of PowerPC Macs that can't boot from anything past OS X 10.5. This has been a critical requirement for administrators (including me) who have old files that can only be read by programs that can't be run on an Intel Mac. That explains why the KB article linked-to in the last sentence of the first paragraph of this post says "If you would like to protect those versions of Mac OS X with Retrospect 15, please contact our Support team for a production build that continues to include support for those."
  25. I recently upgraded from Retrospect Desktop 11.5 to 15.6.1. Everything seems to be working, but I see these strange errors in the LOG, after each backup script is performed: Usually just this: [*] UPreventSystemSleep: IOPMAssertionCreateWithName failed, err = -536,870,208 Sometimes this: [*] soccSend: send failed, err 32 [*] Captured signal SIGPIPE! [*] UPreventSystemSleep: IOPMAssertionCreateWithName failed, err = -536,870,208 Any idea what these mean? I do have it set to send me emails after each script is run, and I am getting them, so I don't know if it has to do with emailing.
  26. 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
  27. DavidHertzberg

    Dashboard empty

    Lennart_T and myhrik, Here's a further quick thought on why the Dashboard works on my "backup server" and not on yours: My "backup server" Mac Pro is still running macOS 10.12 Sierra. That's because I read that macOS 10.13 High Sierra is a bit flaky even in 10.13.6, and I'm not ready to upgrade to macOS 10.14 Mojave—because I've read that it will unavoidably convert my boot drive from HFS+ to APFS. It's inconceivable to me that the Retrospect Inc. engineers are not testing with Mojave, unless they're afraid to add Mojave problems on top of Management Console problems. I'm also not suggesting that you downgrade.
  28. It was a data recovery tool named DiskDrill.
  1. Load more activity
×