Jump to content

DavidHertzberg

Members
  • Content count

    1,378
  • Joined

  • Last visited

  • Days Won

    49

Posts posted by DavidHertzberg


  1. I don't archive, and I Recycle each of my rotating Media Sets every three weeks, so I've never been faced with this problem.  However I think barup should look at this YouTube video, especially from minute:second 0:20 to 2:25.  Unfortunately Retrospect Inc. only made a version of that video for Retrospect Windows, so barup will have to get used to Media Sets being referred to as Backup Sets and other UI differences.  The equivalent operation is documented on pages 128-130 of the Retrospect Mac 14 User's Guide.

    My basic idea is that, by searching for at least some the file/folder names he/she wants to Restore, barup will be able to see the dates on which those files were written to the Backup Set used for archiving.  That should give him/her an idea which drives are needed.  If the drives haven't been externally labeled with the dates they span, he/she can look at the creation and last-updated dates of the the Media Set members (the files that start with a number followed by a dash within the folder for the Media Set within the Retrospect folder) on them using Get Info.


  2. Two weeks ago I put an SSD into a spare bay in my 2010 Mac Pro "backup server" machine.  After doing a Restore of the 12-year-old boot HDD to the SSD and re-creating my Media Sets (with some problems) so their Catalog Files are on that SSD, I ran my weekly Recycle backup of all my 6 drives yesterday—booting from and running Retrospect on the SSD.

    The run on 6 January did a LAN backup of my new MacBook Pro in 2.25 hours, vs. the 2.5 hours the backup of essentially the same files from my new MacBook Pro had taken on 9 December.  So speeding up the drive on the "backup server" machine makes a slight difference, but not nearly as much as speeding up the processor chip on a "client" machine.  It would be interesting to see what effect a faster processor chip on the "backup server" machine would have; since the "backup server" is a "cheese grater" Mac Pro it would be fairly easy technically to do, but I don't have the budget for an upgrade—which based on past experience wouldn't have that dramatic an effect (see the P.S. here).


  3. Macspt,

    A quick look at your past posts makes it appear that you may not be familiar with the capabilities of recent versions of Retrospect, so I am wondering whether you are aware of the enhancements to the Grooming feature that were added to Retrospect Mac 12 and 13.  I mentioned them in the first paragraph and the P.P.P.S. of this post in another thread

    With the "new grooming option [that] allows you to determine the number of months of backups to keep" , you might not need to recycle your 13.7TB Media Set at all.  That assumes that your installation is saving some kind of text documents, so that you don't necessarily need to save every version of them in order to satisfy regulatory authorities.  If OTOH your installation is saving video or audio documents, where every version may be important, Grooming would not be appropriate.  In fact another client-server backup app, whose developers at one point attempted to compete with Retrospect but decided around 2009 to concentrate on a "desktop archival and recovery application designed specifically for the Music, Film, and Television production environment", AFAICT never developed a Grooming feature.  That app, which I'll refer to here as TB, still emphasizes its capabilities for backing up to tape—which of course cannot be Groomed; I'll assume your installation is not that kind of environment, since your Media Set consists of disks.

    HTH


  4. It all depends on what your backup objective is, Macspt

    If your objective is to maintain a single comprehensive backup of your source volume, then you should have a single disk Media Set rather than two—with your two backup disks as the two Members of that Media Set.  To understand why using two separate Media Sets will not result in "striping", read the third paragraph after the bolded paragraph in this section of the old version of the Wikipedia article.  That section—because it refers to Retrospect Mac 6 and previous versions as well as Retrospect Windows—uses the term Backup Set instead of Media Set, but  it is still the case that "Retrospect maintains a separate Catalog File—distinct from any OS-maintained directory—on disk for each [my emphasis] Backup Set."  So when you asked "is it simply copying all of the same data to both Media Sets on a rotating bases?", the answer is yes.  Besides, if "striping" was actually being done and you wanted to restore a particular daily version of a rapidly-changing document, how would you know which Media Set to use unless you knew which day of the week the version had been backed up?

    If OTOH your objective is to maintain two comprehensive backups that are the same except for the most recent day, so that you can keep the least-recent backup off-site, then you'll have to buy an additional backup disk with a capacity as big as the two you already have.  This may not be as big a financial burden as you think; large-capacity disk drives are getting cheaper each month.  For carrying off-site  the Media Set that has as its two Members the backup disks you already own, I suggest buying a cheap chest-pack camera bag—as I did for carrying  on the bus the disk drive I took home weekly at my last job.


  5. 1 hour ago, Pete said:

    OK, skip team viewer and just run a direct screen-share via VLC or the like.

    I think Pete's finger slipped.  I don't think he means the VLC media player, but the VNC graphical desktop sharing system.  If  Pete looks at the 2015 Ars Technica thread I linked to, but starting with the OP, he will find that the thread is titled "Any way to improve VNC performance?" for a very obvious reason.  The conclusion of the Ars Mac hive mind by the end of the thread was that RealVNC—which actually uses the RFB protocol—with the proper settings might give much closer to screen-sharing performance than TightVNC running on a Windows machine to access a Mac.


  6. On 1/3/2018 at 2:10 AM, Lennart_T said:

    You could run TeamViewer (or equivalent) to control the Mac "Server" from any PC or Mac.

    Of TeamViewer, the OP of the same Ars Technica Mac thread wrote, in a post preceding the one I linked to above,  "Teamviewer is my last resort, simply because it adds another level of complexity and I'd be SOL during an internet outage, even with both machines in the same house. I'd really prefer a simple, LAN-based, client-server model."   That's evidently what RealVNC is.

    For the benefit of non-native (or non-American?) English speakers such as Lennart_T, SOL is slang defined here.


  7. I consider this to be a fascinating topic, because it is pretty much the flip side of what Don Lee—under his former "handle" iComputehad suggested to him (by me) at one point as a solution to his problem in another  thread.  At the end of that thread, iCompute was going to try controlling his Retrospect Windows "backup server" from a Retrospect Mac Console—which he had discovered could be done; from the second post in this thread, that evidently turned out to be at least somewhat unsatisfactory  (why didn't he post that outcome in the other thread?).

    As explained by DovidBenAvraham in the last sentence of the first paragraph in this section of the current Wikipedia article, there is indeed no Console app for Retrospect Windows.  The second paragraph of this section of the old WP article describes in later-deleted detail some measures that Retrospect Windows administrators have found to get around that difficulty.  And one of those measures gave me a idea.

    IMHO what Monafly should try is to effectively do the equivalent of running Retrospect Windows "backup server" via Windows Terminal Services (obsolete name, but it's what is used on pages 434-436 of the Retrospect Windows 12 User's Guide).  However based on a search of the Ars Technica Mac forum, Monafly should not try to do this via Apple Screen Sharing and VNC, because it doesn't work well using a Windows client.  The recommended approach in this post there is to use some version of the RealVNC application.  I have no experience with it, so YMMV.  My idea would be to run the Retrospect Mac Console on the same machine as the Retrospect Mac Engine, install a RealVNC server on that machine, and use a RealVNC client running on Monafly's replacement's Windows PC.  Security?  I've heard of it; presumably so has RealVNC Ltd..

    An alternative approach, which I have 1.5 years experience using to control two Macs (one a Digital Audio G4 running OS X 10.3 or OS 9.1) using a single keyboard-videoscreen-mouse, is to buy Monafly's replacement a Mac Mini—to sit somewhere within cable distance of his Windows PC—plus a KVM switch.  The Retrospect Mac Console would run on the Mac Mini, unless Monafly's installation has the Desktop Edition of Retrospect Mac—in which case it might be possible to cable the KVM switch to the "backup server" machine itself instead of a Mac Mini.  The particular model of KVM switch would depend on the connection capabilities of the colleague's video monitor; I use an ATEN CS782DP KVM switch to connect to my DisplayPort-input 27-inch Apple LED Cinema Display (somewhat obsolete, but it's what I inherited).  This approach would work well if the colleague is going to use the Retrospect Console a lot, and it would also make Tim Cook happy if Monafly's installation needs to buy a Mac Mini (insert appropriate smiley here).


  8. 3 hours ago, redleader said:

    The Posts seem to have got out of sync ... so, to recap ...

    Mac Server using Retrospect is on .100 manually in it's system prefs network panel.
    Mac Server using Retrospect is on .100 manually on the routers reserved devices list.

     

     

    I understand that.  IMHO the key question, for one of your WiFi-connected clients, is (to quote myself two posts up) if you "go to System Preferences and double-click the Retrospect Client icon while holding down the Command (apple or cloverleaf) key.  Then click the Advanced tab.  Do you see Server Address 192.168.1.100? "  When I was experimenting with a static IP address for my backup server the other day, I wasn't getting a match between the address the backup server was on in its own Systems Preferences->Network->Advanced panel and the address my client was looking for in its Retrospect Client->Advanced panel.

    IMHO you should send a salesperson out to an extended lunch, leaving his/her computer connected via WiFi, and investigate this question.  See what the address is on the client when it is first re-booted, see what the address is 10 minutes later, see what the address is after you click Sources->client name->Locate on the backup server.


  9. The answer is that the difference was described on page 14 of the Retrospect Mac 13 User's Guide.  Unfortunately the information about the grooming options, along with all the glorious additional features of Retrospect Cloud storage on pages 6-14 and the capability of moving the member folders of disk sets to new locations, never made it out of the "What's New" chapter where it was originally described.  Instead that information was completely over-written by the UG "What's New" information for Retrospect Mac 14 (and Retrospect Windows 12).

    DovidBenAvraham noticed this "documentation problem" when writing the original version of the Wikipedia article.  However his mention in the "Documentation" section of the article had to be deleted for reasons described in the second paragraph of this post.  I filed a Support Case about this, specifying where to move the information to other chapters in future UGs, and was told that Retrospect Inc. intends to rewrite the User's Guides.  I wouldn't hold my breath waiting for that to happen.

    P.S.: What I described in the first paragraph as "all the glorious additional features of Retrospect Cloud storage", namely Seeding for Cloud Storage and Large Scale Recovery for Cloud Storage, were relegated to a 2-minute YouTube video narrated by the head of Retrospect Technical Support.  That video is only linked to, as "Changing paths Cloud Mac", under the Mac Cloud sub-section of the Tutorials page.  IMHO without a written description it's unlikely that any administrator would find the video unless he/she already knew the features existed—and probably not even then if he/she were a Windows rather than a Mac administrator—unless he/she read this subsection of the former Wikipedia "Enterprise client-server backup" article where DBA put in a referenced mention.

    P.P.S.: IIRC, writing the Support Case specifying where to move the information to other chapters in future UGs took me about 3.5 hours.  IMHO that means actually moving the information would have taken about 3 hours for both variants of the UG, given that it was done by someone with a passing familiarity with whatever desktop publishing program (possibly MS Word) is used to maintain them.  A woefully heavy task for Retrospect Inc. :rolleyes: !

    P.P.P.S.: What I said above for the contents of the "What's New" chapter of the Retrospect 13 Mac UG is also true for the contents of the the "What's New" chapter of the Retrospect 12 Mac UG.  In that case, the only piece of information of permanent significance that was over-written is the "new grooming option [that] allows you to determine the number of months of backups to keep. This setting enables you to comply with regulations that require long term data retention for business [my emphasis], while ensuring older and duplicate files are removed from the backup set."  The meaning of that option is self-evident to any administrator who looks at the actual Grooming options dialog; however any potential Retrospect administrator wouldn't know from the Mac 14 or Windows 12 UG that the option exists unless he/she has read this subsection of the former Wikipedia "Enterprise client-server backup" article—where DBA managed to sneak in a mention of it.

    P.P.P.P.S.:  Oops, in the first paragraph of this post I left out another over-written capability in Retrospect Mac 13 (and Retrospect Windows 11)— that of moving the member folders of disk sets to new locations.  Don Lee himself caught that one here.  I've fixed the first paragraph.


  10. I remembered this afternoon that 2.5 years ago, when I started using Retrospect again, I had some connection trouble after I assigned a static IP address to my backup server—not just to my clients.  I got rid of it, and had no further problem on that score.  So I decided to do a bit of testing this evening, to see if I could reproduce redleader's problem.  Note that I do not use WiFi at all; the third paragraph in this post in another thread explains my LAN setup (the second paragraph explains the reasoning behind it).

    I added a DHCP reservation entry to my router for the Mac Pro backup server, using its MAC address.  The static IP address I assigned was 192.168.1.201, whereas before the Mac Pro's address had defaulted to 192.168.1.2 (192.168.1.1 being the default address of the router).  In spite of rebooting my Mac Pro after I had updated the router, the the Server Address in the Advanced tab of my MacBook Pro's Retrospect Client stayed at 192.168.1.2 until I did a Sources->select MacBook Pro->Refresh in the Console.  I then successfully ran a No Files incremental backup of my MBP.  I decided to get rid of the Mac Pro backup server's static IP; I did so in the router and then rebooted the Mac Pro, but a further Refresh of the MBP did not change the Server Address in the MBP's client until I manually changed back the IP address in the Mac Pro's System Preferences->Network panel—which had remained at 192.168.1.201 despite several reboots of the Mac Pro!

    My tentative conclusion is that specifying a static IP address for a Mac backup server in the router changes the IP address in the backup server's Network panel, but that de-specifying a static IP address does not change the IP address in the Network panel back to what it defaulted to before without manual intervention.  And remember, this is for Macs connected to the LAN by cable, not by WiFi.  I suggest that redleader look for discrepancies between what IP address his/her router specifies for the FS-SERVER backup server and what FS-SERVER's System Preferences->Network panel specifies.  It appears that Sources->select a MacBook Pro->Refresh changes a MacBook Pro's Retrospect Client Server Address based on what's specified in the backup server's Network panel, not what's specified in the router.

    I now remember that Alan, the former phone-answering assistant to the Head of Retrospect Technical Support, told me back in 2015 not to specify a static IP for my backup server.  I know, from one other piece of advice Alan gave me, that he tended to give Retrospect administrators the most generalized advice rather than ask them questions about their particular installation.  However it's beginning to look as if his advice about not specifying a static IP for a backup server tended to keep the administrators out of trouble.

    P.S.: A very unintended result of my testing is that I have—hopefully temporarily—truly messed up my own Retrospect backup server.  As a result, my weekly Recycle backup of 6 drives wouldn't even start correctly.  I am now completing a Restore of the Mac Pro's boot drive onto a second drive in the same machine, from a single-drive Media Set cumulative as of a week ago Friday (the Media Set cumulative as of yesterday is now sitting in my safe deposit box in the local bank branch, which wasn't open as of 4 a.m. this morning).  I will next copy over the Library->Applications Support->Retrospect folder, which should be OK if I substitute the Config80.bak file for the Config80.dat file.  Be very careful messing with the static IP address on your backup server, redleader.


  11. I first started using Retrospect in my home installation in 1995, stopped in 2010 when my backup server 7300 died of old age, and started again in 2015 when I inherited a Mac Pro to use as a backup server.  I'm already retired.

    First, from the Console , try using Sources->select WiFi Mac->Refresh.  That is item 4 in this Knowledge Base article on Error -530.

    Second, from the client machine, go to System Preferences and double-click the Retrospect Client icon while holding down the Command (apple or cloverleaf) key.  Then click the Advanced tab.  Do you see Server Address 192.168.1.100?


  12. How could I have failed to notice, back on 7 December, that both redleader's Retrospect backup server machine and client machines are Macs?  So this thread was started in the wrong forum (there is absolutely no mention of Windows machines—much less any running a Server Edition of Retrospect Windows), but—as a Retrospect Mac administrator—I'll respond again anyway.

    First, the post I linked to in the second post of this thread doesn't mention that the assigned static IP addresses must be unique within the LAN.  When I see the address 192.168.1.18 in the preceding post, that makes me suspicious; it looks like one that could be duplicated automatically by redleader's Netgear 6300 router, assuming he/she has enough clients/servers and/or printers on the LAN.  On my router I assigned the address 192.168.1.200 for my networked printer (with which I had connection problems first), and 192.168.1.202 and 192.168.1.203 for my Mac clients (I'm hoping to hit the lottery, and turn my home into a medium-sized office—insert appropriate smiley here).  IMHO redleader should do the same for his/her WiFi connected MacBooks, and possibly assign static IP addresses beginning with 192.168.1.100 to his/her cable-connected client machines for good measure; don't use any address ending in .255 or greater.

    Second, the post I linked to doesn't mention that any Retrospect client machine that is assigned a static IP address must be first Removed from the Sources list (pages 80-81 of the Retrospect Mac 13 User's Guide) and then Added back (pages 76-79 of the UG).  An undocumented tip is that when recent versions of Retrospect Mac add a Mac client source, they do so defaulting to All Volumes in the Back Up popup menu in Options (page 50 of the UG)—and that default includes pseudo-volumes that only Retrospect Add Client can see; you must change that Options popup to Selected Volumes and check-mark only the real volume(s) you want to back up.  After that those client machines must be re-Selected in all the scripts that use them (page 111 of the UG); I've often thought of choreographing a dance to accompany the steps in this paragraph (insert appropriate smiley here).  An undocumented tip (DovidBenAvraham documented this in the Wikipedia article, but other editors made him take that out because it looked too much like something that belonged in a user manual—which of course it does!) is that, after doing a Save for a revised script, you can change the order in which Sources are backed up in the script by dragging them in the Summary panel and then doing another Save.


  13. Thanks for restating your problem, lwhitten; it makes it a great deal clearer.  Actually it sounds as if the setup for your two computers is the same as mine, except your separation is vertical whereas mine is horizontal.  It makes it clear why you are using Proactive scripts; you don't want to descend to the basement, boot your backup server, and then ascend from the basement every time you need to run a backup. 

    In my case the MacBook Pro I backup once a day is in a small room my former wife named the study, while the inherited Mac Pro I use as a backup server is in my bedroom.  I'm not so decrepit that I can't walk 40 feet into the bedroom when I want to boot my backup server, and in fact I usually run the six-days-a-week incremental backup while I'm brushing and flossing my teeth.  My backup server must be in a different room from my other computers, because I have hanging over me the danger of a massive leak from an apartment two floors above mine (the owner is a junior-grade "master of the universe", who has a wife who has insisted on major plumbing/HVAC enhancements, but who lacks the basic home-repairs knowledge to prevent occasional massive leaks from those enhancements).  My apartment is in a reinforced-concrete building completed in 1986, so it would have been ugly running Cat5 cable across the ceiling of two interior hallways to connect the study with the bedroom (and I didn't want to go underneath floors instead).  The next two paragraphs will explain why those facts are relevant to your problem.

    The apartments in my building were built pre-wired with coax cable in every major room (along with four pairs of telephone wires).  Those wires were run under the floors and through walls, so starting in 1998 I disconnected the section of the coax cable running between the study and the bedroom from the Time Warner Cable TV feed and connected it to a pair of 10Base2 hubs.  In 2015 I upgraded these to MoCA adapters, but because of cost considerations these are MoCA 1.1 adapters with 175 Mbits/sec net throughput.  This means that part of my LAN involved in Retrospect backups is only capable of net speeds—1050MB/min allowing for 20% TCP/IP overhead—considerably less than the capabilities of the Cat5 cable in the rest of my LAN.

    However, because the limiting factor in Retrospect LAN backups is the speed of traversal of multiple files in the client computer's file system (see the second and last posts in that thread), I couldn't get a net speed (backup, not counting MD5 compare) of more than about 350MB/min in yesterday's Recycle backup of my new 2016 (purchased open-box) MacBook Pro—see the last two posts in that thread.  The point is that, if you have chosen to connect your client with your backup server using a dedicated Cat6 cable because of backup speed considerations, you shouldn't have bothered.  Two weeks ago yesterday, while I was doing a Recycle backup of my older slower 2011 MacBook Pro (it died the following Tuesday), my friend DovidBenAvraham was easily able to look at Wikipedia articles using Firefox from my Mac Pro while the Retrospect backup server was running over the same LAN. 

    If you have chosen to connect your client with your backup server using a dedicated Cat6 cable because of security considerations, then that's another matter that I can't help you with.  But otherwise my advice would be to ditch the dedicated Cat6 cable and port, the manual addresses, and the public key; just setup a LAN static IP address on the router for your client, and you'll be fine.

     


  14. Sorry, lwhitten, you haven't supplied enough information for anyone to help you.  First, it's not clear whether the bullet-pointed items represent one problem, or whether each one represents a separate problem.  IMHO you should rewrite your OP with a separate paragraph for each distinct problem, and stop using bullet points—you're not doing a PowerPoint/Keynote presentation here.

    Second, in your item "Installed new client on remote Mac (public key) ....", did you follow the procedures on pages 63-64, and 162-163 of the Retrospect Mac 14 User's Guide and set them to add clients automatically?  Since I have a lowly home installation of Retrospect, I've never had to use public key authentication.

    Third, your item "Dedicated connection between 2 Macs, with manual IP address set on each. ...." sounds as if it's a separate case from the preceding item.  It's not covered in the UG, but I learned 2.5 years ago that addresses of Macs (and I suspect other computers) don't stay the same if there's an Internet router assigning them via DHCP/PPPoE unless they are given static IPs.  Here's a post by me that describes how I did that for computers and printers on my LAN; you'll have to adapt that to your router.  The procedure should work for previously-identified computers that appear even intermittently on you LAN/WAN.

    Fourth, your item "If I force a regular (non-proactive) script to run ...." raises in my mind the question of whether you really need to use Proactive scripts.  For computers that intermittently appear on your LAN/WAN you do, but IMHO some administrators use Proactive scripts to back up permanently-connected computers in order avoid dealing with having to schedule regular Backup Scripts.  It may help to know that a Backup script will not run until the "backup server" computer is booted; that's why I have my own Backup scripts scheduled for 3 a.m. but don't normally run them until later in the day—simply booting the client machines before I boot the "backup server" machine.

    Fifth, if you're running a trial of the current version of Retrospect, you're entitled to 45 days of free telephone support—but only on weekdays during New-York-through-California normal working hours.


  15. On 12/15/2017 at 11:05 AM, JohnW said:

    I thought you posted an excellent question and I have been waiting for someone to chime in. I don't know what problems Retrospect is having that they cannot pay any attention to their forums, but it is bad business to ignore their user base. 

    Perhaps the reason nobody chimed in is that Ash7 never said what version of Retrospect he/she was using.  In fact AFAICT he/she has not said that in any of his/her 11 posts on these Forums.  That is especially relevant because of "Fixed 'Bad Backup Set Header' errors during certain restores and transfers (#5662)", which is in the Release Notes for Retrospect Windows 11.0.0.252—released 1 March 2016.  I've used the Search capability of these Forums to find posts mentioning that "bad backup set header found" error message, and there are no other such posts later than 2015.

    The likelihood that Ash7 was using an older version of Retrospect highlights a question: What is "their user base" that "it is bad business to ignore"?  The fact is that a lot of posters on these Forums are using an older version of Retrospect.  IMHO those posters are frequently either consultants or new administrators at their installations, and have been told "Get Retrospect working again to do ..., but don't ask us to spend the substantial amount of money a new version would cost."  It's a tribute to the old versions of Retrospect that they frequently still work well, but (to adapt an old Jewish joke) "Retrospect Inc. isn't in business for its health"—and users of old versions don't bring Retrospect Inc. any upgrade or ASM money.

    I will also take this opportunity to caution JohnW and others about making remarks about Retrospect Inc. business matters on these forums.  My experience over the last 1.5 years is that the head of Retrospect Tech Support regards such remarks as violating the purposes of the Forums, and has told me "Please try to keep your forum posts on topic to solving Retrospect issues for other users."  Also, if you read earlier posts in that thread, you will find that the HRTS takes umbrage at fairly mild satiric gibes.

    P.S.: To amplify the second paragraph in this post. when the HRTS did give advice in these Forums his post usually included a pitch for upgrading along with the advice.  I guess those pitches weren't proving too productive, but probably as important is that he doesn't have the time to post anymore.  The HRTS used to have an assistant named Alan who answered phone-call requests for assistance, but Alan is gone and there has been no replacement—so in my recent brief experience the HRTS answers the T.S. phones himself.  Given the third paragraph in this post, you'll have to figure out for yourselves why that is.


  16. On 12/14/2017 at 11:27 AM, JohnW said:

    So I have been told by you and another that I should post to TS to resolve my problem. I did that. I just wanted to know exactly what I asked.

    The answer seems to be that nobody who has ever posted to these Forums knows what the message means, apparently because nobody has ever seen it before.  IMHO that is because nobody has tried to do what you are trying to do, which is to expand the Use At Most space for an existing Member on a volume which also has Members of other Backup Sets.  Nobody has tried to do that because it is just as easy to add a new Member of a Backup Set on the same volume, assuming the space is available.  And the space has usually not been available on the same volume prior to recently, because there had not until recently been a rapid expansion in the size of a disk available at a particular price—what I have referred to in Scenario 1 in the fourth post in this thread as the Big New Disk.

    I just a few minutes ago thought of a third possible Scenario 2 explanation of why you are trying to expand the Use At Most space for an existing Member.  It is that you are the Retrospect consultant for an installation which doesn't have an on-site backup administrator capable of adding a new Member to an existing Backup Set, or which doesn't have such an administrator on-site when the installation's backup scripts—each using a different Backup Set—are run.  This would explain why you are so reluctant to explain what you are trying to do and why you are trying to do it. 

    My latest suggestion is that you combine my Scenario 2 solution in the fourth post in this thread, as I modified it in the P.S., with the Borrowed Big New Disk I suggested in my Scenario 1 solution.  You would follow a separate set of steps for each Backup Set: [1] Transfer Backup Set from old Backup Set to equivalent new Backup Set on Borrowed Big New Disk, [2] increase space for the only Member of equivalent new Backup Set, [3] delete the only Member of old Backup Set and add a new Member—with the same increased space—for the same old Backup Set on Big New Disk, [4] Transfer Backup Set from equivalent new Backup Set to old Backup Set—whose only Member would be on Big New Disk, [5] delete equivalent new Backup Set's only Member—which would be on Borrowed Big New Disk—and then delete equivalent new Backup Set itself.  With this set of steps there would be only one Backup Set at a time on Borrowed Big New Disk, so you wouldn't get the message when expanding the Member; also Borrowed Big New Disk would only have to be big enough for the largest expanded Member of any equivalent new Backup Set, so it would only have to be Borrowed Not-So-Big New Disk.  Actually you wouldn't even have to do any Member expansions on Borrowed Not-So-Big New Disk; you would just have to create the only Member of the equivalent new Backup Set with the size you had wanted to expand it to.

    And now for a moralistic message:  When you are describing a Retrospect problem on these Forums, don't hesitate to explain the real-world problem underlying it.  You can pick a "handle" that doesn't identify yourself if you are a consultant; you can even pick a "handle" that conceals the fact that you are a woman—which I suspect many of the posters on these Forums are.  If you describe your real-world problem sufficiently well, it's likely that someone on these Forums will be able to solve it by thinking of an approach that wouldn't occur to you—possibly based on a better knowledge of certain features of Retrospect.  Here's an example from about 6 months ago.


  17. So you're confirming that you've got Members from more than one Backup Set on that same disk, as I said in this post I had been assuming?  So why did you write, in your OP in the other thread, "Well it can't be from another set so that messages is just wrong. But what is actually wrong?"  If you've got Members from more than one Backup Set on that same disk, then the message means precisely what it says—and IMHO is offering to delete the Members belonging to the other Backup Sets on the same disk volume as the one you're trying to "update the space information" on in the Member Properties dialog.

    Your OP in the other thread certainly sounds as if you're complaining about not being able to do something you want to do.  Mayoff has certainly chided me on occasion for a post that in his opinion strayed too far from the problem-solving that in his opinion these Forums are for.  And in general I try to stay within those guidelines.

    I reiterate what I said in my first post in this thread, which is that you should totally rewrite your OP in this thread.  Describe precisely what's on your disk volume, and say precisely what you're trying to do.  Then we can say what the message means, and say whether or not it is a Retrospect bug.  Otherwise you're just wasting our time.


  18. My preceding two posts in this thread have been based on the assumption that JohnW actually has Members of multiple Backup Sets stored inside the "Retrospect" folder on his drive.  That is because, on the USB3 portable drives that I attach to my Mac Pro backup server, there is a folder inside the "Retrospect" folder for the single Media Set (Retrospect Mac term for Backup Set) whose Members I store on that drive.  That folder is named e.g. "Media Set White", and inside it is a file named "1-Media Set White" which is a Member.  I assumed that, in the "CS101" dialog window shown in the OP's screenshot that says "select the next disk member to recatalog", the items shown are other folders within the "Retrospect" folder, and that they therefore enclose folders for different Backup Sets.  That's why I couldn't understand JohnW's saying, in the OP for the other thread, "Well it can't be from another set so that messages is just wrong."

    Am I just making an unwarranted assumption that Members for Retrospect Windows are stored the same way they are in Retrospect Mac?  Or does JohnW have an extra level of folders on his disk that is confusing Retrospect Windows, making it think that Members for more than one Backup Set are stored on his disk—which would make the message correct from Retrospect Windows' point of view?  If the latter is correct, then JohnW could solve his problem merely by getting rid of the extra level of folders—which would enable Retrospect Windows to change the Use At Most property for an individual Member as he wants to do.


  19. Since the head of Retrospect Tech Support evidently deleted the post I made in this thread on why and how to submit a Support Case for a bug, JohnW should look at this post in a prior thread for the same information.  The worthy protector of the Forums has called that post "spam", but IMHO he really objects to the very relevant fifth paragraph for a reason you can all undoubtedly figure out for yourselves.

    I agree with Lennart_T that JohnW should open a Support Case, but IMHO it should be two Support Cases for the two separate bugs.  I have not posted about opening a Support Case in the other thread he opened, but have instead devoted that thread to proposing a couple of workarounds for the second bug.  IMHO the second bug is a manifestation of JohnW's trying to do something no Retrospect administrator has done before, because only the recent advent of Big New Disks has made it possible for administrators to copy old Members and try to expand their size.  Therefore he needs a workaround for the second bug, because he shouldn't expect a quick fix.

    As far as the crashing encountered in the first bug is concerned, it is worth considering Retrospect bug #6535—which the Release Notes say was fixed for Retrospect Windows 12.0.


  20. The key question is : Why is JohnW trying to trying to update the space information for each Member in a Backup Set?   I have thought of two scenarios, both of which assume that he has acquired a Big New Disk.

    Scenario 1:  JohnW is simply trying to accommodate his existing Backup Set on the Big New Disk, but is going about it with the wrong approach.   His approach is wrong because he is trying to preserve each existing Member.  He should instead create a new Backup Set on the Big New Disk, add what he considers to be the appropriate number of Members on it (per pages 404-406 of the Retrospect Window 12 User's Guide), and run a Transfer Backup Sets script (pages 214-219 in the UG) to copy all the backups from the existing Backup Set to the new Backup Set.  JohnW would then have to change all his scripts that refer to the old Backup Set to instead refer to the new Backup Set.  If this is too onerous, he could also temporarily obtain what I will refer to as the Borrowed Big New Disk.  He would then create the new Backup Set on the Borrowed Big New Disk instead of the Big New Disk, and—after running the Transfer Backup Sets script—delete the old Backup Set and recreate it with the same name and the newly-appropriate number of Members on the Big New Disk.  He would then run another Transfer Backup Sets script to copy all the backups from the new Backup Set back to the old Backup Set, but any Members of the old Backup Set would now reside on the Big New Disk.  JohnW would then delete the new Backup Set from the Borrowed Big New Disk, and return the Borrowed Big New Disk to its rightful owner.

    Scenario 2: JohnW is simply trying to accommodate his existing Backup Set on the Big New Disk, and is going about it with the right approach.   His approach is right because—for some reason involved with locating particular backups within Members (or—I had thought before experiments on 31 December proved it impossible—making each specific Member the only one in a separate Backup Set used for user-initiated backups and restores)—he must preserve each existing Member.  On the Big New Disk, he should first create a separate new Backup Set for each old Member, distinguishing them with names that correspond to the old Member Names.  He should then run a separate Transfer Backup Set script for each new Backup Set, with the old Backup Set as the Source and the particular new Backup Set as the Destination.  (If there were more than one member in each Backup Set, each one of these scripts would have to have its own set of Custom Selectors (pages 460-466 of the UG) that would effectively restrict the files copied to those contained in the desired Member of the old Backup; since there doesn't appear to be any Selector specifying Member name, IMHO JohnW's  best bet would be Selectors specifying some combination of date and client that reflect the contents of the old Member as appropriate.)  Once all these scripts have been run, he would create the desired comprehensive new Backup Set on the Big New Disk, and specify the Members of all the particular new Backup Sets as Members.  As you may imagine, it's much more fun for me to think up this approach than it would be for JohnW to execute it (insert appropriate smiley here)—but see the P.S. below for a way to simplify that.

    P.S.: Further thinking about "making each specific Member the only one in a separate Backup Set used for user-initiated backups and restores" has led me to an insight about making my Scenario 2 solution much easier.  It's based on the idea that the same Member can simultaneously belong to more than one Backup Set, an idea that had never occurred to me before—and which I'm not absolutely sure is valid.  It turns out because of experiments made on 31 December that it isn't valid.  Thus JohnW must already have a separate Backup Set for each old Member "owning" only that old Member.  He would then proceed with running the first round of multiple Transfer Backup Set scripts as described in the Scenario 2 paragraph above, but the Source for each script would be the Backup Set "owning" only one old Member and the Destination would be the Backup Set "owning" only the corresponding new Member.   Each of these Transfer Backup Set scripts would not have to have any Selectors, since the role of the Selectors would be accomplished by having the Source be the Backup Set "owning" only the Member to be copied.  JohnW would then proceed to run the second round of multiple Transfer Backup Set scripts as per the Scenario 2 paragraph above.  Could someone else please say whether the same Member can simultaneously belong to two different Backup Sets—even though  a Rebuild of a Catalog File rejects .RDBs whose creation date is before that of the Catalog File  ?


  21. On further reading in this forum, I see that JohnW has actually provided most of the missing information I complained about in my preceding post in this thread, but he has provided it in the OP in another thread.  In the editing bar at the top of a post, directly to the right of the first vertical divider, is an icon that looks like a link in a chain; if you let the mouse pointer hover over it, the word "Link" appears.  JohnW should have used that facility in his OP in this thread; if he had, I wouldn't have had to criticize it so severely.

    We see in the third paragraph of that other OP that JohnW is trying to "open the member properties and browse the disk to update the space information".  From the screen shot in the OP in this post, it looks as if he has folders for multiple Backup Sets ("CSI01", "CSI03-BU", etc.) inside the "Retrospect"  folder on the volume "Retrospect_Backup".  If that is correct, then the message is accurate in saying "another set". If there is in fact more space available on the volume, then the fact that the message can't be bypassed to expand the Use At Most space for the Member is a bug.

    I'll try to post back later on how to get around this presumed bug, but I suspect it will involve copying one member at a time to another volume, and expanding its size—and then Recataloging the Backup Set to use the copied Members.

    P.S.: mbennett has in the meantime replied in the other thread that JohnW should discuss his problems with Retrospect Tech Support.  I had posted instructions in that other thread on how to file a Support Case, but Mayoff has evidently deleted that generally-harmless boilerplate post because he considers it to be spam.  Discussion with T.S. may not be necessary—see the post two posts below this one.


  22. IMHO JohnW's post could serve as a textbook example of how not to write a request for assistance.  He doesn't tell us what operation he is trying to perform that leads him to be  "trying to save a Member's properties".  The windows in his screenshot are piled on top of one another, so we can't figure it out.  I'm a Mac administrator with no recent Windows experience, but surely it's possible to drag those windows that have blue title bars around by those bars to separate them.  It might even be possible to temporarily collapse some of those windows into the taskbar, and un-collapse them for a second screenshot.  JohnW also doesn't say what  version of Retrospect he is using, or what version of Windows.

    IMHO JohnW should totally rewrite his OP per the above paragraph.  I don't know about the rest of you, but I don't participate in the Forums to be a quiz show contestant :angry:.


  23. On 9 December I ran an unplanned test that verified my hypothesis in this post in the thread.

    On the night of 5 December my main computer, an Early 2011 15-inch MacBook Pro, wouldn't boot.   I brought it in the next day to Mike's Tech Shop; they said the logic board was dead, and that they couldn't replace it because that model was declared "obsolete" by Apple on 1 January.  I decided to buy a 2016 15-inch MacBook Pro as an "open box" special, doing so because I could take immediate delivery and because it came  with macOS 10.12.6  installed (my rule is never to install an Apple OS whose last digit is not .3 or greater, and macOS 10.13.2 has just been released).  The 4-core processors in the new machine are 2.7GHz vs. 2.0 in the old machine, and RAM on the new machine is 16GB vs. 8GB in the old machine.  Both the new and old machines have 500GB SSDs; the SSD in the old machine was installed in early May, so—within the limitations of the old machine's drive interface—its drive speed ought to be about the same.

    Before bringing the old machine in to Mike's I had run a Restore of the old machine's 5 December  Retrospect incremental backup onto a spare portable HDD.  Overnight starting 6 December I used Migration Assistant to copy the files from that HDD onto the new machine.  Despite a couple of missteps and an adapter problem (the Apple Thunderbolt-3-to-Thunderbolt-2 adapter Mike's sold me turns out not to work with DisplayPort monitors, meaning I can't connect the new machine to my 27-inch Apple LED Cinema Display until I receive a  StarTech adapter that will work from NewEgg), I had the new machine more or less operational with its built-in 15-inch monitor on 7 December.

    Every Saturday I run Recycle backups of all my 6 drives onto a portable 500GB USB HDD.  The run on 9 December did a LAN backup of my new MacBook Pro in 2.5 hours, vs. the 3.5 hours the backup of essentially the same files from my old MacBook Pro had taken on 2 December.  The MD5 validation of the backup of the new machine was also correspondingly shorter than that of the old machine.   IMHO that proves "the main factor limiting speed of [backups over] networks is the traversal of multiple files in the file system by the client computer."

     


  24. I think mdgarnett should do a Copy Media Set, with the destination Media Set a new one whose first Member is on the larger drive.  Instructions for doing this are on pages 137-139 of the Retrospect Mac 14 User's Guide.  Instructions for creating a new Media Set are on pages 87-90.  Obviously mdgarnett will have to change the Destination Media Set in scripts that reference the one on the smaller drive.

    • Like 1

  25. If redleader is getting -530 and -519 errors only on laptops logging on to the WiFi, but not on computers permanently cabled to the LAN, I suggest reading this post

    All of my client computers are connected to the LAN by Ethernet cable.  However 3 years ago, when I started using Retrospect again, I was getting errors—and I now believe they were -530 errors—until Alan of Retrospect Tech Support told me to give the clients static IP addresses.  The post linked to in the preceding paragraph tells how to do it for my particular router.  Since it is done by associating a particular LAN address with the computer's MAC address (which as you can read here has nothing to do with whether the computer is an Apple Macintosh as some people think) that should work for all redleader's computers—including those connected over WiFi because that connection must also be through the router.  He/she should talk to his ISP or router provider.

×