Jump to content

DavidHertzberg

Members
  • Content count

    1,045
  • Joined

  • Last visited

  • Days Won

    38

Everything posted by DavidHertzberg

  1. DavidHertzberg

    No more instant scan on MacOS?

    insont/Martin, Those of us with long memories do know what Retrospect Inc.'s priorities were for Retrospect 16.0 as of March 2018. I could make you work by telling you to read the blue-tagged "New" items for the various Retrospect 15 releases in the cumulative Release Notes, but I'll try to make it easy for you—even though Product Management has done a pretty good job of hiding the 2018 historical record. The Retrospect Inc. developers announced that they intended to release these new features—some in beta form—in May 2018 for Retrospect 15.1. However their priorities were changed by the urgent need to provide "Data Retention Policies: file selector support for grooming for GDPR compliance", so those non-e-mail new features were not released until early September 2018 for Retrospect 15.5—as you can see. The apparent rush in which the engineers did that seems to have led to their inadvertently disabling several Retrospect capabilities that had previously worked. That led to two more bug-fix releases, and it wasn't until 29 November 2018 in the 15.6.1 release that the engineers fixed "Backup: Fixed issue where scripts hung due to Management Console integration (#7753)"—a havoc-causing bug that appears to have originated in the 15.6.0 release on 16 October 2018. Now we reach the 16.0 release on 5 March 2019. Look at the "Feature Set" section of this Knowledge Base article, and tell me with a straight face that the Shared Scripts feature isn't still in beta. As the last sentence of the next-to-last paragraph of the "History" section of the Wikipedia article—as well as several threads in the Windows Forums on this website—will tell you, a fully-functioning two-way Management Console is a feature that Retrospect Windows administrators have been pleading for for many years—a plea to which Retrospect Inc. planned to respond. Nevertheless the Management Console Add-On (referred to in the right-most listed item) which is a requirement for Shared Scripts, hasn't as of tonight made it into the Product Configurator so that administrators can purchase it online (here's my one piece of "inside information": the head of North American Retrospect Sales told me on the phone the day before yesterday that someone is working to add that Add-On to the Configurator). BTW, insont, have you noticed that my predictions up-thread, made without any "inside information", turned out to be pretty accurate? P.S.: You failed to consider the possibility of explanation [2a] per this up-thread post. You may not have them, but other users have external drives cabled to Macs of your vintages. macOS 10.14 Mojave does not force conversion of an HFS+ drive to APFS unless that drive is an SSD. Also, you had not previously said that your "razr" iMac had been upgraded to Mojave. Lastly, you failed to consider the difficulty (which I think the Retrospect Inc. engineers also failed to consider) of the API conversion documented in this KB article—a conversion that was partly forced on them by Apple's development of APFS. P.P.S.: Retrospect Inc. Product Management's "hiding the 2018 historical record", mentioned in my first paragraph, was done by overwriting Web pages written in 2018 with 2019 announcements.
  2. DavidHertzberg

    No more instant scan on MacOS?

    insont/Martin, Thank you for taking the time to investigate and write your immediately-above post, which is very informative. I will assume for the purposes of this post that both your "aftr8" and "razr" client Macs have their disks formatted with APFS. It seems that you are now leaning toward my explanation [2] in the second paragraph of this up-thread post. I propose to sub-divide that into two further possible explanations: [2a] Instant Scan can still be effective in version 16.0 for Mac disks formatted with HFS+, so the Retrospect Inc. engineers had to leave the "Instant Scan" option and the daemon in the Client—especially since a particular Mac "client" machine could have one disk formatted with HFS+ and another disk formatted with APFS. [2b] Instant Scan has been determined to no longer be useful for any Mac "client" disks, so it has been disabled in the Client code—but the engineers didn't have time to eliminate the daemon and/or the option. If you look at the succession of public announcements since the release of Retrospect 15.0 and "read between the lines", it seems that getting out version 16.0—with whatever deficiencies it still has—required a tremendous effort on the part of all employees of Retrospect Inc.. I suspect that a lot of those employees are catching up on their sleep this weekend; I hope the engineers are not waking up screaming. Niceties such as eliminating un-needed options and/or daemons will have to wait for a later "point release", especially since explanation [2a] would require that the daemon would have to be launched whenever the Mac Client finds itself backing up a disk formatted with HFS+.
  3. Version 16 has been released, and once again DovidBenAvraham has the same kind of problems with adding the new features to the Wikipedia articles that he had for Retrospect 15—as described in this up-thread post. The august Retrospect Inc. Documentation Committee has wiped out the previous contents of the User's Guide "What's New" chapter (as has been its practice since Retrospect Mac 13/Windows 11) and replaced it with new marketing fluff (as has been its practice since Retrospect 15), which DBA cannot use as a reference for the WP articles. Pending another TidBITS review, DBA can at least use this Knowledge Base article and this one as references for the Management Console—including the Shared Scripts Add-On feature. It's debatable whether the Deployment Tools are too nuts-and-bolts to deserve much of a mention in the WP articles, even though there are "White Paper" KB articles. But the real problem is the Storage Groups feature. The new KB article on Storage Groups leaves out a key detail, which may be because that part of the feature has not yet been developed. To quote part of my own post here: As the "Under the Hood" section of the KB article says "You can treat the Storage Group like a Backup Set that allows simultaneous writes to it." The "Data Deduplication" section of the KB article says "The architecture for Storage Groups allows simultaneous operations to the same destination because each volume is a different backup set under the hood. However, this workflow also prevents data deduplication across volumes." But what is the GUI for making the Storage Group pseudo-folder generate additional Media Set/Backup Set Catalog Files that are part of an existing Storage Group? Have the Retrospect Inc. engineers even developed such a GUI? And if they haven't, shouldn't DBA treat Storage Sets as he treated the 15.5 Management Console beta—as a Retrospect feature still under development that didn't yet belong in the Wikipedia articles?
  4. The short answer to your question appears to be: No, they won't have to be converted or rebuilt. (Please be aware that I have never done a paid minute of work for Retrospect Inc. or its predecessor companies.) However you raise an interesting point, which I should have noticed had I not been writing the P.S. you quote above in the early hours of the morning. Like a mathematical set, a Media Set is a concept—one that was (under the name of Backup Set, which is still used in Retrospect Windows) thought up by someone at Dantz Development Corp. more than 30 years ago—which exists only in the GUI. The physical embodiment of a Media Set is a Catalog File plus Member folders. A Storage Group, a concept new with Retrospect 16, is a set of Media Sets that the GUI treats for most purposes as if it were a single Media Set. The physical embodiment of a Storage Group is a pseudo-folder—by default within the Library -> Application Support -> Retrospect -> Catalogs folder—that encloses several Catalog Files and can somehow be made to generate more Catalog Files. The format of an individual Catalog File, as well as the format of a Media Set's Member folders and their contained backup files, has apparently not changed with Retrospect 16. The Retrospect Inc. engineer who wrote this Knowledge Base article was evidently trying to get this idea across when he/she wrote the "Under the Hood" and "Data Deduplication" sections at the bottom of the article. However IMHO he/she didn't do a good-enough job. One reason is that the engineer was trying to explain the Retrospect Windows GUI embodiment of Storage Groups, which (because the Roxio engineers chickened out on switching to the Retrospect Mac GUI and terminology when Retrospect Windows 8 was developed around 2010) is necessarily less transparent than the Retrospect Mac 16 embodiment. The other reason is that he/she was probably sleep-deprived when writing the article just before the release of the new version.
  5. like2backup, You can't have both versions installed on the same boot drive, but you can have them installed on different boot drives on the same Mac. You just have to use System Preferences -> Startup Disk to pre-designate which drive you are going to boot from after a Restart. If your "backup server" is a "cheesegrater" Mac Pro that is already booting under macOS 10.14 Mojave, that's the only way you'll be able to switch between boot disks—because Nvidia video cards won't work under Mojave and the hold-down-the Option-key-at-startup facility doesn't work for AMD video cards under Mojave. In my inherited Mac Pro (5,1) I currently have an SSD that runs Retrospect Mac 15.6.1.105, and a HDD that runs Retrospect Mac 14.6. I keep my only set of catalog files in Library -> Application Support -> Retrospect -> Catalogs on the HDD, and back them up with a separate Favorite Folder covering only that Catalogs folder—because I no longer back up the rest of that HDD. P.S.: The key fact here is that the format of Media Sets didn't change from Retrospect 14 to Retrospect 15, and—according to the cumulative Release Notes—didn't change from Retrospect 15 to Retrospect 16. The exception is the new Storage Groups feature, but if you're going to use one Storage Group for more than one backup script simultaneously it can only be for Proactive scripts—and those backups won't do data deduplication between the multiple disk or cloud Media Sets for which a Storage Group is merely a somewhat-transparent container.
  6. DavidHertzberg

    No more instant scan on MacOS?

    insont/martin, My guess is still what I said in this up-thread post, including the P.S.. From what I remember when I was using Retrospect Mac 14.6, the log used to say "Using Instant Scan" on the second or third line for each drive backed up—except for the 3 drives on my Digital Audio G4 which boots under OS X 10.3.9 (the Legacy Client doesn't do Instant Scan because FSEvents hadn't yet been implemented in OS X). When I upgraded to Retrospect Mac 15.6.1.105 in January 2019, the log stopped showing that line. Maybe the Retrospect Inc. engineers accidentally disabled the code that generates that log line, or maybe they intentionally disabled it so administrators backing up drives formatted with APFS wouldn't feel so disadvantaged. Because this Knowledge Base article says [the bolding is Retrospect Inc.'s] "Mac Customers: Please note that Instant Scan is not supported with APFS", and that article hasn't been updated since 15 May 2018. Are your Macintosh HD drives on both "after8" and "razr" both formatted with APFS? If they are, I see two possible explanations for the good news about the scan phase running so much faster: [1] The Retrospect Inc. engineers—likely with some help from Apple—got Instant Scan to work in Retrospect 16 for APFS-formatted drives, but the engineers have thus far not gotten around to updating the KB article. [2] What I quoted in my up-thread post has come to pass, and the ordinary scan phase as implemented with 64-bit APIs has turned out to be so much faster that the engineers have simply abolished Instant Scan for Macs—while keeping the "Retrospectinstantscan" process for sentimental reasons . Maybe Instant Scan on Mac HFS+ drives had to continually update its own indexes using FSEvents to access the filesystem logs, which would explain why your "Retrospectinstantscan" process is no longer using as much of the CPU; that would argue for explanation [1]. I still prefer explanation [2], including keeping "Retrospectinstantscan" for sentimental reasons. Please let us know about the scan phase timing of your subsequent Backup runs, and the CPU use of "Retrospectinstantscan" on your APFS-drive-formatted Macs. Meanwhile I'll try booting my "backup server" from the drive that still has Retrospect Mac 14.6 on it, so I can check my old logs for the "Using Instant Scan" line. P.S.: The reason I still favor explanation [2] in the second paragraph is that, since I upgraded to Retrospect Mac 15.6.1.105 in January 2019, my scan times have gone up from less than 5 minutes to nearly 10 minutes. I know this because I have for over two years been scheduling a "sacrificial" Backup script to run 5 minutes before each "real" Backup script, as a workaround for -530 Bug 1 occurrences for my MacBook Pro "client". Because the "sacrificial" scripts use the No Files Rule, they are basically just doing a scan and then building a Snapshot. The "sacrificial" scripts used to take around 5 minutes to run; they now take around 10 minutes. IMHO the time increase means that Instant Scan is no longer being used, even though it is specified for the MBP "client" and the MBP's boot drive—the only one backed up—is still formatted with HFS+ and booting macOS 10.13 High Sierra.
  7. mbennett and anybody else, "I dipped into the future, far as human eye could see". That's because Retrospect Inc. engineers put some of their new or revised Knowledge Base articles onto the website on 4 March, even though those KB articles are "last updated March 5, 2019". Anyway this KB article describes Shared Scripts, which appears to be the Retrospect Windows 16.0 approach to two-way communication between the Management Console and a Retrospect Engine—with one-way communication having already been revealed in the15.5 Preview version of the Console. The "Under The Hood" section of the KB article says "Retrospect Backup engines contact the Retrospect Management Console every 60 seconds to provide real-time status updates and fetch any management instructions. The Retrospect Management Console does not initiate or maintain an active connection to the engines." My somewhat-optimistic interpretation is that you could use the Shared Scripts facility to update an existing script on an Retrospect.exe engine, as well as add a new one, assuming the engine has the capability of recognizing that a Shared Script that has just been Saved in the Console should replace an existing script with the same name. However the "Feature Set" section of the KB article says "Note that as of March 5, 2019, deployment options are limited to ProactiveAI scripts with standard source containers ('All sources', 'All local', 'All clients', 'All network', 'All email') to cloud destinations with simple scheduling options. Support for local sources, local destinations including disk, scheduled scripts, and more extensive scheduling options will be available soon." Therefore many of you will have to wait until at least Retrospect Windows 16.1 to get the Management Console facility you need. IMHO the delay is partly a result of the fact that the Retrospect Inc. engineers cannot simply copy the code that is in the Retrospect Mac Console, because the GUIs in the two variants are so different. Nevertheless the general approach is along the lines of what I predicted in this post up-thread. The mandatory Windows security settings starting with Windows Vista/Server 2008 subsequently forbade UI interaction with an application auto-launched by a task, meaning that having the Engine contact the Retrospect Management Console every 60 seconds is the necessary Web-client workaround for Retrospect Windows. FYI the Retrospect Mac Console does not AFAIK have to have the same workaround, because macOS does not have the same mandatory security settings as Windows. P.S.: I neglected to mention last night that Shared Scripts requires the Management Console Add-On, a fact alluded to in marketing material but not mentioned in the KB article. I phoned Ian of Retrospect Sales this morning, and he says that Add-On is US$49 for Desktop Edition and other less-lowly Editions—but goes up to around US$450 for really-exalted Editions. (As one would expect in the rush to get version 16.0 out the door, the Product Configurator for either variant has not been updated to include that Add-On as of 2:15 p.m. New York time—which is well after Retrospect Inc. opening time in Walnut Creek CA—on 5 March. ) So two-way interaction between the Management Console and Retrospect.exe will have a price in Retrospect Windows (the non-Web Console supplied as part of Retrospect Mac has two-way interaction built-in), which you can blame on Messrs. Gates and/or Ballmer having had a religious conversion about Windows security. The e-mail I received a few minutes ago says "Retrospect Management Console is free for basic monitoring with a paid version for complete monitoring and management", which confirms what I've said in this P.S..
  8. mbennett and anybody else, "I dipped into the future, far as human eye could see". That's because Retrospect Inc. engineers put some of their new or revised Knowledge Base articles onto the website on 4 March, even though those KB articles are "last updated March 5, 2019". Anyway the last sentence in the first paragraph of my immediately-preceding post now has to be significantly qualified. This KB article now says "With Storage Groups, you can run parallel backups to the same disk destination with a single ProactiveAI script. Scheduled scripts support Storage Groups as destinations, but the backups run on a single execution and not in parallel." However the basic concept is that "Under the hood, a Storage Group is a container for per-volume backup sets. This architecture is why Retrospect allows you to keep the same workflows that you are accustomed to for backup, restore, transfer, grooming, and catalog rebuild, while providing far better performance and simplicity. You can treat the Storage Group like a Backup Set that allows simultaneous writes to it." The remainder of the KB article explains that the containerization is less transparent for the Retrospect Windows 16 GUI than it is for the Retrospect Mac 16 GUI. Eat your hearts out, Retrospect Windows administrators. For all of us, nevertheless, "The architecture for Storage Groups allows simultaneous operations to the same destination because each volume is a different backup set under the hood. However, this workflow also prevents data deduplication across volumes." BTW, those different backup sets must be either on disks or in the cloud; sorry, no Storage Groups for you tape enthusiasts.
  9. DavidHertzberg

    Can I safely downgrade from V15.61 to V12?

    x509, If you were in fact getting -530 errors on "a backup script that involved several volumes was backing up only one of the subvolumes, but if I did an immediate backup, everything worked fine", you may instead want to look at this post in the Mac 9+ Forum. I discovered two weeks ago that the real fix was to Remove and re-Add the "client" using Add Source Directly (using a fixed IP address). (Back in early January I thought that the fix resulted when I moved the corresponding Retrospect Mac configuration file to the desktop—causing it to be regenerated, but several weeks of systematic testing convinced me that the seeming fix in early January really resulted because when I re-Added my "clients"—which regenerating the config file forced me to do—I re-Added them using Add Source Directly.) The third bulleted list item in the post I linked to in the first paragraph of this post explains what Use Multicast means. The "Piton protocol" it refers to is explained on pages 290-291 of the Retrospect Windows 15 User's Guide, so it's not peculiar to Retrospect Mac. As I asked in the last paragraph of the linked-to post, for you—or for other administrators who have "clients" either connecting for Proactive backups or connecting to the "backup server" over WiFi: does the LAN IP address of those "clients" change?
  10. Executive Summary of this post (15.6.1.105 on "backup server" and MacBook Pro Client; MBP now booting under macOS 10.13 High Sierra, Mac Pro "backup server" still booting under macOS 10.12 Sierra): For MBP "client", I get a -530 Bug 1 (first script fails if "backup server" booted after script's scheduled time) and -530 Bug 2 (second script also fails if "backup server" booted after script's scheduled time, even if first "sacrificial" script failed) when MBP "client" was Added with Use Multicast. For MBP "client", I get no -530 Bugs under same circumstances when MBP "client" was Added with Add Source Directly (using fixed IP address). This persisted for 3 weeks, so -530 Bug 3 (-530 Bugs 1 and/or 2 reappear a week or two after MBP "client" Removed and re-Added after Client reinstalled on MBP) may have been fixed—or apparent config corruption doesn't occur when Client re-Added with Add Source Directly. Use Multicast refers to Retrospect's use of its proprietary "Piton protocol" over assigned multicast address 224.1.0.38. This enables an enterprise's "backup administrator" to Add new "client" machines to be backed up over the enterprise LAN, even though the "backup administrator" doesn't have the training required of a member of the IT staff (explained in the last sentence in the first paragraph here). The "backup administrator" doesn't have to know anything about a "client" machine's IP address, only to be able to recognize its unique name as known on the LAN. Once a "client" is Added, communication between its Client software and the "backup server" takes place over well-known port 497; if this communication fails for a "client"—possibly because of a LAN IP address change, the "backup server" sends out another "Piton protocol" request in order to update its "client" database. The "Piton protocol", which was developed shortly after 2000, is one of the features that makes Retrospect easy for an enterprise to keep using—without the aid of a trained member of the IT staff or a consultant. Those of you administrators who have "clients" either connecting for Proactive backups or connecting to the "backup server" over WiFi: does the LAN IP address of those "clients" change?
  11. BTW, what may either be a Retrospect feature (designed to prevent inadvertent double-submission of the same script scheduled twice in succession) or another Retrospect bug exists. I discovered it when testing by scheduling two Repeat Never runs of the same "sacrificial" script scheduled 5 minutes apart, then shutting down my "backup server" and re-booting the "backup server" at least 15 minutes after the scheduled time for the first run. The second scheduled run had disappeared from the Activities list. I was scheduling the "sacrificial" script twice in succession because the "real" script—which does not use the No Files Rule—would have run 15 minutes longer.
  12. DavidHertzberg

    Selector doesn't work for only 1 Backup Script

    x509, Think about what changed about a week ago. Did you update Windows to a new version? Some other change?
  13. DavidHertzberg

    Selector doesn't work for only 1 Backup Script

    x509, I am a Retrospect Mac administrator, as you know, so the suggestion in the next paragraph may not be worth anything. This 2009 thread has something to say about System Volume Information, and this 2018 thread has something to say about the Program Files directory—which seems to be somewhat analogous. What IMHO makes the directories analogous is that they both sound like what Retrospect may define as Special Folders (Windows). That is among the Windows Selector Conditions defined on page 437 of the Retrospect Windows 15 User's Guide. I don't know how to use such conditions in a Selector, so someone more familiar with Retrospect Windows is going to have to advise.
  14. My bug-fix celebration in this post up-thread turns out to have been at least partially premature. When—as promised after 3 weeks in the second paragraph—I switched to Use Multicast instead of Add Source Directly (using a fixed IP address), I got a -530 error when I scheduled a run of my daily "sacrificial" script for 5 minutes in the future and then shut down my "backup server" for 20 minutes. This means that my -530 Bug 1 still exists when my "client" MacBook Pro has been Removed and then Added with Use Multicast. My -530 Bug 2 may have actually been fixed, because the "sacrificial" script run failed almost immediately instead of continuing to try to find the MBP. To test whether -530 Bug 2 had been fixed I would have to schedule two "sacrificial" script runs in a row; if the first run failed immediately but the second one ran, it would mean that -530 Bug 2 has been fixed. I hadn't done that because I was over-optimistic, and I didn't have time for a do-over without interfering with my end-of-workweek backup script runs. Instead I Removed my "client" machines and re-Added them with Add Source Directly. I'll try that two-run test tomorrow or Monday. If anyone else installs Retrospect Mac 15.6.1 (105) and wants to try the -530 bug fix that belatedly turned out to work for me, they'll need to modify step [3] in the fourth paragraph of the up-thread post to say "re-Add any 'client' machines to Sources with Add Source Directly (using a fixed IP address defined to the router) ....".
  15. Sorry, henry-in-florida, I guess I was a bit crabby because I had forgotten that Refresh is supposed to update the list of Source volumes for a "client". Here's a 2016 OP by jelockwood saying it didn't work. Thanks for filing a Support Case, assuming you did so. As I have said several times on these Forums, I am not now doing nor have I ever done any paid work for Retrospect Inc. or its predecessors. I don't even play a Retrospect Inc. employee on TV. So I didn't have anything to do with what is apparently a new version of the Forums software. In fact, I preferred the old version—which automatically numbered posts in a thread and had more-accessible Search options. Here are the "obscure mnemonics" I remember having used, all of which are pretty-standard Internet forums slang: IMHO : In My Humble Opinion IME: In My Experience HDD: Hard Disk Drive AFAICT: As Far As I Can Tell AFAIK: As Far As I Know IANAL: I Am Not A Lawyer OP: Original Post in a thread or Original Poster in a thread RTFM: Read The F**king Manual OTOH: On The Other Hand BTW: By The Way
  16. 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.
  17. 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. P.P.S.: What I predicted seems to have come to pass with the release of Retrospect Mac 16.0 on 5 March 2019. First, the cumulative Release Notes say for Engine "Improved: Scanning faster on APFS volumes" and for Client "Improved Mac: Client scanning faster on APFS volumes". Second, the cumulative Release Notes also say for Client "Alert Mac: EOL notice for Apple Mac OS X 10.3. 10.4, and 10.5 - See details"—where the details are the temporarily-hidden updated version of the Knowledge base article I linked to up-thread which says "Now that the transition to 64-bit macOS file system data structures is complete, Retrospect can no longer support 10.3, 10.4, and 10.5 with the Retrospect 6.3 Client and Retrospect 9.0 Client."
  18. 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."
  19. 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).
  20. 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.
  21. 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.
  22. 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.
  23. 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."
  24. 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.
  25. DavidHertzberg

    Dashboard empty

    Lennart_T and myhrik, Here's another thought I just had, inspired by the fact that both of you are Scandinavians: Your English is excellent, but do you actually use Retrospect Mac in a different language version—such as German? My impression is that the Retrospect engineers are really rushing to get the Management Console out of beta, especially after the delay caused by their having had to concentrate on GDPR for 15.1. Considering the foul-ups in 15.5 and 15.6.0—where the engineers evidently didn't test existing features to see if those still worked, I imagine it's possible that they didn't test the non-Management-Console Dashboard in languages other than English. Come to think of it, here and here are threads whose OP goes by the Forums "handle" johanvos; the first thread is specifically about a Dashboard problem, and the second thread may be. Given his "handle" and his less-than-perfect English, I'll bet johanvos actually uses the German version of Retrospect Mac.
×