Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by DavidHertzberg

  1. DavidHertzberg

    cannot find Catalog File

    Oh my, billbobdole, it appears you're still using the same ancient trick with File Media Sets I described 6 months ago—except now you're trying to do it under Retrospect Windows (17?) with the File Media Sets supposed to be treated as File Backup Sets. 😢 At a minimum you need Retrospect Windows and Windows expertise, which as a Mac administrator I can't provide—but maybe Nigel Smith or Lennart_T can. What version of Windows are you running under? Did your 2012 Mac Mini die, or did the trick not work under Catalina? At a maximum you need the help of Retrospect Tech Support. If you upgraded to Retrospect Windows 17 within the last 30 days, you are entitled to free personalized Tech Support. And IMHO you need that kind of support; I don't even know if your trick works the same way under Retrospect Windows 17.
  2. DavidHertzberg

    Yet another -530 client not found error

    rfajman, You've left out a key word after "dedicated Gigabit Ethernet": you should have written "dedicated Gigabit Ethernet WHATSIS". Is the WHATSIS a piece of hardware—such as a router or "gateway", or is it a piece of software—such as something in Microsoft Windows 10? The WHATSIS apparently has an interface, and that interface is checkable and configurable via a command file. Some Googling seems to show that Gigabit Internet interface is a connection between a computer and a router. You may have a Windows 10 problem, but I'll let someone who knows Windows explore (no pun intended) that further—based on further information about your script that you must provide. P.S.: Rewrote 2nd sentence of 2nd paragraph; the interface isn't necessarily a particular Windows table.
  3. DavidHertzberg

    Scheduling a one-time backup

    rfajman, The facility you want is probably already in Retrospect Windows 16; it is called a "run document". See pages 236–238 of the Retrospect Windows 16 User's Guide.
  4. DavidHertzberg

    Yet another -530 client not found error

    MrPete, For the problem described inside parentheses in your first paragraph, have you defined your subnets per pages 228–229 of the Retrospect Windows 17 User's Guide—and have you added such clients using the Subnet Broadcast access method per the Access Tab alluded to (not described) on page 223? My impression is that Subnet Broadcast—which I've never used for its intended purpose—searches for the "client" machine using the Piton Name Service on each of the subnets defined on the "backup server". If that doesn't do what you need, here's why and how to create a feature request Support Case for enabling multiple Direct Access addresses for a particular "client".
  5. DavidHertzberg

    Windows 10 Feature Release 2004

    speedyme, You can find your answer in the cumulative Release Notes for Retrospect Windows. But I'll save you the effort of reading the most recent entries; the answer is no.
  6. DavidHertzberg

    Yet another -530 client not found error

    Nigel Smith, Your 10-step guess as to what might have been happening may be correct, although you got confused about the Location of my first test—it was "Automatic" (X.Y.Z.202) instead of "Retrospect Priority" (X.Y.Z.201). I reran that test yesterday, but—after changing the Location of my MacBook Pro "client" machine—scheduled the backup run 15 minutes in the future and then shut down and re-booted my "backup server". This time the No Files backup ran with no error. 😲 That raised the question of how the Retrospect Engine had been able to find the MBP Source, which I am sure I had defined with Add Source Directly as X.Y.Z.201. The answer seems to be the "magic" of Piton Name Service. When I did a Locate of that Source after the test, it found the MBP via Multicast as X.Y.Z.202. (I intentionally did not do a Locate after re-booting the "backup server" but before the test run was scheduled, because I found 3 years ago that a pre-Backup Locate would eliminate a -530 error that otherwise would occur.) So am I going to investigate this further in my installation, other than possibly making the effort (because of necessary script changes) to Remove and re-Add my MBP as a Source with Use Multicast? No I am not, because of an experience I had with Tech Support over two years ago. As the third paragraph of that post says, T. S. twice gave me test versions of Retrospect with extra logging. I uploaded the results to my Support Case, and got back a reply that said basically "Yes we see a problem, but we can't do anything about it unless we can reproduce it on our own machines—because it seems to be at least partially related to network hardware." I thereupon offered to snail-mail T. S. my two MoCA adapters (for which I had by then bought higher-speed replacements) and a 40-foot length of previously-bought-for-testing Radio Shack coax cable to run between them, but got back a reply that said basically "Thanks for the offer, but we cannot take responsibility for customer-owned hardware." I then suggested they find someone in the Retrospect Inc. organization who had gone far enough in law school to be able to write a deed of gift to Retrospect Inc. that I could sign, but they didn't reply. ☹️ So, as the last paragraph in this up-thread post states, we'll just have to wait until StorCentric discovers the -530 problem for the forthcoming Drobo variant of the "backup server"—and provides Retrospect "Inc." engineers the necessary resources to find and fix the problem. 😢
  7. DavidHertzberg

    Yet another -530 client not found error

    Nigel Smith, You are correct about my having defined the Piton protocol too narrowly; Instead of writing "multicast Piton Protocol", I should have used the term Piton Name Service—per page 227 of the Retrospect Windows 17 User's Guide. At last the -530 versus -519 difference is clarified. On page 221 the UG says: Page 228 says: Page 33 of the Appendices says: In fact, a closer examination of the log for my first test run illustrates the difference between the overall Piton protocol and Piton Name Service in a rather interesting way (it turns out I didn't need WireShark. 😁). The run actually "Finished scanning backup set data files to ... ", then issued the message "Can't access backup client ..., error -519 (network communications failed)". It seems my "backup server" managed to find my MacBook Pro "client" by name, when it couldn't do so by Direct Access because the IP address the "client" was using didn't match the one defined in Sources. Then, after successfully finishing scanning, the "backup server" said "Wait a minute, that's not the Source I'm supposed to back up" and issued the -519 error—not a -530 error. By contrast, the log for my second test run—where the IP address the "client" was using did match the one defined in Sources—says "Can't read state info, error -519 (network communications failed)" when I too-rapidly shut down the MBP after the "backup server" had successfully finished the backup stage. Thus it's the Piton Name Service that needs to be fixed. As I've predicted elsewhere, StorCentric will have to force this to be done for the forthcoming Drobo variant of the "backup server"—so hordes of new Retrospect users won't have to learn how to set up Direct access to avoid -530 errors.
  8. 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.
  9. 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.
  10. 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. 😒
  11. 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.
  12. 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.
  13. 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 ), backed up to on multiple "clients" own schedules, in between those "clients" and a "backup server" that backs up the "appliances" 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 have not as yet provided any GUI for accessing the component Media Sets of an existing Storage Group, except for Restore in Retrospect Windows and 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 seems obvious such a "backup server" would 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. And 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 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 existing 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?
  14. 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.
  15. 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?
  16. 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.
  17. 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.
  18. 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! ☹️
  19. 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?
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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?
  25. 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.