Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by DavidHertzberg

  1. DavidHertzberg

    Yet another -530 client not found error

    I am in fact doing what Nigel Smith calls "belt-and-brace" ("braces" are British English for what the rest of us call "suspenders") ; I have entries both in my router's MAC table and my MacBook Pro's System Preferences->Network->Locations for both my Moshi USB-C-to-Ethernet adapter port (X.Y.Z.201) and my CalDigit TS3 Plus Ethernet port (X.Y.Z.202)—X and Y and Z are "seekrit" numbers you couldn't đŸ€Ł possibly guess.. My "Automatic" Location has the CalDigit port enabled, and my "Retrospect Priority" Location has the Moshi port enabled. On my Retrospect Mac 16.6 "backup server", the Source for the MBP is defined with Add Source Directly as X.Y.Z.201—and my MBP usually uses the "Retrospect Priority" Location although the "Automatic" Location would give me slightly-faster Ethernet via Thunderbolt 3. Yesterday afternoon I did a couple of tests, using my handy-dandy NoOpSun-FriBackup script with the No Files Rule (Selector in Retrospect Windows). I first switched my MBP to the "Automatic" location and ran the script, which immediately issued a -519 error for the MBP. (That error number is an argument for my side in the 6-months-back dispute with Nigel Smith over whether the "backup server" uses the multicast Piton Protocol in finding a Source defined with a correct MAC address using Add Source Directly. My "backup server" would have found the MBP by name if it had used the Piton Protocol, or it would have issued a -530 error.) I then switched my MBP's Location to "Retrospect Priority" and reran the script. It started to run fine, until I too-rapidly shut down the MBP while the script was still making its 4-minute run—eliciting a "backup server" -519 error. (Point for Nigel Smith in the 6-months-back dispute; "the client was found, then disappeared".) Getting back to Nigel Smith's final warning, x509 should certainly find out what range for fixed IPs his router allows. I believe I checked the manual for my ancient Verizon Quantum G1100 "gateway", but I simply set up fixed IP addresses starting with X.Y.Z.200.
  2. DavidHertzberg

    Yet another -530 client not found error

    x509, I did a little Googling, and—just below the heading "How to assign static IP address using Settings" [my emphasis] on this Pureinfotech article on "How to set a static IP address on Windows 10"—is a section "Assigning static IP address for Wi-Fi adapter". So you wouldn't have to do scripting or get into your router's assignments table, but—from what you and mbennett have said up-thread—a Windows update might silently reset any such settings. Everyone, I went searching for this because I couldn't believe that modern Windows doesn't have the equivalent of the System Preferences->Network->Location dialog in macOS, for x509 to use with his Wi-Fi. This facility was developed in OS X to provide for Mac laptops that might be moved to different locations (hence the name) having different LANs, and is available as far back as my ex-wife's ancient Digital Audio G4 booting 2003's "Panther" OS X 10.3. Although my MacBook Pro never leaves my study desk, I discovered Location after I bought a CalDigit Thunderbolt Station 3 Plus dock to connect it via a KVM switch to a an external monitor. When my Apple 27-inch LED Cinema Display loses the video signal, it goes into a "deep sleep" mode—and needs to be "goosed" to wake up. If my KVM switch is still set to take input from the CalDigit dock, it has lost the DisplayPort video because I shut down the MacBook Pro the input was indirectly coming from—so rebooting the MBP results in the dock "goosing" the monitor. If OTOH my KVM switch was formerly set to take input from the G4 via converted DVI, it has lost the DisplayPort video because I switched it to an awake MBP—and only rebooting the dock results in the dock "goosing" the monitor. In that second case I originally found that detaching and re-attaching either end of the Thunderbolt 3 cable between the MBP and the dock was sufficient to reboot the dock—as was unplugging and re-inserting the dock's power cord, but a woman at Apple Tech Support suggested that a method which wouldn't violate any mechanical port-insertion limits would be to plug the dock into a surge protector whose sturdy switch I could use to reboot the dock—so I'm doing it. This created a problem with using Retrospect to simultaneously Recycle backup my MBP—using version 16 and an Ethernet connection wired via MoCA (inter-room Wi-Fi is slow in my apartment) to a "backup server" in another room—and my G4—using version 6.1 and a DAT tape drive SCSI-cabled directly to the G4. Using the KVM switch to switch the Cinema Display from the MBP to the G4 works fine, because the G4 automatically "gooses" the monitor out of "deep sleep". However using the KVM switch to switch the Cinema Display from the G4 to the MBP was killing the MBP's backup, because power-cycling the CalDigit dock was interrupting its Ethernet connection. My solution was to create a Location named "Retrospect Priority" in addition to the "Automatic" one. In "Retrospect Priority" the MBP's Ethernet connection is via a Moshi USB-C-to-Ethernet adapter (used with iffy StarTech USB32DPPRO before CalDigit), and the Ethernet connection through the dock is disabled—so power-cycling the CalDigit won't interrupt the MBP's Ethernet connection. I took the trouble to explain this because, now that external docks are becoming popular, other administrators with DisplayPort or Thunderbolt 3 monitors in their installations may have similar problems. The "deep sleep" feature is common to many such monitors—not just Apple's, and represents monitor manufacturers taking advantage of a DisplayPort (and Thunderbolt 3, which merges DisplayPort + PCIe + DC power) characteristic to lengthen monitor life—ignoring DP cable swappers and KVM switchers. HDMI monitors also have a "deep sleep" feature, but it can be disabled in some models.
  3. DavidHertzberg

    Retrospect 17 and low-end users

    Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. x509, The x.5 release of major version x is usually in late August or early September, and includes new Retrospect features. The fact that 17.0.2, consisting of bug fixes for big installations, was released in mid-May means IMHO there isn't going to be a release 17.1; I'd love to be proven wrong in this. My information is that engineers are hard at work on the variant of the "backup server" running on (beefed-up?) Drobo hardware ï»ż (and possibly other Linux-based NASes), because it sounds as if that's the main reason StorCentric bought Retrospect Inc.. If OTOH you're looking for improvements in the Client programs that would overcome the -530 problem and difficulties with Windows 10, my feeling is that Retrospect "Inc." engineers won't be allowed to put in that effort until StorCentric management sees the Drobo variant of the "backup server" operating in 17.5 trying to backup Windows "clients"—and realizes that there are serious Client problems for some administrators. So my expectation is that we won't see the kind of upgrade you—and for that matter I personally—want until the release of Retrospect 18.0 in March 2021, or possibly a release 17.6 in December 2020. Sorry to be so pessimistic. 😒
  4. DavidHertzberg

    Applicability of v17 fixes to earlier releases

    rfajman, It's first worth noting that two Engine improvements in Retrospect 17.0.0 are for "10x Faster ProactiveAI" and "Restore Preflight". Years ago you were talking about using Proactive, and administrators have been screaming for Restore Preflight for years. Three out of the four Engine improvements in 17.0.1 are for Remote Backup—which was a new feature in 2018 but has suddenly received administrator attention because of COVID-19 Work From Home, and the other Engine improvement is for Restore Preflight. Second, let us consider the 17.0.1 bug fixes that doubtless apply to earlier major versions of Retrospect Windows—as per the cumulative Release Notes. These are easy to identify, because bug #8547 is a "milestone" that was identified by Tech Support the same day 17.0.0 was released (it's debugging code that was erroneously left in on 3 March). There are 14 bug fixes in 17.0.1 with numbers lower than 8547; these must fix bugs in 16.6 and earlier. Other than #8547 itself, that leaves 16 bug fixes in 17.0.1 that may be for bugs introduced in 17.0.0; OTOH they may instead be for later-discovered bugs in earlier major versions. Of these, 7 bug fixes are for Storage Groups, a feature designed to work with Proactive that was not changed in 17.0.0. Of the remaining 9 bug fixes, 1 was for NAS Shares (3 "fixes" in 17.0.0) and 2 were for ProactiveAI and 1 was for Restore Preflight. That leaves 5 remaining bug fixes for Backup and Install and Configuration and Rebuild, which could have been for bugs introduced in the course of un-noted 17.0.0 changes. So the short answer is that at least 21 bug fixes out of 31 in 17.0.1 also apply to earlier versions of Retrospect, not bugs introduced in 17.0.0.
  5. DavidHertzberg

    Retrospect 17 and low-end users

    rfajman, I looked at your posting history, which you can get to by first clicking the green circular icon containing 'R' (in your case) to the left of any of your posts and then clicking "See their activity". You asked this question for both Retrospect Windows 15 and Retrospect Windows 16. Your were also at one time talking about using ProactiveAI scripts, which were substantially speeded-up for finding the next-available source computer in Retrospect Windows 17.0.0. BTW, cloud backup is a feature added in Retrospect Windows 12; that's 4 major releases ago.. For some of us, March 2016 isn't "relatively recently". đŸ€Ł P.S.: If you're not using Proactive (and you're almost certainly not using Remote Backup), the new feature that would be useful to you might be added in 17.5. As I said in this post in another thread, it looks as if Product Management decided "there's no possibility certain new major features are going to be ready in another week, so let's 'quick-ship' a 17.0 release containing bug fixes plus the three new features that are ready—and then follow up ASAP with a 17.1 or 17.5 release with the other new features." You may not appreciate one future major new feature, which IMHO will likely be a rewrite of the 1990s-designed and klunky built-in GUI for the Retrospect Windows "backup server". But lots of other administrators have complained about that GUI, so they'll probably feel a new one—which ditches Auto Launching and ditches a separate GUI for Immediate operations—is an improvement. It would end the need for two greatly-different User's Guides for the Windows and Mac variants of Retrospect. The real reason IMHO: similar-look GUIs will aid a variant of the "backup server" running on (beefed-up) Drobo hardware (and possibly other Linux-based NASes)—which StorCentric's top management has said it wants, controlled by a GUI Console running similarly on Windows or Mac machines on the same LAN and connected to the "backup server" via a NAS webserver.
  6. Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. denno, Storage Groups were previewed in the fall of 2018, and officially released in March 2019. I was given a feature justification shown in the third paragraph in this March 2019 post, but that justification omitted a key sub-feature that is still IMHO inadequately documented in the Knowledge Base article—which has been recently copied into the User's Guides. That sub-feature, not described in the Forums until this April 2020 post, is that "parallel backups" means a single Proactive script can be simultaneously backing up as many as 16 combinations of machine and drive to different Media Set components of its destination Storage Group. This is IMHO a really clever riposte—using the multi-threading power of a modern "backup server" machine—to other more-complicated (and more-expensive) client-server backup applications. Those require an installation needing equivalent multi-threaded random backup to interpose "appliances" resembling Airport Time Capsules (not necessarily using WiFi ) in between those "clients" and a "backup server" that backs up the "appliances"—backed up to on multiple "clients" own schedules—via periodically-run scripts . As shown especially in the Retrospect Windows cumulative Release Notes, the engineers have since been busy fixing Storage Groups bugs—most of them no doubt pointed out in administrators' Support Cases. The problem is that the engineers haven't as yet provided any Retrospect Mac GUI for accessing component Media Sets of an existing Storage Group—as they have for Retrospect Windows, except for using custom Rules/Selectors in operations that can be scripted (i.e. not Rebuild). They may have planned to provide that GUI in the fall of 2019, but any such plans were upended by the StorCentric acquisition on 25 June 2019. StorCentric upper management has publicly announced it intends to build a Retrospect "backup server" that runs on at least a beefed-up Drobo version of a Linux-booting NAS, and my information is that Retrospect engineers are busily at work implementing that. Since NASes don't have their own monitors and keyboards and pointing devices, it's obvious a NAS "backup server" will have to be accompanied by a Mac and Windows Console that connects to it over a LAN using (probably) a Web server on the NAS. Lo and behold, a Retrospect Console Preview was released on 3 December 2019—looking rather like a dumbed-down existing Mac LAN Console but also running directly on a Retrospect Windows "backup server" (where IMHO it'll be better when fully implemented than the 1990s-designed built-in GUI). It doesn't take great "tea leaf reading" skills to predict that it's unlikely further enhancements are going to be made this year to the Retrospect Mac Console GUI. So—if you want to use Storage Groups—you'll for now have to live within the confines of the existing half-baked GUI. Until Retrospect 16 killed the Legacy Client, I was backing up 4 drives in two "client" machines plus two local drives and a Favorite Folder onto three rotated-weekly portable disk Media Sets. Now I'm instead backing up the 3 drives on my old G4 Digital Audio machine to 3 rotated-weekly DAT tape Backup Sets, using Retrospect Mac 6.1. I have a home installation, and I rotate a portable disk and a DAT tape off-site once a week; YMMV. Would describing your "problems with my existing media sets" get you better answers?
  7. denno, Why are you using a Storage Group? Are you backing up many machines, and want the backups to be on separate Media Sets but can't be bothered to set them up along with separate scripts? Or are you using a Proactive script, especially with Remote Backup, and want the backups of individual machines to run in parallel? Otherwise don't use a Storage Group! 😟 The feature was originated in 2018, and evidently was not much used by administrators until COVID-19 Work From Home. Its GUI, especially in Retrospect Mac, is half-baked (3rd linked paragraph)—probably because the engineers had other features to develop. As to your problem, I don't have time to run a test. However, based on my previous testing and knowledge of pages 34-45 of the Retrospect Mac 17 User's Guide—which are essentially a copy of a Knowledge Base article, backing up to a Storage Group creates a component Media Set—if it doesn't already exist in the Storage Group—for each combination of source machine and drive. I'd guess that it also creates a component Media Set for a Favorite Folder on a source drive that is used as a Backup source. I suspect you have or had such a Favorite Folder, and it is or was for the Users/jrubin folder on your Macintosh HD. It sounds as if that directory was deleted on the Macintosh HD disk—or its physical Catalog was deleted in the "Main Backup Media Set A" Catalog folder, without deleting its component Media Set within "Main Backup Media Set A"—which you can't do in the half-baked Storage Group GUI. OTOH it's possible Retrospect Mac 17.0.2 has a bug when it tries to compress a Storage Group containing a component Media Set created from a Favorite Folder. Here's why and how to file a Support Case for a bug, although it could also be formulated as a feature request for fully-baking the Storage Group GUI. BTW, if you don't like getting -1101 Backup errors for your Backblaze.bzpkg files, you can create a Custom Rule (pages 176–179 of the UG) that excludes them from your Backup scripts. This Ask Different thread recommends doing the equivalent exclusion from Time Machine backups. P.S.: I did eventually run a couple of tests, and it looks as if you manually deleted something. Both my tests were of backing up an old HDD locally installed on my "backup server", to a testing Storage Group whose members are in the spare space on my "backup server"'s boot SSD. I don't normally back up that HDD, but I do keep my Catalogs on it and back up the Favorite Folder containing them once a week. My first Recycle backup run check-marked both the HDD as a whole and the Favorite Folder as Sources. As I predicted in the third paragraph of this post, the first run created two component Media Sets—one for the entire HDD and one for the Favorite Folder. My second Recycle backup run check-marked as a Source only the HDD as a whole, not the Favorite Folder. Both script runs were successful; the second run Recycled only the component Media Set for the HDD as a whole.
  8. DavidHertzberg

    How to FORCE a file backup on each run?

    MrPete, Look at the sub-section "Matching Execution Options" on pages 301-302 of the Retrospect Windows 17 User's Guide. It seems that if you turn off "Match source volumes to Catalog File" and "Don’t add duplicates to Backup Set" for a Backup script, the source files accessed by that script will be backed up on every run. Of course the script source will have to be one or more Subvolume(s) containing only the files that do not get a timestamp update when they change, as I suggested in this up-thread post. I see now that Nigel Smith suggested this in his second paragraph here up-thread. I agree with him that turning off "Don’t add duplicates to Backup Set" (he used the Retrospect Mac option name) would be sufficient. It so happens we have a probable test case for block level incremental backup, identified by this post in a Macintosh 9+ Forum thread and its predecessors. The OP Joriz is a Belgian administrator with a penny-pinching boss (who is impeding Joriz's effort to add disk-to-tape backups to go off-site); he is currently doing disk-to-disk backups of one server disk that contains Veeam backups of one or more VMWare VMs. He complained that those backups are creating excessive Retrospect Mac "churning". Nigel Smith suggested that Veeam might be doing block level backup—I verified it has the capability, but Joriz evidently hasn't enabled block level backup in Retrospect. Unfortunately at last report Joriz is out with illness (not COVID-19, he says), so he won't be able to immediately enable block level backup in Retrospect. We may have helped Joriz, but I think you're going to have to forgo the benefits of block level backup for those files if you turn off "Don’t add duplicates to Backup Set". How would Retrospect Windows know to not backup the unchanged blocks of a file if it's adding duplicates to the Backup Set? But come to think of it, how are you getting block level incremental backup for those files now, if their timestamps don't change? 🙄 Read the second paragraph on page 458 of the UG, with careful attention to the word "subsequent". Did I disclose that I receive a sales subsidy from the World Association of Disk Manufacturers? đŸ€Ł Buy bigger Backup Set disks, or a tape drive. P.S.: Considering all the foregoing, I think your idea—outlined in this up-thread post—of making short-lifetime timestamped copies of the non-timestamped files and letting Retrospect do block level incremental backups of the copies is the best approach. Buy bigger source disks instead of Backup Set disks. I ask, in naive ignorance: how does having files not be timestamped make them more secure?
  9. Walter Bowen, Thanks for alerting us to the release of 17.0.2. Could you tell us what your version of macOS is? Here's why and how to create a Support Case for a bug. All you have to do is copy your OP into the Problem Statement, and fill in the information above it.
  10. Joriz, Nigel Smith is absolutely correct in his first paragraph; I should have written "run a disk-to-tape script every day" instead of "run a disk-to-tape script nightly". Don't forget to specify that the disk-to-tape script must run in the same activity thread as the disk-to-disk script, as I said in the third paragraph of this up-thread post. Nigel Smith is even more correct in his second paragraph; 😁 it never occurred to me that Veeam is doing block level incremental backups, because I don't use that feature myself (I've only got one set of small databases that get updated maybe twice a month). A fast Google search brought up this Veeam Community Forums page; I'm sure you can find the appropriate pages in the Veeam manual, of which this may be one. Read pages 198-202 in the Retrospect Mac 16 User's Guide to find out how to use the corresponding block level backup feature in Retrospect. Nigel Smith, I think "snapshot" was a wonderful term when Dantz came up with it in 1990 or before. Unfortunately first Unix and then Windows NTFS and now Apple APFS began using it to mean something else beginning by the early 2000s. If the Retrospect User's Guides add the explanation for "active Snapshot" that I suggested in this post up-thread and in my Support Case, it's therefore going to have to include something like "this is Retrospect's definition of the term 'Snapshot', not everybody's filesystem's definition". Maybe it could quote the well-known Humpty Dumpty statement from Through the Looking-Glass.đŸ€Ł The word "snapshot" started out as a military or hunting term, and was appropriated by the Eastman Kodak company around 1890 to mean something different—in the context of someone carrying a camera instead of a rifle. Considering that every backup administrator will be familiar with the use of a filesystem "snapshot" for a backup—I predict even Retrospect will be doing it by next year, IMHO it would be asking a lot of an administrator to switch context just in that one place. That's why I suggest that Retrospect "Inc." should avoid any confusion and convert to "manifest"; "backups" confused you.
  11. DavidHertzberg

    Yet another -530 client not found error

    x509, You don't need to create a fixed IP address plan for all the devices on your network, just the computers you back up with Retrospect. Just pick a number evenly divisible by 100—higher than the number of devices you have on your network, and assign fixed IP addresses to your computers equal to or higher than that number. For instance, back in 2015 when I had to connect my ancient HP LaserJet 5MP printer—which connects to my LAN via an HP JetDirect EX Plus (too old for Bonjour, my 2015 problem when I upgraded to OS X 10.10) because the 5MP doesn't have Ethernet, I just plugged the EX Plus's MAC address with into my router. It still works fine, and I did the same for my client computers in February 2017 starting with The only thing I changed on 30 January 2017 was replacing a dead 100Mbps switch with a 1Gbps switch. It appears that newer networking hardware blocks ports 497 and 22024. These must be open on your LAN for both TCP and UDP for the Piton protocol to work. Retrospect "Inc." hasn't yet revised that protocol—which doesn't depend on SMB V1—to cope with the situation; I've been told there's a different approach to multicast that they should be using. It's also possible that your Windows software update turned on a firewall on your "client", as part of the update, that blocks those ports. Ah security, what crimes are committed in thy name! â˜č
  12. Thank you for the compliment, Nigel Smith; I did a number of revisions to my preceding post to make it clear without being too lengthy. I just submitted a Support Case (note to self: #73687), covering both the relevant User's Guide deficiencies—both Mac and Windows variants—and the apparent Cumulative Release Notes error I spotted per this up-thread post. As far as the Mac User's Guide deficiency is concerned, it may help to be aware that according to DovidBenAvraham Retrospect Mac 8—including a totally new GUI and terminology changes as well as the enhancements of Retrospect Windows 7.5—was hurriedly released in 2009 after EMC first end-of-lifed Retrospect Mac and then allowed the re-hiring of some of the employees who had worked on it. According to the head of North America Sales, an old-timer with whom I had a longer-than-expected phone conversation the other day, one of those employees was both brilliant and rigid—and he was the one who rewrote the Mac UG. Then he moved to VMWare, so he wasn't around to deal with Retrospect Mac terminology and documentation problems. One of those problems is that the Mac UG "now uses the term backup to include both session and Snapshot data". Of course the Retrospect Mac Engine, which since late 2009 has been common code with the non-GUI part of the Retrospect Windows Engine (not the Windows-only GUI ), still uses Snapshots in the Retrospect sense; you can see that merely by watching the Console text summary of a running Backup script. And of course the session data isn't stored in the Catalog for an active backup; it's only the Snapshot. So I said in the Support Case that, besides copying "Eppinizer"'s explanation of "active backup" onto page 120, they're going to have to enhance it to include an explanation of "Snapshot" referring to the Glossary definition on pages 264-265. P.S. (because I needed some sleep): As I interpret Joriz's posts on the first page of this thread, he has three interlocking problems in his campaign to have a disaster-recovery backup—preferably off-site—that is up-to-date: (1) His boss won't pay for more than the 3 x 2 = 6 LTO-7 tapes (costing US$65 apiece, according to my Googling) currently owned by the company. (2) Any disk-to-tape script he runs on weekdays must fit into the portion of 24 hours that remains after his server-disk-to-backup-disk incremental Backup scripts have run. (3) Veeam is churning bigger Retrospect incremental server disk backups than it ought to, because Retrospect is seeing VMWare files Veeam already backed up as having been changed in some way. To cope with these problems, I have made the following two suggestions: (a) Run a disk-to-tape script nightly, but make it as short as possible by having it add to tape only what the Snapshot of the latest disk-to-disk Backup shows has just been backed up. (b) Do something to prevent Veeam seemingly re-making backups of files it has already backed up. Suggestion (a) can be implemented by either using Copy Backup scripts whose source is disk Media Sets with grooming retention of only the latest backup—with a Groom script run only once a week, or by using Copy Media Set scripts that rely on the “Don’t add duplicates to the Media Set” option to screen out everything except what has been just backed up. The first alternative would IMHO run at least a little faster, but would require a US$69 update to Retrospect Mac 17; the second alternative would allow more frequent grooming of the disk Media Sets, which might be desirable if Joriz is running out of space on them. Suggestion (b) can be implemented either by finding out how to prevent VMWare-Veeam from churning, or by switching from Veeam to R. V. (and it's only my guess, which I'll check with Sales, that R. V. would churn less)—which would undoubtedly be very scary to both Joriz and his boss. P.P.S: I added to my Support Case a suggestion that the Retrospect term "Snapshot" be changed to "Manifest". It's the same number of characters, and younger administrators are probably more familiar with a cargo or customs manifest than they are with a Kodak snapshot. The point is that the term "manifest" hasn't been co-opted by the Computer Science community to mean something else What do you think?
  13. Nigel Smith, I finally figured out the explanation for the confusing Copy Backup popup option explanation in the Retrospect Mac 17 User's Guide (you're citing that version, though Joriz runs 16.6) page 121. We must detour to page 177 of the Retrospect Windows 17 UG, where it is written of Transfer Snapshot—the equivalent operation with the same options described in a slightly-different sequence: So why did they butcher this explanation for Retrospect Mac 8 and thereafter? The reason is that the term "snapshot" was abolished in the Retrospect Mac GUI because by 2008 the term had acquired a standard CS meaning, eventually even at Apple. Starting in 1990 the Mac UG (p. 264) had defined it: The term "active Snapshot" is not defined even in the Windows UG; it means a Snapshot that the "backup server" has given the status "active" by keeping it in a source Media Set's Catalog. As we see from Eppinizer's first paragraph quoted here up-thread, it is the single latest Snapshot if the source Media Set has grooming disabled—but is the "Groom to keep this number of backups" number of latest-going-backward-chronologically Snapshots otherwise. So that's why the choices in the Copy Backup popup have the word "backups" as plural. I'll create a documentation Support Case asking that the august Documentation Committee put Eppinizer's definition of "active" backups/Snapshots into the UGs. But "a backup that is kept in the Catalog" sounds silly.
  14. In regard to the churn rate of disk-to-disk backup of your Veeam backup files, Joriz: First, make sure you have left un-checked "Match only file in same location/path" in the Options->Backup->Matching tab of Scripts for your Backup script. Per pages 98-99 of the Retrospect Mac 16 User's Guide, this will make sure that any separate copy of an incremental backup file will not be backed up again. Second, I suggest you consult the Veeam Backup and Replication forum of the Veeam Community Forums. Here, for instance, is a 2016 thread in which the OP asks "Till now Retrospect is managing the tape library but we need a possibility for outsourcing out of date Veeam backups we don't need anymore but we don't want to delete finally. Is it possible to create a job in Retrospect which writes the related backup files from Veeam onto, with the possibility to restore them again to it's original destination if needed?" There is a Tape sub-forum there, but the OP in the thread I linked to in the second sentence of this paragraph posted down-thread (spelling mistakes are his, not mine) about what is probably also your single-tape-drive situation: Third, I have to ask whether you have considered using the Retrospect Virtual application instead of Veeam. I don't know anything about R.V., and have been forbidden to discuss it on these Forums. However I'm pretty sure it's cheaper than Veeam, even though your boss —and apparently you—is used to Veeam. R.V. only runs on a Windows machine, but you must have one of those to run Veeam. R. V. doesn't seem to have a tape backup capability of its own, but—considering it is marketed by Retrospect "Inc."—it probably has destination disks that can be backed up onto tape by Retrospect non-V. Mac.
  15. Nigel Smith and everybody else, They aren't supposed to be "the same thing with expanded options." Page 120 of the Retrospect Mac 17 User's Guide says (as does page 137 of the Mac 16 UG) : To answer the questions "What is an 'active backup'?" and "why does Copy Backup offer 'Copy all backups' as a choice in the drop-down?", here's a 2016 post by "Eppinizer"—IRL Jeff of Retrospect Tech Support—answering those questions in two separate paragraphs: I just looked at my test runs in Activities; my early test runs were of a Copy Backup script. The second of those runs copied all backups of "David's MacBook Pro" from Media Set Red, not merely the latest No Media Action incremental Backup. So I think that the Release Note I quoted in this up-thread post is wrong, and I've left voicemail messages for both the head of Tech Support and the head of North America Sales asking them to re-check it. In the meantime I now think that Joriz should either run a test himself, or use Copy Media Set for his incremental disk-to-tape backups and rely on the “Don’t add duplicates to the Media Set” option to restrict the copying to the most recent backup whose Destination was the Media set he is using as the Source.
  16. Joriz and Nigel Smith, While searching the Retrospect Mac Cumulative Release Notes for a possible answer to another administrator's problem, I just noticed this for 17.0.0: (Transfer Backup Set is the old name for Copy Media Set; it is still used in Retrospect Windows, which is why the common-code Engine uses the term.) In my early tests mentioned directly above, I was seeing the same problem using Retrospect Mac 16.6. Because the problem went away when I changed the disk drive location of 1-CopyTestDestination, I thought it resulted from my original test setup. Instead it evidently resulted from an intermittent bug, . Joriz: If you can't get your penny-pinching boss to shell out the equivalent of US$69 for an upgrade to the Retrospect Mac 17 version of Desktop Edition—which is the Edition I assume you are using, you'll have to use a Copy Backup script with schedules specifying No Media Action for your daily tape incremental backups. Leave the “Match Source Media Set to destination Media Set” and “Don’t add duplicates to the Media Set” options check-marked. I think you'll want to pick the "Copy most recent backups for each source" option from the popup, but see the next paragraph. Nigel Smith: Maybe this bug was why you wrote "I don't know what the practical difference is." Though it's probably not useful for Joriz, the popup options for Copy Backup—when it's working as designed—include "Copy most recent backups for each selected [my emphasis] source". Apparently that lets you specify which backup onto a selected source Media Set should be copied, using the Browse button on the selection dialog shown for that option. P.S.: Corrected the Joriz paragraph, which I had messed up.
  17. j.a.duke, (1) Are you using a Storage Group as the destination for your Proactive script? I'm not recommending it; the reason I ask is that the Retrospect Mac 16.6 GUI for Storage Groups is really half-baked, and there's no indication that the GUI has been improved even in Retrospect Mac 17.0.1—which was released on 1 May. (2) Otherwise your OP sounds as if you've got a problem with the hierarchical structure of your destination disk drive. The the hierarchy you list has two "FT_TD" folders at different levels of the hierarchy, one above the "Retrospect" folder and one inside it. Maybe that's getting the Console confused. My practice is to let Retrospect create a "Retrospect" folder at the top level on the destination disk, and let it create folders for the individual Media Sets underneath that. But then I've got a simpleminded home installation. Do you have more than one "Retrospect" folder on your destination disk drive?
  18. Joriz and Nigel Smith, In my first job as a programmer in the mid-1960s, I worked as a consultant with one U.S. Air Force-written project cost and schedule control application that ran for hours on a "big iron" IBM 7090 or 7094—using multiple half-inch tapes for I/O because those machines generally didn't have then-incredibly-expensive disk drives. I was paid—indirectly by the U.S. Navy—to personally supervise those runs, which were made at one of the computer service bureau offices belonging to my employer. Thus I became quite familiar with factors affecting tape life. The IBM 729s and 2400s we used then and the LTO-7 drive Joriz is using have one thing in common; they make read and write scans linearly up and down the tape. The tape is moved by rollers that touch the tape and it passes over a read-write head (a second read head for LTO does read-after-write verification) that even for LTO also touches the tape. It's the repetition of high-speed linear scans that wears out tapes. (As I write this I am using Retrospect Mac 6.1 to back up my ex-wife's old Digital Audio G4 onto a DAT drive—which uses helical scanning with a rotating head instead of linear scanning, but DAT-based Digital Data Storage was abandoned because it couldn't keep up with LTO's capacity increases.) AFAIK LTO tape wear doesn't depend on whether the read-write head is writing when the drive does those linear scans, but at least the read-write head has to be reading at least a servo track—except for rewinds—because that's the only way the read-write head can position itself for non-direct-access as a result of those scans. I just spent the best part of 24 hours doing comprehensive tests of both the Copy Media Set and Copy Backup features of Retrospect Mac 16.6. At first I didn't think they worked, but that was because I had placed the Media Set member 1-CopyTestDestination in the spare space on my portable USB3 HDD—which wasn't large enough to hold a complete copy of 1-Media Set Red that occupied the rest of that HDD. After I did a Rebuild of CopyTestDestination to place 1-CopyTestDestination on the larger spare space of my "backup server"'s SSD boot drive, both Copy Media Set and Copy Backup functioned as pages 116-122 of the Retrospect Mac 16 User's Guide say they should—but see my post directly below. (Switching my destination from USB to boot drive halved the speed of the script runs—even though it straightened out the function testing, so you'll have to do speed testing with your tape drive , Joriz.) The "Copy most recent backups for each selected source" option on the popup menu of the Sources tab for a Copy Backup script functions exactly as it states, Nigel Smith. I tested by first running a Copy Media Set script after running a Recycle Backup of three source drives and a Favorite Folder onto Media Set Red, and then interspersing No Media Action Backups of one source drive with No Media Action Copy Backup script runs using the "Copy most recent backups for each selected source" option. However I also tried a No Media Action Copy Media Set run after a No Media Action Backup run; the “Match Source Media Set to destination Media Set” and “Don’t add duplicates to the Media Set” options caused that Copy Media Set run to copy only the latest backup of that source to Media Set Red, exactly as did the Copy Backup run with the "Copy most recent backups for each selected source" option. Thus Joriz can use either Copy Backup with the "Copy most recent backups for each selected source" option or Copy Media Set for daily tape backups.
  19. DavidHertzberg

    client not being recognized

    denno, Does the MBP which you can't Add have multiple network interfaces? This sounds to me, whose LAN is much less complicated, like that situation. First read this "Client Security" section in the Retrospect Mac 17 User's Guide. Make sure you have done what it says for the MBP you can't Add. Next, open the Advanced tab of System Preferences -> Retrospect Client for both the MBP your iMac Pro "backup server" can see and the one it can't see. Look at the Public Backup Server field on the tab for both those MBPs. Are they the same? If they're not, Click The Lock to Make Changes, and then click the Edit button and set the Public Backup Server field on the MBP that can't be seen to the same address as the one that can be seen by the "backup server". However the P.P.S. of this post in that same thread says that field was introduced in Retrospect Mac 15 for Remote Backup—which I gather you aren't using, so it may not be applicable in your situation unless it's been expanded for use in ordinary public/private keypair security. But read the preceding portions of that post. If that hasn't solved your problem, read the rest of that thread—concentrating on the posts by Nigel Smith. BTW you should probably upgrade your "backup server" to Retrospect Mac 17.0.1, which has a lot of bug fixes even if none related to this. P.S.: In regard to your post directly below, Retrospect.app is the Console—not the Engine which is installed in a "seekrit location".
  20. amkassir and Nigel Smith, Reading this article and this article reinforced my understanding of snapshotting of APFS-formatted volumes under High Sierra, Mojave, and Catalina. The key points are (a) snapshots are a capability of the APFS filesystem—but a capability that backup applications must be programmed to initiate, and (b) APFS snapshots are made on a source volume and consist of links to files (links taking up essentially no space, which I knew)—so a backup application that initiates a snapshot must then copy the linked-to files. Time Machine and CCC do both these things, but Retrospect doesn't do them yet. The second article says: and, because "a snapshot essentially marks all the currently used data blocks on a volume to be preserved; that is, no changes can be made to them": Both those articles describe how to use commands in the Terminal to create and to restore from snapshots, assuming the source volume containing them is still available. This article describes how CCC makes copies of hourly, daily, and weekly snapshots that it initiates on the source volume; it also describes CCC's Time-Machine-like policy for retaining its copies of those snapshots. The procedure this article describes for Restoring from a CCC-retained copy of an APFS snapshot is simpler than the procedure in the Retrospect Mac 17 User's Guide, but it only works for a startup drive if you've still got one that's functioning. That's why Bombich Software says: Also note that AFAICT the CCC snapshotting capability only works if the destination volume is also formatted with APFS. AFAICT that rules out USB drives that that don't have the capacity of the source drive, NAS drives, and also the cloud as destinations. It is also of interest to everyone that the Retrospect Knowledge Base articles on "macOS Catalina Support", "macOS Catalina – Application Data Privacy", and "macOS Mojave – Application Data Privacy" were updated on 5 May.
  21. Joriz (if Nigel Smith is a good boy he can read this too đŸ€Ł ), Let me start out by guessing that you didn't institute off-site backup because you wanted to play with tape drives, but because your employer seems to be a business that has the responsibility of promptly recovering from the disaster of the server room flooding. (If I emphasize flooding, it's because U.S. companies have been in the habit of putting their server rooms in the building basement underneath the cafeteria—with predictable results. Besides, Belgium borders on the North Sea.) Nigel Smith, from his statement in another thread, seems by contrast to be an administrator for an educational or research institution—where it's the responsibility of the researchers to do their own backup during COVID-19 Work From Home. The reason I suggested daily Copy Backup scripts up-thread is because I thought they would run faster than Copy Media Set scripts, and you seem to be concerned with adding to the total elapsed time of your disk-to-tape runs. In connection with this, I'm not sure from your OP whether you run disk-to-disk Backup scripts on Saturdays or Sundays; from the 10 p.m. start time of those scripts it sounds as if you wouldn't want to run one on Saturday or Sunday night—unless you have employees using the fileservers over the weekend. I'd guess you do, though, and therefore currently have the requirement that a disk-to-tape script run starting at 8 a.m. on Saturday complete before 10 p.m. on Saturday. But if you switched to daily disk-to-tape runs, they'd be incremental and therefore run faster than your current weekly disk-to-tape runs—which seem to be the equivalent of Recycle Backups. You can make sure an incremental disk-to-tape script runs after its corresponding disk-to-disk script run, by designating the same Activity Thread for both scripts. Page 225 of the Retrospect Mac 16 User's Guide says "By assigning activities to the same activity thread, it ensures that they will run one after the other."; an Activity Thread is assigned for a Backup script in a "Use ..." popup at the bottom of its Summary tab that is shown—but not explained—in the screenshot on page 94 of the UG, and is assigned for a Copy script by a "Use ..." popup at the bottom of its equivalent Summary tab. Caution: do not let a Copy Backup/Media-Set script execute in a different—or "Any"—Activity thread from its corresponding Backup script; I discovered a couple of years ago that doing this will allow a Copy Backup/Media-Set script with a particular Media Set as a source to execute while a Backup script with the same Media Set as destination is still running—which I thought was a wonderful feature until the head of Retrospect Tech Support pointed out that a Backup script doesn't update the Catalog File of its destination Media Set (which the Copy Backup/Media-Set script reads) until the end of the run. But so long as you observe this precaution, you are guaranteed that a daily Copy Backup/Media-Set script will not start executing until its corresponding daily Backup script is finished. Therefore you have a full 24-hour day for the combination of the two corresponding scripts to run. Up-thread I suggested using daily Copy Backup scripts instead of Copy Media Set scripts, because I thought they'd run faster. But now I'm not so sure, and I don't have the capability of running a test for it. That's because, contrary to what the UG implies on pages 137-138, my test the other night indicates that "the most recent backup [my emphasis] for each source contained in the source Media Set" doesn't work as of Retrospect Mac 16.6. The source Media Set for my Copy Backup test had been backed up with Recycle last Saturday morning and then backed up withe the incremental No Media Action on Sunday and Monday mornings, but the Copy Backup test copied the entire source Media Set instead of only the last incremental Backup The Match source files against the Media Set and Don’t add duplicate files to the Media Set options didn't have any effect because I had specified Recycle in the Schedule for the script. As for tape wear, I'm afraid that—because of the fundamental non-random-access nature of tape drives—each successive Copy Backup run would probably cause Retrospect to read its way down the last tape mounted on your LTO-7 tape drive to get to the point where it should start writing. Possibly leaving the tape in the drive from one night to the next would prevent it from doing this, but that would only be true if Retrospect remembered the name on the label of the tape from the last run—and therefore didn't have to rewind to read the label—but I don't think it trusts the drive user to that extent. The Linear Tape File System might add that capability, except that Retrospect doesn't use LTFS for Backup operations. And besides, I suggested that you unload the current tape from the drive after each Copy Backup run—and temporarily store it in your boss' office so that it would be in a separate room from the backup disks.
  22. Joriz, Sorry for the delay, but I needed to correctly run a test of a Copy Backup script early this morning. The test copied the last Recycle backup of my MacBook Pro to an extra Media Set that fortunately happened to be occupying spare space on the portable USB3 hard disk drive that has been my destination for Backup runs since early Saturday morning (my scripts switch between 3 such portable HDDs weekly). The successful test run was itself a Recycle, since I had used up the destination Media Set's space on previous tests. The purpose of the test was to get timing for a Copy Backup script versus the Backup script that copied the same data. The Copy Backup script took 30 minutes to copy 65GB of files. The original Backup run, by contrast, took 190 minutes to Backup the same files to the destination Media Set that was the source for that portion of the Backup run. The Copy Backup copying rate was 2.4GB/minute, which is about 7 times the speed of the 0.361GB/minute copying rate of the Backup run. That is what I expected, since my previous experimentation has shown there's a lot of processing work that the Client program does on a Backup run—and my MacBook Pro is is a "client" on my LAN (which has a 6GB/minute speed—allowing 20% overhead for TCP/IP headers). The same Saturday morning Backup run also did a Recycle backup of two drives that are internally mounted on my Mac Pro "backup server" machine; the copy rates were 2.0 GB/minute for the old HDD drive and 2.3GB/minute for the SSD drive. Therefore I simply don't believe that "The disk to tape can be run in the weekend because it needs more time to backup [my emphasis]", as you wrote in this up-thread post. You wrote in your OP "ï»żForï»ż the Disk to Tape backup I made an individual script for each tapeset. The script type is set to 'Copy Media Set'". I think your disk to tape scripts are actually Backup scripts, whose sources are the same FILESERVERx SMB shares that are the sources in your disk to disk scripts.. They probably run somewhat slower than your disk to disk scripts because their destination is a tape drive (the source and destination of my test Copy Backup script is the same portable USB3 HDD, so that should produce a somewhat equivalent slowdown). I need to go to bed now, so I'll later add suggestions to this post about how to do a Monday-through-Friday Copy Backup script run after each disk to disk Backup run, as I suggested up-thread.
  23. amkassir and Nigel Smith and others, I had phoned the head of North America Sales, and he just phoned me back. He checked within Retrospect "Inc.", and was told that there was ""a ton of coding" done in 17.0.1 to support the additions to pages 154-156 in the latest revision of the Retrospect Mac 17 User's Guide. So what I wrote in the third paragraph of this up-thread post was wrong—I've now corrected it, even though my bare-metal Restore of a High Sierra MacBook Pro slightly more than a year ago seemingly was a klunkier version of the same procedure. Maybe Apple made a bare-metal Restore substantially more difficult with Catalina and Mojave, and the engineers had to revise Retrospect to compensate for that. In regard to CCC, amkassir, here's "Leveraging Snapshots on APFS Volumes", and here's "Everything you need to know about Carbon Copy Cloner and APFS". My understanding of these two documents is that CCC simply creates a snapshot on an APFS-formatted source volume, and uses the contents of that snapshot as the source. If you're doing a bare-metal Restore, that snapshot itself is not available—only the copy of the snapshotted volume that CCC made on the destination volume. If the source volume was poisoned by ransomware before the snapshot was made, then you can only restore a good copy of the source volume if you had CCC also save a the contents of a previous snapshot. That would require a destination volume with—if the source volume is nearly full—twice the capacity of the source volume. So my "Must back up multiple machines to a destination more compact than the same number and capacity [my emphasis] of disk drives" requirement still argues in favor of also using Retrospect.
  24. Joriz, First of all, there's something unusual about one fact in your OP in this thread. There you state you are "running Retrospect [presumably Mac] 13", whereas in this post 8 months ago you stated you were using Retrospect Mac 16.1.2. Did you go back 3 major versions—assuming you continued working at the same company—in the last 8 months, and if so why? Second, I agree with Nigel Smith that your provisions for offsite backup are inadequate for a company that probably can't afford to lose up to a week's worth of data in the event of a flood or fire in its server room. I think you should run a disk-to-tape Copy Backup script every day as soon as the disk-to-disk Backup script is finished, and then store the tapes belonging to the current OFFSITE Media Set outside the server room—possibly in your boss' office. You would bring the tapes back to the server room at 8 a.m., and put them back into the tape library device while the disk-to-disk Backup script is running. That way if the server room is flooded sometime during the rest of the day, you'll still have tape backups as of 8 a.m.. A Copy Backup script should run faster than a Copy Media Set script, since it can be set up to "Copy most recent backups for each source" (see pages 161-162 in the Retrospect Mac 13 User's Guide).
  25. Joriz, First read pages 14-15 of the Retrospect Mac 13 User's Guide. That's why grooming isn't doing anything to reduce the size of your disk Media Sets. If even one source file backed up to an RDB file is still current, then performance-optimized grooming won't delete the RDB file. You should be using storage-optimized grooming unless your disk Media Sets are in the cloud—which you say they aren't. (It seems the term "performance-optimized" can trick administrators who aren't native English speakers, such as you.) There's a reason performance-optimized grooming was introduced in the same Retrospect Mac 13 release as cloud backup. It's because rewriting (not deleting) an RDB file in a cloud Media Set requires downloading it and then uploading the rewritten version—both of which take time and cost money.