Jump to content

DavidHertzberg

Members
  • Content count

    1,281
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by DavidHertzberg

  1. DavidHertzberg

    granular restore options

    (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 penny by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially here.) redleader, There used to be an explanation of those granular Restore options on pages 129–130 of the Retrospect Mac 16 User's Guide, following the phrase "Choose one of these:" (that phrase still remains 🙄 )in step 6. However the explanatory indented paragraphs below the phrase were deleted on page 115 of the Retrospect Mac 17 UG by the StorCentric Slasher (who is in reality probably a direct employee of Retrospect "Inc."). The Slasher evidently had to make room in the UG for 30 pages of new Appendixes that were copied from Knowledge Base articles explaining "go big or go home" features—pages that IMHO should have been added to the UG when the features were introduced in 2018—without unduly expanding the size of the UG. However a version of that options explanation—including 'Replace if Backup Set is newer'—still remains on page 117 of the Retrospect Windows 17 User's Guide, which was previously more than doubled in size in 2012 for reasons explained in the 3rd paragraph of this later-deleted section of a Wikipedia article. But that explanation depends on the term "Snapshot", which is explained in the fifth paragraph of this also-later-deleted section of the Wikipedia article. As that paragraph also says, "Snapshot" was—as used from 1990 onward: That elimination of "Snapshot" was done in 2008 by the Tyrannical Terminologist 🤣 (my name for a developer whom an old-timer in Retrospect Sales says played a key role in the re-design of Retrospect Mac 8). That developer was prescient; Apple APFS's "snapshots" mean something different than Retrospect's, and something similar to Microsoft Windows' "snapshots". As a Glossary entry on pages 229–230 of the Retrospect Mac 17 UG says: IIRC I've never used the 'Only overwrite older files' option, so I've no idea whether it works. However nobody's posted a Forums complaint about it not working. Read Mac16 UG pg.99 Use Attribute Modification Date ... . If you find it doesn't work, here's why and how to submit a Support Case for a bug. Regardless, of whether the option works, you may also want to submit a Support Case for a Retrospect Mac documentation deficiency; here's why and how to do that. In doing that, you'll have to deal head-on with the term "Snapshot" having been banned in Retrospect Mac since 2009. The last two paragraphs of this post in another thread discuss my proposal—made in response to my earlier post in that thread about the meaning in the Retrospect Windows UG of the undefined term "active Snapshot"—that Retrospect "Inc." replace the term "Snapshot" with "Manifest". That replacement would have to be in the "backup server" Engine as well as in the GUI for both variants of Retrospect, because the Engine is basically common code for the two variants. If you doubt Engine code is common, look at a running Retrospect Mac Backup script—where you'll see "Updating snapshot" and "Copying snapshot" displayed on the Console as phases of the backup. That's why I suggested "Manifest", which has the same 8-letter-length as "Snapshot".
  2. DavidHertzberg

    Console 16.1 erases client options

    Don Lee, Upgrade immediately to Retrospect Mac 16.6. Don't pass "Go", don't collect $119 🤣 —which I assume you already paid for a Desktop Edition upgrade. Retrospect Console 16.1 has "joined the choir invisible". Why are you using it? 🙄 I've been totally on Retrospect Mac 16.6 since December 2019. A fast eyeball search of the Retrospect Mac cumulative Release Notes doesn't disclose a fix for your 16.1 Console bug. However a number of existing features ended up broken in the 15.0–16.5 "go big or go home" era of Retrospect development; most of them seem to have been fixed by 16.6. As the first long paragraph of this post in another thread mentions, Retrospect "Inc." apparently isn't above obfuscating who discovered a Retrospect bug that backup administrators reported before it was fixed. 😎 So if an engineer discovered the bug noted in your OP and fixed it by 16.6, he wouldn't necessarily have put a mention of it into the Release Notes—because IMHO the engineers are ashamed of 30 years of inadequate alpha-testing.
  3. DavidHertzberg

    Proactive job scheduling

    Jan Löwe, The head of Retrospect Tech Support did indeed reach out today, at what would be 5:24 a.m. California time. The second paragraph of his reply is: That sounds as if your bug was the one fixed in Retrospect Mac and Windows 17.5.1. As to who at Retrospect "inc." changed the bug title to be less informative, I'd better not speculate. I'd also be better off not speculating as to why QA testing supposedly (but see Jordan Shattuck's first e-mailed reply in my post directly above) discovered this bug after the 23 September release 17.5.0. However there is an Engine preference that specifies the maximum number (up to 16) of activity threads that can be running in parallel. So all an engineer had to do as an alpha-test is to set this preference to 3—leaving 2 for source "client" machine-drive combinations along with the thread for the Proactive "controller"—and then submit a script with 3 source "client" machine-drive combinations. Proper alpha-testing, including of the 17.0.0 "AI" speedup, should have caught this bug earlier. Everybody, The first paragraph of his reply is: As stated in the post directly above, I originally contacted Retrospect "inc." about bug #8893 by using the messaging facility newly made available to readers of the cumulative Release Notes—not via this Forum. All subsequent communications were via e-mail. So I guess the head of R. T. S. is annoyed that I mentioned my communications on this Forum. Be warned. Also be warned that my sending a message from the cumulative Release Notes web page resulted in "Jordan Shattuck" creating a separate Support Case containing my original message and the subsequent e-mails. Maybe that's the only way he/she has of communicating them to R. T. S.. OTOH hitting option 7 on the Retrospect phone line and typing in "Shatt" elicited a statement that no one whose last name starts with those letters is listed, so I guess Inside Sales Manager Jordan Shattuck is considered too junior—maybe because he still has hair 🤣—to have a separate phone extension.
  4. DavidHertzberg

    Yet another -530 client not found error

    Nigel Smith, Permit me to recount a personal story that will shed some light on I bought my first home computer in the Fall of 1988, preparatory to belatedly returning to college for 1.5 years to get a quickie BA in Computer Science. I bought a Mac because that's what my college recommended, and I followed that up with buying a Maynard QIC tape drive in February 1989. The backup software was not Retrospect but Maynstream—the ancestor of BE. My wife and I returned to NYC after I received my BA degree in the Spring of 1991; my wife had been using my original Mac for writing and drawing once I had bought a second Mac for myself in December 1989. In January 1992 I upgraded my Mac to System 7, following the Boston Computer Society Active Window recommendation to do so by wiping my backed-up HDD and installing System 7 from scratch. That worked fine, and my wife asked me to do the same for her Mac in February 1992. Maynstream couldn't read the Maynard backup I had made for her. I ended up shipping the backup tapes to Drive Savers, who managed to recover most of my wife's backed-up data for a charge of around $700 in 1992 U.S. currency. I bought a DAT tape drive in 1995, after a later disaster—whose details I can't remember—that resulted in my wife's permanently losing some of her Mac artwork, and have been running Retrospect with a Compare step every morning ever since—except 2010–2015 when I had no "backup server". (My now-ex-wife has continued to buy Macintoshes, and is using Time Machine for backup.) The applicable point of this story is that one has to be very careful about preserving the data—and applications—stored on a spouse's computer. It's possible that x509's wife has been using applications or Windows add-ons that came as part of the Lenovo "bloatware", which is why he would write "... but too much time has passed now." That's why I'd like to help him get a "self-healing" Retrospect Windows Client. A exact opposite of such carefulness is the attitude of the Ars Technica Other Hardware forum poster to whom I wrote the Private Message from which the story in the above lengthy paragraph is adapted (you didn't think I wrote it especially for this post, did you? 🤣 ). He is personally a Windows and Linux user, and wrote—of his wife and daughter's Macs—"computers that I don't want to support when a free alternative they can use to self-support exists. I'm not planning on throwing money away on a repeated basis buying upgrades to any potential software, I'm not planning on constantly making sure their backups are working, I'm not interested in walking them through periodic upgrades. If I can provide a service that they can use to self-support (the entire beauty of Time Machine) then I'm done. If Time Machine is unreliable, I'll cross that bridge when I get to it." I had cautiously suggested a client-server application (I'm not allowed to name Retrospect on the Ars forums except in one authorized Mac thread) for backing up to the NAS he wanted to buy, but ended up suggesting A**—a "push" backup application that would be enough for all his home computers.
  5. DavidHertzberg

    Proactive job scheduling

    Jan Löwe, Retrospect Windows 17.5.1.102 was released today. Its very-informative 🤣 entire entry in the cumulative Release Notes is: Is #8893 the bug number assigned to the Support Case that you submitted about Proactive job scheduling? P.S.: When I looked again at the cumulative Release Notes, they gave me an option to send a message. The first e-mailed reply, from "Jordan Shattuck", said After I replied to that e-mail, pointing out that I had initially read the Release Notes and describing your prominent position, I got back another e-mail saying I strongly suspect that "Jordan Shattuck" is actually a bot. Just what I needed, StorCentric! 🙄 Real people may reach out Monday.
  6. DavidHertzberg

    Yet another -530 client not found error

    I understand that, but x509 has been suffering with -530 errors on his wife's Lenovo Yoga 730 machine for at least a year—and I'd like to automate the relief process for him as well. I'd like nothing better than for him to do a clean install using a retail copy of Windows, but he says "I probably should have done the same [clean install] with my wife's system when it was new, but too much time has passed now." Restart Service is no doubt overkill (a choice of word not originally intended to be humorous 🤣 ) for all the other administrators having a -530 problem with Windows "clients" that aren't "blessed" with Lenovo "bloatware", but it would be effective. Maybe there could be a single "command line" script that would first determine if the Client was On. If it wasn't, the script would do a Restart Service. Either way, the script would then do a "ping" of the "ipsave address"; if the "ping" didn't work, it would turn the Client off and on again. The problem is that, if the Client were Off, it couldn't run the "command line" script—so the "command line" script would have to be run at the end of the machine boot process. I'd like to avoid having the Retrospect Client Installer put in a machine-boot-process "command line" script for all other administrators; maybe the Installer could determine if the "client" machine is a Lenovo. Alternatively, we—or R.T.S.—would have to give x509 a separate script to install on his wife's machine.
  7. DavidHertzberg

    Yet another -530 client not found error

    Great experiment, Nigel Smith! 😀 It sounds as if x509 can make things easier on himself if he just checks the Client on "Lenovo730" before its nightly backup starts (he could already be backing up "client D"), and does a "Close program" followed by a "restart service" for the "Lenovo730" Client if its Status is "Off". Maybe that can later be done in one Windows "command line" script—or optionally two; see the next paragraph. MrPete, mbennett, rfajman, and Nigel Smith, Be aware I don't know anything about Windows "command line" scripting, but it occurred to me that the entire process in this post's lead paragraph could be automated for the case where the Client's Status is still On—which it isn't in x509's case. The approach would be the same as in the last substantive paragraph of this up-thread post, except that the Client would launch a Windows "command line" script to do the work instead of doing the work itself. That would shift the multi-threading upwards to Windows, which would eliminate the engineering difficulty of multi-threading the Client that I mentioned in the second paragraph of this further up-thread post. Either the "command line" script would retrieve the Client's "ipsave address" itself or the Client would pass the "ipsave address" to the script as a parameter; either way the script would simply "ping" the address, and do the "Close program" followed by a "restart service" for the Client if the "ping" was unsuccessful (based on the "if I can't see you, then you probably can't see me" principle we all learned as children playing hide-and-seek.). A optional extra—for x509's situation—"command line" script without the "ping" would be run after "client" machine boot to start the Client. MrPete, because of his evident prowess in Windows shown in this even-further-upthread post, should probably investigate the feasibility of writing such a script. If it's feasible, he should include it as an Additional Note in his Support Case #8512. Given that Retrospect Windows 17.5.0.237 didn't fix the -530 bug, I suspect the Retrospect engineers would now be open to a simpler approach. Maybe I should investigate the feasibility of writing the equivalent of such a script for macOS, although I have no experience with macOS "command line scripting. x509, IMHO you need to further investigate eliminating the "Lenovo bloatware" on your wife's "Lenovo730" machine. I did a search of the Forums, but nobody else has reported the same problem. However you're totally correct about that "bloatware"; through early 2015 it included bundling Superfish software identified as malware, and in August 2018—which post-dates the release of the Yoga 730—Lenovo "was criticized for automatically downloading Lenovo Service Engine software – labeled as unwanted bloatware by many. Worse, when users removed the software Lenovo systems were configured to download and reinstall the program without the PC owner’s consent [my emphasis]". Before investigating that, you need to figure out precisely when the "bloatware" shuts down the Client around the time of "client" boot—so that the optional "ping"-less script can be run afterward as part of the machine boot process rather than by the Client.
  8. DavidHertzberg

    Yet another -530 client not found error

    x509, I'm now going to get myself into trouble by venturing into the sociological aspects of client-server backup. 😃 Assuming "client" machine "Lenovo730"'s C:\ drive is OK, then—based on what Nigel Smith has said and what you've said above—it sounds as if your wife is occasionally doing something to her machine while Retrospect is backing it up. My guess is that she's either rebooting it or shutting it down or removing it from an Ethernet connection while the backup is running, and that's what's generating the Client lock file. I wouldn't recommend holding your breath while the Retrospect engineers develop a facility for having a robotic arm reach out of the "client" to slap her hand when she tries to do that. 🤣 Therefore let's consider doing what I did for the last 10 years I was married. I wrote Backup scripts—not Proactive scripts—scheduled to run at 3 a.m. or later to back up both our machines, and I booted both "clients" followed by the "backup server" whenever we had breakfast. So both of our "client" machines got backed up once a day; No Media Action (Normal) on weekdays and Recycle (to a newly-swapped-in destination with the swapped-out destination going off-site)—with a script that also backed up the "backup server"—on Saturdays. (IIRC I originally scheduled these backups to be done while we were getting ready for bed, but the noise of a tape drive executing the Recycle script in the bedroom turned out to interfere with our sleep Saturday night to Sunday morning.) We both learned to do Save As for any document changes that wouldn't be backed up until the following morning, and we treated Saturday mornings in accordance with the no-work Jewish Sabbath (despite her being Catholic). Although now alone, I still do this. If my guess is incorrect or my solution is unacceptable, let's return to the question of "constant maintenance". Contrary to what Nigel Smith speculated above, this 2016 Knowledge Base document—though for a different error—implies that there is no Retrospect Windows equivalent for Retrospect Mac's retroclient.state file. This post in a 2014 thread by the head of Retrospect Tech Support—again for a different error—implies the same thing. So it appears there's no alternative to what you reported doing in December 2019—which is Client delete and reinstall. A Client, even multi-threaded (2nd paragraph here), couldn't delete and reinstall itself. You can at least eliminate the monitoring part of the "constant maintenance" by—in addition to supplying your e-mail address—specifying Send e-mail for failure and media requests per page 407 of the Retrospect Windows 16 User's Guide. That would, by showing any problem with "Lenovo730" backups, IMHO eliminate the need for the script hooks that Nigel Smith suggested. P.S.: Nigel Smith made an error below because he didn't pay attention to the second through fourth sentences of my third paragraph; a Windows Client has no equivalent to a retroclient.state file. I've deduced this from a KB article and an R.T.S. post, but you can check that deduction with R.T. S..
  9. DavidHertzberg

    Yet another -530 client not found error

    x509, Nigel Smith's suggestion in the next-to-last paragraph directly above is excellent. However if the lock file hypothesis is correct, it sound as if the "client" you now refer to as "L" is never backed up. I will use my immense psychic powers 🤣 to guess that your client "L" is actually the same "Lenovo730" you were talking about in the OP a year ago today (Happy thread Anniversary!). And two months later you solved a problem with what is probably the same "client" computer by doing this. So why not do it again, which should get rid of any lock file that is related to "L"'s Client? But I also notice that the Lenova Yoga 730 came out about 2.5 years ago. With two similar problems in one year, is it possible that your C:\ drive is failing in a way that affects the Client? Nigel Smith or Lennart_T can advise you better than I can on how to test that.
  10. DavidHertzberg

    Yet another -530 client not found error

    x509, How soon we forget! 🤣 Here's a December 2019 post by you yourself in this Forum, telling how you solved what seems to be this very problem on one of your "client" machines by thoroughly un-installing and re-installing the Retrospect Windows Client. My preceding post in the same thread pointed out that there's supposed to be a Protected by Retrospect Server checkbox line, described on page 304 of the Retrospect Windows 16 User's Guide, in the Retrospect Client Control Panel. However on page 305 of the same UG there's an Allow Clients to Turn off the Retrospect Client Software preference in Configure > Clients in the "backup server" console sidebar. Maybe you've un-checked that preference for this particular "client", which would explain why "there is no way for the client to turn itself back on." The preference was added years ago; users with slow "client" machines were turning off their Client to disable backup. P.S.: Retrospect Windows 17.5.0.237, released on 23 September, doesn't contain a fix for bug #8512. MrPete says the bug is only in the Windows variant, but I don't see why at least the cause—if not the must-reboot-the-"client"-machine fix—isn't the same in the Mac variant as well.
  11. DavidHertzberg

    -1104 errors

    rfajman, I think you must only be having this problem when backing up to a disk destination, so it shares that with the problem described in your other thread. However it's for server as well as client backups, so the commonality may only be in having various funny things—per Nigel Smith—going on with the destination disk. As to that, take a look at this 2019 Forum post, which I found by clicking the magnifying-glass icon in the Search box on the upper right and typing in "1104" (this time with the double-quotes). The very-expert-in-Retrospect-Windows Lennart_T diagnosed that OP's problem as being with the source Windows (C:) drive, although the OP produced evidence that the problem went away with a different method of connecting his destination drive to the "backup server"—whose (C:) drive was evidently the source.
  12. DavidHertzberg

    -643 errors with client backups

    rfajman, It's time you learned how to use the Retrospect Knowledge Base. Navigate your web browser to www.retrospect.com/support, click the "Knowledge Base" icon, and do a search on "-643" (without the double quotes). You'll find this 2017 article, which says "If the Retrospect process ends unexpectedly, it could result in problems saving some of temporary data files that are used when negotiating security with your servers". It looks as if its solution may solve your problem. OTOH that doesn't explain why you get no error with cloud backups; Nigel Smith's suggestion might help to provide that explanation—which may have to do with temporary files that aren't used for your cloud backups because they're scanning fewer source directories (how's that for a SWAG? 🤣 ). As for the CHKDSK flags asked about by Nigel Smith, here's a Lifewire article explaining them. I found that by Googling "chkdsk windows 10 commands"(without the double quotes). However the KB article linked-to in the preceding paragraph says the problem is likely to be with Retrospect temporary files on the "backup server", not with the disks being backed up.
  13. DavidHertzberg

    Proactive job scheduling

    Nigel Smith, Sorry, per further reading the second paragraph in my preceding post proposes a wrong solution. Circumstances of my making the post are personally embarrassing; I did so early on the morning of Yom Kippur, when in other years I would have been on my way to a synagogue. However this year—due to the COVID-19 pandemic—I had to participate in services by watching YouTube live feeds at home, and—having made my preceding post just before the start of the Sunday evening service—I couldn't resist the temptation to take a quick look at this Forum before the start of the Monday morning service—and to post a quick reply while you and Jan Löwe would see it. Now I've got another sin to repent of, which is hastily-written reply posts. Step 2 of The Algorithm's decision tree says: It looks to me as if the looping in the algorithm is not going back to Step 2 after each successful backup, maybe as an unintended (or trade-off?) result of the "10x Faster ProactiveAI" enhancement in 17.0.0.149. Here's The Algorithm's last step; "moves on" should mean looping back to Step 2: If so, this is some kind of loop-back bug, possibly fixed in Retrospect Mac 17.5.0.185—the following bug fix sounds like it's to the same piece of code: Jan Löwe, Please upgrade your "backup server" to Retrospect Mac 17.5.0.185, rerun your previous test, and then—assuming you get the same erroneous results—submit a bug-fix Support Case. All you need to do for the Problem Statement is to copy the longest paragraph in your second post in this thread, and then append the result of that further test as an Additional Note.
  14. DavidHertzberg

    Proactive job scheduling

    Nigel Smith, You're right on both counts; I didn't read Jan Löwe's second post in this thread anywhere nearly thoroughly enough 😢 , probably because he posted it while I was writing a post myself. Please accept my apologies. However it appears that the analysis in the second point of my most-recent post isn't a total waste; the paragraph below the quote pinpoints what the bug is. When the destination of a Proactive script is a Storage Group, the "backup server" should immediately generate all "child" Proactive scripts—placing them into the "Waiting" queue in defiance of the second quoted Note. That way each "child" script for which there is initially no available activity thread would start to execute as a preceding "child" script finished executing—making an activity thread available. Jan Löwe, Please ASAP do the test Nigel Smith suggests in his last paragraph of the post immediately above this one, and submit a Support Case. It's now clear that it's really for a bug in an existing feature, so here's how to do that. I'd submit it myself, except that my past experience has shown that Retrospect Tech Support will ask the person who submitted the Support Case to test at least possible bug fix—and I no longer have enough "client" machines in my installation to do that. All you need to do for the Problem Statement is to copy the longest paragraph in your second post in this thread, and then append the result of that further test as an Additional Note.
  15. DavidHertzberg

    Proactive job scheduling

    Nigel Smith, First, I don't know what you mean by "Mac script" and "PC script" in Jan Löwe's situation. He says all his scripts are running on a macOS Catalina "backup server", and there's nothing that says a single Retrospect script can't backup "clients" of both OS varieties. In fact from 2001–2004 I used to include as a "client" the drive on my Windows 95 "grey box" PC, which my bosses' boss had forced on me for work-from-home use so I wouldn't infect the rest of the office with a recurrence of shingles (his mother was Native American, and although he was a graduate of New York University he had certain non-modern health concepts), in a weekly Recycle Backup script—running on my Mac "backup server"—that also included my wife's and my Mac "clients". Although I don't use Proactive scripts, I'd expect that to apply to them as well. Second, I don't think anything in the Engine's handling of multiple activity threads—execution units in Retrospect Windows parlance—has changed with the introduction of Storage Groups. Because Engine multi-threading was introduced in Retrospect Windows 7, here's a quote from page 161 of the Retrospect Windows 7.5 User's Guide (belatedly copyrighted in 2011)—whose explanation is simpler than in later editions: IMHO the Notes would apply to a Proactive script whose destination is a Storage Group. Such a script simply attempts to launch a "child" Proactive script for each client-volume in the script's Sources; if there isn't an available activity thread, the corresponding "child" single-source Proactive script's launch goes into the "Waiting" queue—but only if the second Note doesn't apply). When such a "child" script has backed up its single Source, what's left for it to loop on? One solution would be if a multi-Source "parent" Proactive script were also running—looping while monitoring completion of the single-Source "child" Proactive scripts, but I can see nothing in pages 37–45 of the Retrospect Mac 17 User's Guide that says that feature exists yet. Don't expect it to be added soon. It won't be needed if the second Note quoted doesn't apply to a "child" Proactive script; Jan Löwe should test this. The feature does exist already, but has a bug; see this down-thread post. Third, I agree with you about the aptness of the Retrospect term "grooming"—which appears in the Retrospect Windows 7.5 UG and thus can have originated no later than 2007. However I think Jan Löwe's objection is similar to the reason the bossy Retrospect developer had for banning the use of the term "snapshot" in the Retrospect Mac 8 UI. Both terms have acquired other more-popular connotations, in criminology for "grooming" and in Computer Science for "snapshot". Welcome to the wacky world of English language development. 🤣
  16. DavidHertzberg

    Proactive job scheduling

    Think nothing of it, Nigel Smith. 😄 My preceding post started out as a correction of your preceding post, but then I realized that Jan Löwe's fundamental problem seemed to be (he's just made a second post) that he didn't understand the use case for Proactive scripts—whether following the pre-2018 algorithm or the "AI" (I agree with him that "AI" is a bit of a naming stretch for what is really an "expert system") algorithm. I'm running 16.6. Jan Löwe, Don't worry about posting in the wrong Forum; over the years many Retrospect Mac administrators have been confused by the "Professional" title for this Forum. 🤣 I'll change the User's Guide links in my previous posts to also reference the Retrospect Mac 17 UG page numbers. If your two Proactive scripts are each spawning multiple Activity Threads, then their destinations must be Storage Groups. What you don't yet realize is that Storage Groups, with their current limitations, are basically a kludge intended to save administrators from the bookkeeping that would be required for creating multiple Proactive scripts with explicitly-separate (to avoid conflict) Media Set destinations. AFAICT the use of a Storage Group currently doesn't create any "parent" Proactive thread that is looping while keeping tabs on the progress of the "child" Proactive activity threads; the looping is in each "child" thread—but that has AFAIK only one Source machine-volume so the looping is only theoretical. It would be wonderful if there were such a "parent" thread, but that new feature—which your Support Case should suggest—would require inter-process communication that would AFAIK be different for Retrospect Mac vs. Retrospect Windows (challenging the common-code-since-2009 foundation of the Engine). I've been told that the Retrospect "Inc." staff is now busy with meetings centered on StorCentric management's requirements, so don't expect that feature to be added soon. The third sentence in this paragraph is wrong; the Proactive script itself is supposed to be the "parent" thread—with no looping in the "child" thread, but there's an apparent bug in the "parent" looping—see this down-thread post. Therefore IMHO what you should do is to go through the bookkeeping of creating multiple scripts. Some Proactive scripts can be for "client" machines that you know have been backed up before—possibly for "departmental" or "arrival-spread" subsets, and may use a Storage Group destination to enable parallel execution—which the Engine will keep track of but without looping. OTOH each "new client" machine should have its own separate script with its own separate destination Media Set, and IMHO that should be a one-time-scheduled Backup script—with a Recycle media action—that can keep running over a daily boundary until it finishes. After it finishes, you can run a Copy Media Set operation to copy the Media Set into the Storage Group; that run can overlap with other script runs using the same Storage Group for other "client" machines, and can then re-use the same Media Set with a Recycle media action for your next "new client" Backup. My warnings in my third post in this thread about Storage Group limitations continue to apply, especially for Retrospect Mac—where the GUI for accessing Storage Group component Media Sets doesn't exist yet. BTW, are you in real life the director of a laboratory in Cambridge UK? (Or did you just pick his name as a Forums "handle"?) Just asking because it's helpful to know something about an administrator's installation; I've been quite open about my own. Nigel Smith's installation may resemble yours.
  17. DavidHertzberg

    Proactive job scheduling

    Jan Löwe, This post will be the last of my thoughts on your problem, unless and until we get further information from you. That information must include how many Proactive scripts you currently have scheduled, and what those schedules are. What you are asking in your OP is whether we agree that "that's poor behaviour of the scheduler that should make jobs active whenever required AND possible, and should prioritise those clients that have never been backup up to the current set." I don't agree, because I think the use case for Proactive scripts described in the first paragraph of my second post in this thread has satisfied the needs of many administrators for over 20 years. You OTOH have a different use case that prioritizes clients that have never been backed up to the current Backup Set. I've explained in the remaining paragraphs of my second post how you can achieve that prioritization using separate scheduled Backup and Transfer scripts, and I've explained in my third post in this thread how you might be able to achieve that same prioritization using Storage Groups—despite their limitations. What you may not fully appreciate, because the explanation on pages 197-198 of the Retrospect Windows 17 User's Guide is unclear (unlike page 108 of the Retrospect Mac 17 UG), is that the longest you can schedule a Proactive script is from midnight to midnight on a particular day. A daily Proactive script starts again with a new "backup window" on its next scheduled day, where—per "Algorithm" step 7 on page 191—"Sources with faster previous backups will be backed up sooner than sources with slower previous backups." The "Algorithm" sub-section (which is a duplicate of the Knowledge Base article I have linked to in up-thread posts) doesn't explain what priority is given to a brand-new source on its first Proactive backup. However the section lead on page 190 says "With ProactiveAI, backup scripts will optimize the backup window for the entire environment based on a decision tree algorithm and linear regression to ensure every source is protected as often as possible", which clearly means per step 7 that a new source that has been backed up at least once for several hours will get lower priority than an old source whose previous Normal incremental backup took a shorter time. That's why per your OP "it takes many days for all clients to be backed up for the first time (while others get incrementally backed up in the meantime)". As I said in the third paragraph of my second post in this thread, you could file a Support Case asking for an option that would implement "Sources with faster previous backups will be backed up later than sources with slower previous backups." But I doubt the feature request will be accepted, for the reason I've given in the second paragraph of this post.
  18. DavidHertzberg

    Proactive job scheduling

    Jan Löwe, When I finished writing the first of my two up-thread posts, I still thought your problem was in not having enough "execution units" to provide sufficient parallelization of Proactive "client" backups. That accounts for my next-to-last paragraph in the post. However. as I started writing the second of my up-thread posts, I decided your fundamental problem is doing from-scratch backups of "client" machines via Proactive scripts that also do Normal backups of other "clients". Let's consider this in terms of what Nigel Smith said up-thread: The maximum—not just the default per mbennett—number of "execution units" that can run simultaneously on one Retrospect "backup server"—with 20GB RAM—is 16 , whether the "execution units" are from explicitly-separate scripts or in-parallel "execution units" implicitly generated by using a Storage Group as the destination for a Proactive script—as Nigel Smith suggests. (Page 325 of the Retrospect Windows 17 User's Guide and page 166 of the Retrospect Mac 17 UG still say 8, but the fix for bug #1366 shown in the cumulative Retrospect Windows Release Notes shows that had been increased to 16—which I've confirmed in my Preferences ->General for Retrospect Mac 16.6—by November 2012.) Your OP says you have to back up about 30 "clients", and when I attended primary school 30 was greater than 16—so there's no way you can back up all your "clients" at once. As I said in the third paragraph of my second up-thread post, a fundamental part of the ProactiveAI decision tree algorithm is that "Sources with faster previous backups will be backed up sooner than sources with slower previous backups." I don't know whether a Proactive script that has completed one of its incremental "client" backups will release the "execution unit" for that backup while a from-scratch backup using the same Storage Group destination continues. I suspect it will, but you're going to have to test that out with a couple of Proactive script runs that cover all 30 "clients" using the same Storage Group destination. It turns out it should but it won't; see this down-thread post. If it works, you can have one Storage Group for all 30-odd "clients", and not run—as I suggested in my second up-thread post—separate scripted Backup runs followed by Transfer Backup Sets operations for the from-scratch backups. However be aware that, to avoid a confusing GUI mess, the Retrospect engineers required in 2018 that a Storage Group be defined with its first Member for all component Backup Sets on a single HDD or cloud equivalent. At least one administrator posting on these Forums has reported a problem with the first Member for one component Backup Set apparently prematurely running out of space. It's not yet clear whether one can define a second Member for an entire Storage Group, or whether one can do this for an individual component Backup Set (which isn't yet an option for a Retrospect Mac "backup server", because the engineers—before their new StorCentric masters diverted them to other tasks in Fall 2019—evidently didn't have time to enhance its GUI to enable accessing an individual Media Set—the Retrospect Mac term for Backup Set—component of a Storage Group). If one can't, you may have to Transfer Backup Sets off Storage Group component Backup Sets and re-initialize the components; that would be messier than what I suggested in my second post up-thread. Nigel Smith's quote also says that a Storage Group creates a separate component Backup Set for each volume attached to each "client" machine—I've verified that. So if some "clients" have more than one volume attached, you'll have more than 30-odd component Backup Sets in your Storage Group.
  19. DavidHertzberg

    Proactive job scheduling

    Jan Löwe, Proactive scripts were developed in the late 1990s for AFAIK the following use case: Sally SuperSalesperson visits the central office irregularly on a non-predictable schedule. You as administrator want to do a Normal incremental backup of Sally's laptop whenever she cables it up (or connects via WiFi) at the central office, so that the organization won't lose her valuable data if her laptop is stolen or is destroyed in a car crash. The organization has many female and male SuperSalespersons, each with his/her own schedule for central office visits—schedules which tend not to overlap. It is assumed that Sally's laptop was given a New Backup Set backup via a Backup script after the initial organization software needed for her position was installed, before her boss first handed it to her. So why are you "doing a complete backup once in a while" via a Proactive script? A Retrospect "backup server" can run a maximum of 16 scripts in parallel "execution units" (page 211 of the Retrospect Windows 17 User's Guide and page 166 of the Retrospect Mac 17 UG still say 8 because they haven't been updated as of November 2012), and that's on a machine that has 20GB or more of RAM. Have each employee with a new "client" machine leave it at the central office overnight, so you can use it as a Source for a scheduled Backup script with the New Backup Set action to its own backup set—which you will then copy via a Transfer Backup Sets operation (pages 132-134 of the Retrospect Windows 17 UG, pages 118-120 of the Retrospect Mac 17 UG for Copy Media Set) to the backup set which will be the destination for its Proactive script with the incremental Normal action . If you read "Algorithm" step 7 in this Knowledge Base article, you'll see "Sources with faster previous backups will be backed up sooner than sources with slower previous backups." That's a feature of the 2018 "ProactiveAI" decision tree, and it explains why you complain "it takes many days for all clients to be backed up for the first time (while others get incrementally backed up in the meantime)." Here's what to do if you want to attempt to get this feature changed, but I can assure you that the Retrospect engineers went to a lot of trouble to change the late-1990s scheduler algorithm that did have the prioritizing you want. You could try asking for an option to invert algorithm step 7, but who besides you would want it? BTW, in my simple home installation I use only Backup scripts; I just boot the "backup server" to backup my single "client" machine at or after 3 a.m..
  20. DavidHertzberg

    Proactive job scheduling

    Jan Löwe, First let's get some preliminary questions out of the way: How long ago did you last use Retrospect? Was it before 2009, when Retrospect Mac was resurrected with a different User Interface from Retrospect Windows after being end-of-lifed? Are you running Retrospect Windows on your "backup server" machine, or Retrospect Mac? The "backup server" Engines have common code, but the User Interfaces have different terminology and look different. (An old-timer in Sales says a key member of the team creating Retrospect Mac 8 was very bossy, and insisted that the old terminology and Graphic UI had to go. Mostly because Retrospect Mac 8—having been developed in a management-imposed rush—was very buggy and incompatible with older machines and existing backups, it got such a bad industry reputation that the Retrospect team decided not to make the corresponding changes in the Retrospect Windows terminology and UI.) Because you posted in the Windows—Professional ("Professional" as distinct from "Express"—a simplified Retrospect application for Windows that is no longer sold) Forum, I'll assume your "backup server" runs Retrospect Windows and use that terminology—which is a slight problem for me since I use Retrospect Mac. Precisely what version of Retrospect Windows or Retrospect Mac are you running? You should upgrade ASAP to 17.5.0.x. When you say "parallel backups", do you mean from different scripts? "jobs" isn't a Retrospect term, and an individual Retrospect script cannot backup multiple "clients" in parallel—unless the script's destination is a Storage Group instead of a Backup Set. Are you using the Remote Backup feature? It was developed in 2018 for use by a centralized organization with a few employees/contractors working in scattered far-away places, but has been recently hurriedly adopted by centralized organizations that have sent many employees off to Work From Home nearby. The implementation of Remote Backup has a kludge that didn't matter much in 2018; IMHO you shouldn't use it if you don't have to.
  21. DavidHertzberg

    simple question on uninstaller for Mac Retrospect

    Thanks, Nigel Smith. I did what you said in your second paragraph directly above, since I wanted to uninstall Retrospect from my "client" MacBook Pro—where I had installed it per my second paragraph in this up-thread post. After I replaced my Mac Pro's PRAM battery, I had used System Preferences->Retrospect (not System Preferences->Retrospect Client) to stop the Engine on my MBP—so I didn't want to start the Engine (->run scheduled scripts) to Uninstall itself. So I did "Export server installer and uninstaller" to a thumb drive connected to my Mac Pro, then took the thumb drive over to to my MBP and ran the un-Zipped "Retrospect Support.app from there. Before doing that I followed the procedure on pages 196-197 of the Retrospect Mac 17 User's Guide (which is on a different page in the Retrospect Mac 16 UG; I was uninstalling Retrospect Mac 16). Note that what page 197 says is ~/Library/Preferences/com.Retrospect.plist has an extra "Retrospect" as part of the name.
  22. DavidHertzberg

    Only Have RDB Files

    wanderlust, The head of North America Sales says someone was trying to do what you want to do, but was stymied because the Media Set was encrypted and the password wasn't available. If that was you and you are a legitimate relative, I'm sorry. If OTOH that was you and you are a hacker, you've provided a security lesson to us all. Now I'll reveal what I should have written in the second paragraph of this up-thread post: You should first find out the name of the Media Set—I'll call it "Whatever" for this example— that was backed up onto your relative's hard drive, by looking at the name of the folder inside the "Retrospect" folder on it. You should then start Retrospect and—clicking Media Sets in the sidebar—Add (not Rebuild) a Media Set with that same name "Whatever". Add's default places the new Catalog File inside Library->Application Support->Retrospect->Catalogs on your own Mac. When Retrospect asks to Add a New Member for "Whatever", you should select the Retrospect->"Whatever"->"1-Whatever" folder on your relative's hard drive. Don't Add any more Members. I've previously done this (how did I navigate to Member?), but haven't newly Removed and re-Added an existing Media Set on my own "backup server".
  23. DavidHertzberg

    Yet another -530 client not found error

    Nigel Smith, I'm sorry my last up-thread post consists of four lengthy paragraphs. I felt I had to present my alternative proposals side-by-side in the same post, in order to avoid having the reader bounce back-and-forth between different posts. First, with regard to all my paragraphs except the third, let's go back to what "came out of the horse's mouth" on 5 September. MrPete said: The proposal in my fourth paragraph is to first automate what MrPete said—after the quoted word "than"—would be less easy to do manually. The user (or a script) wouldn't have to do those things if the user's Client had stored within itself—by the "backup server" at Add time—a pre-formatted "ipsave address" for the "backup server". As I said in that fourth paragraph, if the Client found that automation didn't work then it would know (based on the "hide-and-seek principle") it has to restart itself—because otherwise the "backup server" at that "ipsave address" won't be able to contact the Client at the address the Client is bound to. This proposal would also get around the messy fact that an administrator who won't allow the user to stop and start his/her Client probably doesn't want that same user to be mucking about with a manual ipsave. The proposal in my third paragraph emerged from my memory after I drafted all my other paragraphs. Despite what you said in the last paragraph I've quoted at the top of this post, the fact is that a Retrospect Mac Locate command did work when I was having trouble with "clients" Added via Use Multicast—precisely in the case that the "confused client's" Client was bound to an address that the server couldn't reach. Since what's activated by a Retrospect Mac Locate command must be in the Engine's code—which is common to both Retrospect Mac and Retrospect Windows, there undoubtedly is a way of activating a Locate-equivalent that will work for Windows and Mac variants. Figuring out what—if any (because the Retrospect Windows GUI has been intentionally "frozen in stone" since version 7.7)—command in Retrospect Window's GUI is equivalent to a Retrospect Mac Locate is "above my pay grade", but the engineers should be able to activate underlying common Engine code per the proposal in my third paragraph. P.S.: I have now, crediting you, added your post directly below as an Additional Note to Support Case #75559.
  24. DavidHertzberg

    simple question on uninstaller for Mac Retrospect

    d37fc1fe-a25d-4df0-9b52-cb21971f1fde, So are you now running Retrospect Mac 17.0.2.101 Single Server Edition on a separate dedicated Mac? Release 17.0.1.141 especially had a lot of bug fixes, as the cumulative Mac Release Notes show. Most of the bug fixes are for new Retrospect features, which you're probably not using. Unless you're using the new features, I suspect your "troubleshooting and bugs" are mostly because of recent versions of macOS. For about a week I was running Retrospect Mac 16.6 Engine and Console just fine on my principal-machine MacBook Pro, because the 2010 "cheesegrater" Mac Pro I use as a Desktop Edition "backup server" wouldn't boot (which I eventually fixed with a replacement of its PRAM battery). However my MBP is booting macOS 10.13 High Sierra, and my Mac Pro is booting macOS 10.12 Sierra; neither version is recent. I suggest you phone Tech Support—which no longer reads the Forums—at (888) 376-1078‬ ext. 3; if you upgraded to Retrospect 17 in the last 30 days, you're entitled to free personalized support. If you don't have a dedicated Mac to use as a "backup server", you can buy an old one for a few hundred US$—although I inherited my 2010 Mac Pro. OTOH if you can wait until the end of the year, I've read StorCentric management predictions backed up by titbits from Sales that Retrospect "Inc." is developing a variant of the Engine that will run on at least a beefed Drobo—which may turn out to be more expensive than an old Mac but can also be used as a NAS. You might be able to use the NAS capabilities to replace macOS Server, saving several hundred US$ on your next release of Retrospect by allowing you to downgrade to Desktop Edition. When you talk to Tech Support, you can ask them how to uninstall the Retrospect Mac Engine—since its location is apparently intentionally not in the Applications folder. In the mean time, you can just turn off the Engine in System Preferences->Retrospect. I just Quit the Console each time I boot my MBP, but I could uninstall that with https://freemacsoft.net/appcleaner/ . If OTOH you've actually decided to scrap Retrospect, send me a Private Message and I'll reply with the name of a "push" backup application that—up to its latest version with problems akin to Retrospect Mac 8—is well thought of. Naming competitor apps in Forums posts annoys the head of R. T. S..
  25. DavidHertzberg

    Yet another -530 client not found error

    Nigel Smith, This KB article says "The Retrospect Client uses the ip and ipsave commands to allow users to direct Retrospect backup traffic through a specific IP address if it is available to the machine the client is installed on." IMHO that means the only way manual ipsave might be made to work is if [1] the "client"'s user knows the the IP address of the "backup server", and [2] the "client" machine—which has "wandered" by either being physically moved to another subnet or by having its IP adapter switched from from a cabled to to a WiFi connection (or vice versa)—can still connect to that "backup server" IP address. However IMHO that would only work if the "client" is set up as a Remote Client and is backed up with a Proactive script, in which case the Client takes the initiative in contacting the "backup server". The -530 problem MrPete and x509 are dealing with is that—as diagnosed by MrPete in this up-thread post—the Retrospect Client for a particular "client" is getting confused, either by getting assigned a virtual interface by Windows APIPA or VMWare, or by a security system, or by a router. That means the "backup server" can't contact the Client for a non-Remote backup. MrPete's solution is to "unconfuse" a "client"'s Client by restarting the Client. As for APIPA, this article says "The APIPA service also checks regularly for the presence of a DHCP server (every five minutes, according to Microsoft). If it detects a DHCP server on the network, APIPA stops, and the DHCP server replaces the APIPA networking addresses with dynamically assigned addresses." So making the "backup server" wait 5 minutes before trying to back up a "wandering" client" might do the trick. However I just remembered this trick for "unconfusing" a "client"'s Client, which worked for my MacBook Pro "client" when I was still Adding it to my Retrospect Mac "backup server" with Use Multicast instead of Add Source Directly (using a fixed IP address)—which MrPete has said doesn't solve his -530 problem. This suggests having the Retrospect Windows "backup server" automatically do the equivalent of Retrospect Mac's Locate (page 51 of the Retrospect Mac 17 User's Guide) 15 minutes before it starts to back up each particular Backup script "client". If the "client"'s Client has been assigned a virtual interface by Windows APIPA, the Locate-equivalent alone should "unconfuse" it. If OTOH the "client"'s Client has been assigned a virtual interface by VMWare, or has gotten confused by a security system or a router, then the Locate-equivalent will fail—in which case the "backup server" should send an e-mail to the Retrospect administrator. I suggest doing the Locate-equivalent 15 minutes in advance because the Retrospect administrator, upon receiving the e-mail, may have time to fix the "client"'s problem before the script begins to back it up. Looking at a post in another thread later, I was reminded that the "backup server" already does "reaching out" to Proactive script "clients" per steps 3 and 4 of this KB article —so extending that "reaching out" as a Locate-equivalent for Backup scripts wouldn't be as "effortful" as the first sentence of the next paragraph says. But that at first seemed effortful, so here's another way or "unconfusing" a "client"—an extension to the suggestion I made in the second paragraph of this up-thread post: Have the "backup server" store its own IP address, which I'll call the "ipsave address", in the Client of each "client" machine added to its Sources. Then, when a "client"'s Client starts up, let it try to contact the "backup server" at the "ipsave address". If it can't, then the "client"'s Client should restart itself—because it must have been "confused" by being re-assigned an address by APIPA or by VMWare or by a security system or by a router. (This is based on the "if I can't see you, then you probably can't see me" principle we all learned as children playing hide-and-seek.) A "client"'s Client successfully contacting the "backup server" for address verification would only be a slight variation of what is already done by a Remote Backup "client". Possibly there should be a script run option to wait 5 minutes before backing up a "client" whose Client has not contacted the "backup server". P.S.: I have now created Support Case #75559, from this post preceded by links to appropriate preceding posts in the thread.
×