Jump to content

DavidHertzberg

Members
  • Content count

    1,059
  • Joined

  • Last visited

  • Days Won

    38

Posts posted by DavidHertzberg


  1. hgv, like many new posters to these forums, you may not be aware that there is a search facility for the forums.  If you look at the very top of the page, on the line where the Retrospect box logo and the "Retrospect" name appear on the left, there is a magnifying-glass icon on the right.  Immediately to the left of that magnifying-glass, there is a search box.  On some browsers that search box appears in a shade of black, so that it is tough to see.

     

    Anyway, if you type an error code such as "530" (no quotes) into the search box and then click the magnifying-glass icon, you will get a pop-up with a list of thread titles—or threads with an applicable post—where that error code appears.  Because the search facility has not been specially adapted for the Retrospect forums, if you type in the error code as "-530" (no quotes) you will not get any results.  To get results without removing the minus sign from the error code, you must type the error code as "-530" (with surrounding quotes).

     

    By default, that pop-up list is sorted in order of what the search facility considers to be relevance—which may not be what you consider to be relevance.  However the pop-up list has a drop-down, just to the left of the close-box 'X', that lets you change the order to most-recent-first date—which you are likely to find to be more useful.


  2. Oh boy, do I have clues!  First of all, do what it says in this post, which I made last August.  You can probably forget about the "port 497 suggestion" I mention there; that turns out to be unnecessary so long as you don't have any firewall within your LAN.

     

    That worked fine for about 6 months, when I started having -530 errors as described in this thread. If that happens to you look at the OP first, to see if you did every step in the workaround that A. recommended.  If that doesn't work, or stops working after a number of days (as it did for me),  scroll down to post #15 and look back at the posts I link to in the first sentence of that post.

     

    Good luck, and please post back to let us know how you made out.


  3. Just want to draw everyone's attention to rforgaard's thread on doing this with Amazon AWS S3.  That thread IMHO has been comparatively ignored because s/he posted it in Device and Hardware Compatibility-Windows.

     

    Also, for those users who don't have unlimited upload bandwidth or time or money, there is an extremely popular thread over in the Retrospect 9 or higher for Mac forum which boiled down to a discussion of how to groom a multi-year local backup down to a single year for duplication in the cloud.  Unfortunately it uses Retrospect Mac terminology, which for historical reasons going back to 2009 differs from Retrospect Windows terminology.


  4. Just FYI, page 42 of the latest Retrospect Mac User's Guide, in the "Fundamentals" chapter under the section "Media Sets" (what Retrospect Windows—for historical reasons—still refers to as Backup Sets) says "Disk Media Sets replace the less-flexible Removable Disk sets present in older versions of Retrospect."  

     

    There is no option to create a Removable Disk Media Set in the latest version of Retrospect Mac.  However some references to "removable disk" still remain in the Mac User's Guide.

     

    In general, it is my impression that Retrospect Windows has kept some facilities and terminology that were removed or changed in Retrospect Mac.  Some of that goes back to 2009.

     

    P.S.: (27 August 2016) As a result of a bit of research done this week for another thread, determined that all "super-floppy" devices—for which Removable Disk was created—had stopped being manufactured by 2009.  So if you're using a device other than RDX—which should be defined as Disk—that has been defined as Removable Disk to your Windows "backup server", be gentle with it—you may have difficulty finding replacement hardware of the same type.


  5. IMHO the results recounted in this post, this post, and this post indicate that in some cases a true "conceptual bug" lies behind -530 errors.  (In my terminology, you know you have a "conceptual bug" when you find yourself saying "Oh s**t, I had no idea I'd have to code for this situation."  OTOH, you know you have a "carelessness bug" when you find yourself saying "Oh s**t, I knew I'd have to code for this situation, but my hand/brain slipped.")  This "conceptual bug" is the conflict between "scheduled pull to server" backup and automated updating.

     

    In the first linked-to case, it was Microsoft Office 2004 that was doing—unsuccessfully—the automated updating.  In the second linked-to case, it was something related to Firefox—probably  Adblock Plus—that was doing the automated updating. In the third linked-to case, it was Adobe Flash Player that was doing the automated updating.  In all three cases the automated updating activity interfered with the Retrospect Client, producing -530 or -535 errors.  In all three linked-to cases, stopping the automated updating eliminated the -530 or -535 error.

     

    The very heart of Retrospect's "scheduled pull to server" backup is the "backup server's" telling a Retrospect Client on the LAN "You must start sending me the files to be backed up right now."  If the client's machine replies—because of automated updating going on—"I can't let you connect to the Retrospect Client" or the Retrospect Client—again because of automated updating going on—replies "I'm here, but I can't send you files because the LAN is unavailable", the result is a -530 or -535 error in backing up that client machine.

     

    This "conceptual bug" used not to be a problem because automated updating of application program files wasn't being done.  It is being done now, and solving the "conceptual bug" conflict will be a hard job for the Retrospect Inc. engineers.  In the mean time, it looks as if disabling automated updating for client machines being backed up by scheduled Retrospect scripts is the best approach to preventing -530 errors.


  6. Thanks, but I'm "just a guy at home" with my little home LAN.  My backup media is a 4 TB drive mounted internally on the system that runs Retrospect.  I change out that drive once a year.  If that drive starts to fill up, I will move some older months or quarters to a second 4 TB drive.  Hitachi 7200 rpm 4 TB drives are about $180, so that's my annual cost.

     

    For the rest of your post, it all seems very relevant, as does Mayoff's.  I have to print off this thread and study the posts in detail to see how I can implement one of these procedures.

     

    Thanks. :)

     

    I'm "just a guy at home", too, with 6 drives on 3 machines that need to be backed up.  I also have a special problem that I hope you don't have,  which is that for 29 years I have lived two floors down from a "junior-grade Master of the Universe" who has three times leaked water into my apartment—two times because of systematic negligence on his part.  In addition, for 20 years I was married to a multi-talented woman who both writes and paints, and who took to using a computer like a duck to water (not that kind of water ;) ) as soon as I gave her her first Mac.  

     

    Therefore,  starting at least as early as 1995, I adopted  a removable-media backup strategy based on my years as a mainframe applications programmer.  I have three Backup Sets (Media Sets in Retrospect Mac parlance) named "Red" and "White" and "Blue", of which I Recycle one each Saturday; I carry off-site the Backup Set containing Recycle and Normal backups from a particular Saturday through the following Friday ASAP after that Friday's Normal backup.  The Backup Sets are now on USB3 disks, although they used to be on DAT tapes until my old "backup server" machine died of old age in 2010.

     

    Years ago I decided that, if I (or she) deleted a file that I later needed back, I would know within three weeks while I would still be able to Restore it from an off-site Backup Set. Therefore my system, because it does not attempt to maintain Backup Sets extending back into the mists of time, does not require 4TB disks—only 500GB G-Tech G-Drive Slims.  My initial outlay, when I re-established my backup system a year ago after inheriting a Mac Pro to use as a new "backup server", was about $540—for the three G-Drive Slims and a USB3 adapter card and extra RAM for my Mac Pro as well as a new $119 copy of Retrospect Desktop Edition.  My annual cost, however, is essentially $0.

     

    P.S.: Upped initial outlay in last paragraph slightly from $515 to $540; I remembered wrong, but have now found the Ars Technica post.

    • Like 1

  7. This morning [saturday 18 June] I awakened my MacBook Pro and then booted my Mac Pro "backup server", expecting that the "Sat. Backup" script would start doing a Recycle Media Set backup of my MBP in spite of the fact that it was more than an hour past the script's 3 a.m. scheduled start time.  Instead "Sat. Backup" gave immediate -535 errors (backup client: network unavailable) for both the MBP and my Digital Audio G4—which I had not yet booted because it would not start being backed up until the 3-hour backup of the MBP was finished—and started scanning (unable to use Instant Scan) the first of the two local drives on my Mac Pro.  

     

    I tried to use the Console to do a Sources->Locate of the MBP, but it could not do so and gave a -505 error (backup client reserved) when I typed in the hard-coded DHCP address of the MBP.  I then ran Firefox on the Mac Pro to successfully connect to Ars Technica, which proved that a LAN path through my Verizon router—which is connected to the Internet in the room where the MBP and G4 are located—to the MBP should be clear.  Next I booted the G4 and rebooted the MBP, after which Sources->Locate worked for both the MBP and the G4 without typing in a hard-coded DHCP address.   Finally I killed the "Sat. Backup" script—which was still scanning the local drive—and restarted it, and it ran to successful completion on all machines.

     

    Meanwhile I remembered that when I had booted the Mac Pro I had gotten a message that Adobe Flash Player wanted to install an update, which I had postponed.   I had not gotten any such message for the MBP, which is why I had decided to reboot it.  Sure enough, it turned that the System Preferences->Flash Player had its "allow Adobe to install updates" radio button activated on the MBP (as opposed to its "notify me to install updates" radio button on the Mac Pro).  A post-mortem revealed that Adobe Flash Player Install Manager.app on the MBP had been updated an hour into the successful "Sat. Backup" run, which showed compare errors for nine Flash Player Install-related files on the MBP during that successful run.  

     

    My conclusion is that Adobe Flash Player had started to do a self-initiated install on the MBP after I originally awakened it, and that is what caused the -535 errors and later -505 error during the first—scheduled—run of "Sat. Backup".   Again Adobe Flash Player does not involve hardware, nor should it either take over the LAN or be part of Mac OS X—although it gives itself airs.  BTW, doing a Forums search, I noticed that I myself encountered -535 errors when testing out client Wake-on-LAN for scheduled scripts—as reported in this post.


  8. The results of the last week definitely call into question—in some cases—the Retrospect Inc. engineers' belief that the -530 error depends on some combination of hardware and LAN as well as OS software.  My experience over the last week is that -530 errors on an OS X 10.10 MacBook Pro can be caused—or cured—strictly by interactions—or inhibition of interactions—of application software with the Internet.  This post will deal only with my experiences from Sunday 12 June through Friday 17 June.  My experience today—Saturday 18 June, although it bears out the statement in the second sentence of this paragraph, is sufficiently complicated that it deserves its own post.

     

    Very early on the morning of Sunday 12 June, I received an invitation from Mozilla to update my copy of Firefox on the the MBP and improve my use of its features.  I did so, which gave me a copy of Firefox 47.0 to which I added back Adblock Plus.  Some time after I had done so, finishing shortly before 3 a.m., I quit all applications on the MBP and booted my Mac Pro "backup server" to run my daily "Sun.-Fri. Backup" No Media Action script.  Contrary to my experience over the previous 4 months, in spite of the fact that it started after the 3 a.m. scheduled time, "Sun.-Fri. Backup" backed up my MBP without a -530 error.

     

    This experience has repeated itself for every run of "Sun.-Fri. Backup" since then.  It doesn't matter how late after 3 a.m. I start the script, so long as I have awakened the MBP before booting the Mac Pro.  And, so long as I awaken the MBP at least 5 minutes before booting the Mac Pro, "Sun.-Fri. Backup" invokes Instant Scan.

     

    A folder named "Old Firefox Data" has appeared on my desktop, created Sunday 12 June at 2:52 a.m., and containing over 1600 items.  This is evidence that the "improvement" involved extensive changes.  It certainly looks as if the "improvement" cured whatever was causing my MBP to get -530 errors whenever "Sun.-Fri. Backup" was started after 3 a.m..  My guess is that what was "improved" had something to do with the way a Firefox add-on interacted with the Internet.  But Firefox involves neither hardware nor LAN, nor is it part of Mac OS X.

     

    P.S.: I'm running Firefox 47, not 42; so sure I didn't check; bad memory.


  9. It occurred to me on 18 May that I might be in possession of a Retrospect treasure: a MacBook Pro that fairly consistently gets -530 errors when backed up with Retrospect 12.5.  

     
    I have a portable 2.5-inch HDD that I don't use very much.  I thought I could give that drive a name such as "Macintosh HD 530Test", and use Retrospect to restore the contents of my MBP's "Macintosh HD" onto "Macintosh HD 530Test".   I could then delete a few sensitive documents from the restored contents , after which I would verify that I could boot my MBP from the restored drive and then try to run a "530 Test Backup" script from my Mac Pro "backup server".  If that script failed with a -530 error, I would ship the "Macintosh HD 530Test" HDD drive to Retrospect Inc. to be copied and returned.
     
    I posted that suggestion on my -530 thread on the "Retrospect bug reports" sub-forum of the "Retrospect 9 or higher for Macintosh" forum.  When I hadn't gotten a reply after two weeks—which is not totally surprising because the Retrospect Forums are user-to-user and not consistently watched by Retrospect Inc. personnel, I phoned the head of Retrospect Inc. Support this morning [01 June] to make the offer verbally.
     
    R. said he appreciated the offer, and would pass it along to the Retrospect Inc. engineers.  He said, however, that the problem with reproducing the -530 error is really that that it depends on some combination of hardware and LAN as well as OS software.  It is apparently timing-related, having to do with how long the Retrospect "backup server" must keep trying to recognize a particular "client".
     
    R. said the engineers are now trying to decide what changes to make to the Retrospect software to get around the problem.  A number of users are getting -530 errors, and some are getting other related errors.
     
    David H.
     
    P.S.: I originally made this post on my Retrospect thread on the Ars Technica Mac forum on 01 June.  I made it to let people on that forum know what was going on with the -530 error problem; the first two paragraphs and the first sentence of the third paragraph will not be news to anybody on this forum.  The person I refer to as R. in this post is, of course, Mayoff.  The reason I have now copied this post onto this forum is that results since 12 June—which I expect to be borne out by my weekly "Sat. Backup" script run tomorrow—indicate that what Mayoff said on 01 June about what the Retrospect Inc. engineers believe about the causes of -530 errors may not always reflect  a valid belief.  I expect that the results of my "Sat. Backup" run tomorrow morning, which I will post by tomorrow afternoon, will definitely call into question the validity—of the engineers' beliefs rather than what Mayoff said about their beliefs—of the second and third sentences in my fourth paragraph of this post.  Stay tuned!

  10. I conducted a couple of interesting experiments starting late this morning, as motivated by experiences I've had with Retrospect 12.5 over the last two weeks.  My conclusions are: (1) A -530 error can result from a client machine trying to do something on the Internet after it is booted while my Mac Pro "backup server" is accessing it.  (2) A -530 error can be avoided if the "backup server" does not run a script immediately after it is booted.

     

    My first experience was that, starting two Saturdays ago, my "Sat. Backup" all-machines Recycle Media Set script started getting a -530 error for my old Digital Audio G4—which had never happened before.  The G4 is—as always—running the Retrospect PPC Legacy Client under OS X 10.3.  However, while doing a major cleanup of my dining table three weeks ago in preparation for a party, I re-discovered my install CD for MS Office 2004.  I have never bought MS Office for my MacBook Pro running OS X 10.10—I use LibreOffice instead—so I decided it might be nice to have it available on my G4 secondary machine.  After I installed Word + Excel + PowerPoint, Microsoft AutoUpdate started giving me messages about needing to install an 11.6.6 updater—which it couldn't find because MS has reorganized its website.  I realized yesterday that the Saturday following the Office 2004 install is when the G4 starting getting a -530 error during "Sat. Backup".

     

    My second experience was that, twice during the last few nights, I have awakened well before the 3 a.m. scheduled time for my  "Sun.-Fri. Backup" No Media Action script.  On those nights I have  awakened my MacBook Pro and then booted my Mac Pro; "Sun.-Fri. Backup" has then run with Instant Scan for the MBP and without a -530 error.  This is not new behavior; see the P.S. in post #5 in this thread.

     

    So last night I trashed Microsoft AutoUpdate on my G4.  Then, late this morning, I scheduled my "Sat. Backup Incremental" all-machines No Media Action script for a one-time-only run  that was supposed to be 15 minutes in the future—preceding this by awakening my MBP and booting my G4 (and manually turning on the legacy Retrospect Client on that machine).  The scheduled  "Sat. Backup Incremental" run started immediately after I scheduled it on the already-started Console for some reason, but it ran without -530 errors for either client—although with no Instant Scan for the MBP.  I then scheduled "Sat. Backup Incremental" again for a one-time-only run 45 minutes in the future; that time it again ran without -530 errors for either client—and with Instant Scan for the MBP (there is never Instant Scan for the G4, because AFAIK the final version of the PPC Legacy Client was written before the Instant Scan feature was added to Retrospect).


  11. What you want to do, x509, would IMHO require two capabilities: (1) The capability of automatically creating new Backup Sets whose names follow a specific pattern.  (2) The capability of duplicating existing Scripts—or modifying them—to use the automatically-created Backup Sets.  In addition, as indicated in your thread title, you would almost-certainly need:  (3) The capability of automatically creating a new Windows volume to put the automatically-created Backup Sets on.

     

    Capabilities (1) and (2) would involve getting into the behind-the-scenes nitty-gritty of how Retrospect stores information on Backup Sets and Scripts.  I don't think you have a prayer of getting Retrospect Support to give you any help in doing this, and for reliability and security reasons I hope they won't give you any such help.  Capability (3) would involve  getting into the behind-the-scenes nitty-gritty of how Retrospect stores information on Volumes, but would also require getting into the behind-the-scenes nitty-gritty of how Windows itself stores information on Volumes.  I don't know anything about Windows internals, but that sounds like a quite an exercise to me.

     

    What I have suggested in my previous post in this thread is IMHO the least-effort method of manually doing what I think you really want to do.

     

    However, while I was writing this post Mayoff made a post that appears directly above this.  His suggestion would be applicable if you adopt the Staged Backup Strategy I suggested in my previous post.  In that case you would use New Backup Set as the Action in the backup set transfer script(s), so that (2) the secondary Backup Set names(s) would be changed each time those script(s) are run—say once a month.  You might not like (1) the Transfer Set Whatever [nnn] name that Retrospect would generate for such a Backup Set, but it would save you a bit of effort in manually creating new Backup Sets, and in changing the backup set name in the transfer script(s) to refer to them.  Either way, you would (3) have to mount a blank disk or tape each time a backup set transfer script(s) is run.


  12. It seems to me that what you really want, in Retrospect Windows terms, is known as a Scripted Backup Set Transfer.  This is described starting on page 221 of the Retrospect 11 Windows User's Guide.  The idea is that you keep recycling the same primary backup set(s) every month or quarter, after having previously transferred their cumulative contents to other secondary backup set(s).  In Retrospect terms this is known as a Staged Backup Strategy; the link is to the Windows tutorial that shows you how to automate a Staged Backup Strategy.  There is another Windows tutorial that goes into more detail on the backup set transfer step, but does not discuss automation; to do what you want you will need to choose the "Recycle source Backup Set after successful transfer" option—as briefly mentioned around 1:20 in the second tutorial and discussed on page 379 of the Windows User's Guide.

     

    Do not be put off by the fact that the first tutorial I have linked to above assumes that the secondary backup set(s) will be on tape; you can put it/them on disk if you want.  However, if you are going to create a new secondary backup set(s) as often as once a month, you may find that—with an LTO4 Ultrium tape drive costing $900 and tapes costing $30/800GB vs. a USB3 disk drive costing $80/500GB—the economics favor tape over disk if you are going to do this for as little as 2 years.  Also note that, per page 241 of the Retrospect 11 Windows User's Guide, it appears that you can schedule the backup transfer script(s) as infrequently as once a month—the first tutorial I have linked to is a bit out of date.  Whatever the frequency you will, however, have to change the secondary backup set name(s) on the  backup transfer script(s) manually; I do not see a method of automating that/those name change(s).

     

    I assume that you do not want to do Retrospect Archiving, which involves deleting files from your computer's disk(s) as you copy them onto a backup set.

     

    Note that I do not use a Staged Backup Strategy myself; I am satisfied with rotating via schedule weekly among 3 cumulative primary 500GB USB3 disk backup sets (or media sets in the more-modern Retrospect Mac terminology), which I store offsite, retrieve, and recycle every 3 weeks.  Also note that, for weird historical reasons (I link to this Macworld article by way of the Retrospect Knowledge Base reference so you can know the reasons are acceptable to Retrospect Inc.), the terminology for Retrospect Mac was modernized in 2008/9 but the terminology for Retrospect Windows was not.  Therefore please let any knowledgeable comments, e.g. by Lennart Thelander or Scillonian, take precedence over what I have written above.


  13. x509, it sounds as if you essentially did the same workaround that I linked to in my first post in this thread.  Presumably the uninstall tool you used accomplished the Windows equivalent of "Make sure the file 'root-drive-name/Library/Preferences/retroclient.state' (no single-quotes around file name, root-drive-name is usually 'Macintosh HD' with no quotes) is no longer there; if it is still there, delete it."

     

    However I probably should have made it clear in my previous post in this thread that the idea is to override the DHCP address that the Internet-connected router might assign to your client C.    Years ago this was not necessary, but now it is (don't shoot me, I'm only a messenger for A. of Retrospect Inc.).  What I am suggesting you do is described in the manual allocation paragraph of this Overview section of the Wikipedia article on DHCP.  In other words, establish "a preconfigured mapping to each client's MAC address."

     

    You need to obtain the client's MAC address.  Under Mac OS X's Apple menu, this can be done in either of two ways: (1) About This Mac -> System Report -> Hardware -> Ethernet Cards or (2) System Preferences -> Network -> Advanced (button) -> Hardware (tab).  In either case, what you are looking for is a string of 6 pairs of hexadecimal digits separated by colons.  It's been 12 years since I had a Windows 95 machine (loaned by my employer) at home, but I sure there are one or more Control Panels that will give you the MAC addresses for your Windows clients.

     

    As I said in my previous post, how you will then go about mapping a reserved fixed DHCP address to each client MAC address depends on what brand and model of Internet-connected router you have.  But the Wikipedia paragraph I linked to in the second paragraph of this post essentially says that you can do this mapping on any brand of Internet-connected router; you only have to figure out the terminology used and navigate to the place to do the mapping once you have connected to your router.

     

    I'd even be willing to bet that there is some way of determining the MAC address for a VMware virtual network adapter.  If so, it should be possible to map a fixed DHCP address to that MAC address, so that you can then enable that virtual network adapter's host connection.  I'll let the Windows/VMware experts figure out how to do that, but you might want to start with Chapter 16 of the Ver. 11 Retrospect Windows User's Guide—followed by searching the Knowledge Base to see if you can do it without paying for an add-on product.

     

    In response to your question "Is it even reasonable in an era when lots of office workers have laptops connected by DHCP-based WiFI to require fixed IP addresses?", the answer is that you must once obtain the MAC address of each laptop that will be used by an office worker and map a new reserved fixed DHCP address to that laptop's MAC address.  As soon as you have done that, you can—in the presence of the laptop user—wave a dead chicken over the laptop to signify its being approved for connection to the office LAN.  If an office worker tries to connect an unapproved laptop to the LAN, you can instead hit him/her with the dead chicken.


  14. I forgot one thing that I learned from A. last June, when I first started running Retrospect again after 5 years.  At that point the only show-stopper problem I had was in getting the Retrospect "engine" to "see" my two client machines consistently on startup (I could get it to do so by manually doing a Recognize from the Sources item on the "console" and then running my desired script). 

     

    You must give each of your clients a reserved fixed DHCP address that won't conflict with DHCP addresses that the Internet-connected router might assign.    Years ago this was not necessary, but now it is.  This is not documented anywhere in the User's Guide.  (A. also told me to open up port 497 on my Internet-connected router for both TCP and UDP—I don't run an internal firewall, but after fierce objections from other posters 7 months later on my Ars Technica Retrospect thread about my thus creating a supposed security hole I closed port 497 on my Internet-connected router—with no resultant problem.  This is documented properly in the User's Guide—as applicable to internal firewalls.)

     

    How you do this depends on what brand and model of Internet-connected router you have.  On my Verizon-provided Actiontec GT784WNV "router"—which also includes the functionality of what used to be called a "modem", I type 192.168.1.1 as a URL into my browser, then enter the name (defaults to "admin") and password (I changed it; if you haven't, see the ISP's documentation or phone their Tech Support).  I then click the Advanced Setup tab, and go to DHCP Reservation under IP Addressing on the sidebar.  There I manually enter the MAC address (has nothing to do with Macintoshes—look it up on Wikipedia) for each client machine—which must include embedded colons on the Actiontec.  For that client machine I then enter an associated IP address (I chose 192.168.1.202 and 192.168.1.203 for my clients; 192.168.1.200 is the reserved DHCP address for my printer), and then click the Apply button.


  15. It would probably be a good idea to start out by trying the workaround I reported in the OP of this thread in the "Retrospect 9 or higher for Macintosh" forum.  I enthusiastically reported that workaround, which came from A. of Retrospect Support, because it initially solved my -530 problems.  However, as you will see from my later posts in the same thread, the workaround stopped working for me after a week or so; the same thing happened other times I tried it later.

     

    My setup is somewhat similar to yours, except that—besides the fact that I am running Macintoshes instead of Windows machines—my "desktop" tower machine is only used for running a Retrospect "backup server" (and is shut down when it is not time to run the scheduled script of the day), and my main machine is a laptop that is one of my two clients.  It is the laptop that now almost always gets a -530 error when I back it up daily, while my other client—which is an old tower running a Retrospect legacy client—never gets an error when I back it up weekly as part of a Recycle Media Set backup of all my HDDs.

     

    I have been running Retrospect Mac 12.5 since last September (and Retrospect 12.0 since the July before that—I had previously been running Retrospect from at least 1995 to 2010), but I only started getting -530 errors in February.  I have not bothered to pay to upgrade to Retrospect Mac 13, the equivalent of Retrospect Windows 11, because my Internet upload speed is too slow for cloud backup and the other bug fixes were not compelling.  My laptop and my "backup server" machine have both been running Mac OS X 10.10.5 since last September; I have not updated them to OS X 10.11 because it is reported to have a number of new bugs.

     

    By all means "contact our technical support group at support@retrospect.com or online at http://www.retrospect.com/support" as Mayoff says—but you won't find any other contact at www.retrospect.com/support except a phone number (where A. will tell you the same workaround) and I think you already know everything in the Knowledge Base article that Lennart links to below.  I have created a three-post thread on the "Retrospect bug reports" sub-forum  of "Retrospect 9 or higher for Macintosh" forum, pointing to the thread I have linked to above.  There is no indication that Retrospect Inc. has looked at either of the threads.  However, based on what A. told me back in February, the Retrospect Inc. engineers are aware of the -530 problem but it appears that they are having trouble reproducing it.  In my last post in the three-post thread, I offered to try to give the engineers a portable HDD copy of my laptop client's HDD—since that machine gets -530 errors so reliably.  It's been several days since I made the offer, but I haven't heard back from Retrospect Inc..

     

    I hope the workaround works more permanently for you than it did for me.


  16. It occurred to me this morning [18 May] that I may be in possession of a Retrospect treasure: a MacBook Pro that fairly consistently gets -530 errors when backed up with Retrospect 12.5.  

     

    I have a portable 2.5-inch HDD that I don't use very much.  I could give that drive a name such as "Macintosh HD 530Test", and use Retrospect to restore the contents of David's MacBook Pro's "Macintosh HD" onto "Macintosh HD 530Test".   I could then delete a few sensitive documents from the restored contents , after which I would verify that I could boot my MBP from the restored drive and then try to run a "530 Test Backup" script from my Mac Pro "backup server".  If that script failed with a -530 error, I would ship the "Macintosh HD 530Test" HDD drive to Retrospect Inc. to be copied and returned.

     

    Mayoff, you have my e-mail address.  Let me know if this would help the Retrospect Inc. engineers investigating the -530 bug.  I could start working on it as soon as next week.


  17. Most days over the last two months I've been getting -530 errors on my scheduled script runs.  I've done A.'s workaround a couple of times, but it hasn't been effective for more than a day or two.  I've even reverted my MacBook Pro to the 12.0 Retrospect Client again, but that didn't help.

     

    On 14 May, with genuine anguish in my heart, I added a new post to my 4-months-long Retrospect thread on the Ars Technica Macintoshian Achaia forum. In it I recounted the series of -530 errors that I and other users have been getting, and that the Retrospect Inc. engineers have been unable to isolate and fix the problem.  In view of that, I recommended that anyone buying Retrospect take advantage of the 45-day free trial offer, and be prepared for Retrospect's stopping working for scheduled scripts even after that period.

     

    I also wrote in that post: "For me at least, the -530 error seems to have something to do with the RetrospectInstantScan root process running on the client machine; the successful manually-from-the-Console reruns do not invoke Instant Scan—and the legacy PPC client [which never gets -530 errors on 'Sat. Backup' unless I forget to switch on the Retrospect Client after booting my Digital Audio G4] has no Instant Scan capability. However disabling Instant Scan on my MBP's Retrospect Client does not stop the -530 problem."

     

    The next night I added a P.S. to that post: "Last night after editing this post, I left my MBP awake, booted my 'backup server' Mac Pro 45 minutes before the scheduled time for 'Sun.-Fri. Backup', and went to bed. When I awoke I found that 'Sun.-Fri. Backup' had run fine, including Instant Scan. I've tried the same approach other times, and gotten -530 errors. Do you see what I mean when I say 'they [Retrospect Inc. engineers] can't consistently reproduce the problem'?"

     

    Early this morning my "Sun.-Fri. Backup" script worked fine again—even though I un-slept the MBP and booted my Mac Pro "backup server" well after the script's 3 a.m. scheduled start time.  The only thing I'm doing differently for the last couple of days is to wait a number of minutes until the RetrospectInstantScan root process on the MBP has quiesced, as shown by the CPU tab on Activity Monitor, before I boot the Mac Pro.

     

    Come on, Retrospect Inc.!  I've been working hard on the Ars Technica Mac Ach forum for months to counteract the terrible reputation Retrospect has among posters there from years past—and now I'm faced with this!


  18. Most days over the last two months I've been getting -530 errors on my scheduled script runs.  I've done A.'s workaround a couple of times, but it hasn't been effective for more than a day or two.  I've even reverted my MacBook Pro to the 12.0 Retrospect Client again, but that didn't help.

     

    On 14 May, with genuine anguish in my heart, I added a new post to my 4-months-long Retrospect thread on the Ars Technica Macintoshian Achaia forum. In it I recounted the series of -530 errors that I and other users have been getting, and that the Retrospect Inc. engineers have been unable to isolate and fix the problem.  In view of that, I recommended that anyone buying Retrospect take advantage of the 45-day free trial offer, and be prepared for Retrospect's stopping working for scheduled scripts even after that period.

     

    I also wrote in that post: "For me at least, the -530 error seems to have something to do with the RetrospectInstantScan root process running on the client machine; the successful manually-from-the-Console reruns do not invoke Instant Scan—and the legacy PPC client [which never gets -530 errors on 'Sat. Backup' unless I forget to switch on the Retrospect Client after booting my Digital Audio G4] has no Instant Scan capability. However disabling Instant Scan on my MBP's Retrospect Client does not stop the -530 problem."

     

    The next night I added a P.S. to that post: "Last night after editing this post, I left my MBP awake, booted my 'backup server' Mac Pro 45 minutes before the scheduled time for 'Sun.-Fri. Backup', and went to bed. When I awoke I found that 'Sun.-Fri. Backup' had run fine, including Instant Scan. I've tried the same approach other times, and gotten -530 errors. Do you see what I mean when I say 'they [Retrospect Inc. engineers] can't consistently reproduce the problem'?"

     

    Early this morning my "Sun.-Fri. Backup" script worked fine again—even though I un-slept the MBP and booted my Mac Pro "backup server" well after the script's 3 a.m. scheduled start time.  The only thing I'm doing differently for the last couple of days is to wait a number of minutes until the RetrospectInstantScan root process on the MBP has quiesced, as shown by the CPU tab on Activity Monitor, before I boot the Mac Pro.

     

    Come on, Retrospect Inc.!  I've been working hard on the Ars Technica Mac Ach forum for months to counteract the terrible reputation Retrospect has among posters there from years past—and now I'm faced with this!


  19. ....

     

    Given the number of views of this very thread, I assume many people are interested in doing what jethro wants to do—seed a cut-down version of a local backup to cloud storage for rapid recovery if the local backup is destroyed. ....

     

    ....

     

    ....

     

    ....

    The other day I got curious as to why there is no equivalent of this thread over in the Windows Products-Retrospect section of the forums.  I found out there is one.  It currently consists of a single post by rforgaard, and it was started almost 3 weeks after jethro started this thread.  His/her post consists of "step-by-step instructions for using cloud storage for Retrospect Desktop v.11 for Windows using Amazon S3 services.  These instructions should be identical for other versions of Retrospect v.11 for Windows.  If you are running the Mac v.13 (or later) version of Retrospect, or if you are using a cloud storage provider that is not Amazon S3, some of the instructions below might still be useful to you."

     

    I must assume these instructions are correct, since I don't personally use Amazon S3 services—or other cloud storage provider's services—for Retrospect (I can't because of my limited Internet upload speed, as I have mentioned up-thread).  I would also need a translator such as Lennart Thelander—not from Swedish to English but from Retrospect for Windows to Retrospect for Mac (I would love to know the inside history of why Retrospect Inc. chose some years ago to modernize the terminology of Retrospect Mac but not Retrospect Windows).

     

    What particularly interests me is the section at the bottom of the post beginning "Create a transfer (incremental backup) script in Retrospect to copy your disk-based backup set to your cloud-based backup set (e.g., to your Amazon S3 account)".  That seems to be equivalent to what I wrote in step C6 of this post and in following posts, but I'm too lazy to compare Windows vs. Mac videos or User's Guides and translate the terminology in order to verify it.

     

    One question that occurs to me is why there have been so few views of that thread—and no further posts—compared to this one. Possibly it's because rforgaard, being a total newbie on these forums, put his/her thread in the Device and Hardware Compatibility-Windows forum instead of in the Professional forum.

     

    The other question that occurs to me is why that thread contains none of the discussion of grooming that has lately occupied much of this thread.  Is that because rforgaard seems not to be concerned with "seeding" a large existing local Retrospect backup to the cloud?  Or do all Retrospect Windows users work at installations where there is so much money available that they don't have to worry about grooming their cloud backups, or is that true only of rforgaard?


  20. I imagine all of you who are U.S. (Canadian?) Retrospect users received a personalized 21 April e-mail from Retrospect Inc. entitled "... a special offer on DreamHost Cloud Storage from Retrospect".  Unfortunately the list of Certified Cloud Storage Providers  still says of DreamHost "• Seeding and Large Scale Recovery – Not available."

     

    Given the number of views of this very thread, I assume many people are interested in doing what jethro wants to do—seed a cut-down version of a local backup to cloud storage for rapid recovery if the local backup is destroyed.  Why, then, is Retrospect Inc. touting a provider that does not provide these facilities?  DreamHost's motto should be "Cheaper because our service is untouched by human hands (including its own sales—try figuring out how to phone us)."

     

    IMHO Retrospect Inc., in the process of deciding whether to spend six months of engineering time developing a cloud backup facility, should have done a little Jobs-style marketing of its own.  That means going out and finding out what your customers want that you can uniquely provide, not just looking at what competitors are doing that may look like it's "eating your lunch".

     

    P.S.: This afternoon [25 April], around 1:30 p.m. PDT (DreamHost's time), I used DreamHost's website to ask their Sales Department whether they now offer "seeding" and/or "large scale recovery".  As of an hour after their 6 p.m. PDT closing time, I have not yet received an e-mail reply.  Over the weekend I also discovered, using a Google search that gave me a third-party website, that DreamHost has a phone number at (714) 706-4182.  I left a message shortly before 9 a.m. PDT today (their website says their messaging opens at 6 a.m. PDT) asking the same question; I have not yet received a call-back message. 

     

    P.P.S.: This evening [28 April] has been more than 3 working days since I asked DreamHost, both via their Sales Department website and via telephone to their secret number, whether they now offer "seeding" and/or "large scale recovery".  IMHO it's safe to assume that they still don't offer those optional services.   That is further reinforced by the lack of results from my 24 April e-mail to Mayoff, in response to his formulaic reply to my response to Retrospect Inc.'s 21 mass April e-mail, in which I suggested that he phone DreamHost to find out whether he should update its information in the list of Certified Cloud Storage Providers.  I think this whole episode is sad.


  21. I am not sure where or if suggestions are received but I have one that would be efficient for admins keeping the clients up to date.

     

    ....

    Paul

     

     

    A worthy suggestion, IMHO.

     

    Suggestions for Retrospect Mac are received in this forum.

     

    Whether they are ever acted upon, or whether that forum is just a distraction to keep the peasants happy,  is another question.  I think it would be worthwhile for encouraging current and future customers if the head of Retrospect Sales took an evening to reply to each of the "recent" threads in that forum, saying in one two sentences either "This good idea was implemented" or "This was judged to not be a good idea" or "This was judged to be a good idea, but too much work to be implemented".  And who better to advise the head of Retrospect Sales on what action was taken on these suggestions than "Retrospect Employee #63. Since 1994", namely Mayoff?

     

    If the head of Retrospect Sales doesn't do this within a reasonable time, maybe we should have an "Occupy Wall Street" phone-in.  Each Retrospect user who submitted a suggestion should phone Retrospect Support, at 925-476-1030 (Mon.-Fri. 9a.m-4:30p.m. EST) and ask "Was my suggestion implemented, and—if not—why?".

    • Like 1

  22. There is a new 13.0.1 update out today that fixes a grooming issue I've seen here.   Just FWIW.

     

    For those who want to look, the Release Notes are here.

     

    I suspect what Maser is referring to is this item: "Fixed crash when storage becomes full during backup and grooming starts (#6107)".  I wonder whether that has any relation to my prediction in the second paragraph of this post.  I notice that the 13.0.1 release note item uses the c**** word, which Mayoff objected—in the last paragraph of this post—to my using in my post linked-to in the preceding sentence.  :lol:

     

    Oh well, since Retrospect Inc. didn't take the bet I proposed in that post, I guess I'm not going to get a free update to Version 13.  However, if you want to do the honorable thing, Mayoff, you know my e-mail address.  ;)


  23. Hi David,

     

    Thank you for the thorough reply. I read jethro's thread and your replies there. The reason I posted here in the grooming thread was because I'm not worried about seeding. I know the initial upload may take some time. I'm more curious about how Retrospect grooms, trying to figure out what our storage buckets will end up like over time. Based on the attempts to be conservative with gets and puts, and the very very low cost associated with them, I'm not too worried about that either. I just want to have a better understanding of how the grooming works. Is it going to rewrite the rdb file with a smaller one, (one delete, one put as I see it), or just keep track of the groomed info locally until it can delete that rdb entirely?

     

    ....

     

     

    If you're not worried about seeding, then you must work in an establishment with very fast Internet connections.  Not all of us are so lucky, which is why jethro started his thread.

     

    I don't have any inside information about Retrospect grooming.  In fact, in my small home installation that Recycles one of its three daily-backup Media Sets each week, I don't use grooming at all.  However I assume that Retrospect Inc. engineers weren't permitted to expend effort implementing "performance-optimized grooming" in conjunction with Cloud Backup just because everybody thought it would be sexy.  For competitive reasons the engineers are not likely to tell us exactly why they implemented it.  However it's likely that they determined that gets and puts and deletes on a real Cloud member of a Cloud Media Set would cost processing time and—for any user not in a position to install Basho Riak S2 on his/her own server—money as well.  Therefore I think we'd better treat "this faster grooming mode only deletes whole RDB files instead of rewriting them" as meaning that it is not going to rewrite an .rdb file as a smaller one.

     

    ....

     

    II'm also trying to figure out if we can have a local copy of the data and keep it in sync with the cloud copy of data. I'm thinking that the backup strategy goes something like this.

    - Backup script A backs up clients to media set Local Disk A.

    - Transfer Script A transfers Local Disk A to cloud based media set 'Cloud B'.

         - Repeat several times.

    - Grooming script grooms Local Disk A and Cloud B.

    - Backup script A and Transfer Script A resume their normal operations and both media sets are the same size (assuming the same grooming parameters)?

    ....

     

    That's consistent with what I wrote in this step-by-step post in jethro's thread.

    ....

     

    I'm also trying to figure out a similar scenario but using slightly different parameters, where locally we have 6 months or 12 months grooming policy, but the cloud media has 'Groom to 3' or something like it. I think this is what you are describing earlier where you said ....

     

     

    Also, if you go to 'more reply options' which opens the full reply editor, there is a checkbox on the right for "enable emoticons". Uncheck that and  B) works normally! Being a tech forum, I think these should be turned off by default! Also there is no way to set your standard 'Post Options' defaults anywhere I can find in the user settings here.

     

     

    Yes, when I said "age subset of 'Groom to Retrospect defined policy' for action during the copying part of Copy Media Set to a Cloud Media Set", I was dealing with the situation that jethro's regular on-site Media Set has a no-grooming policy but he wants his Cloud Media Set copy to have a 12 months grooming policy.  My point was that, if he could institute the 12 months grooming policy without invoking copying-grooming cycles as part of his Copy Media Set to the initial local Member of his Cloud Media Set—rather than have to institute the policy by doing a separate Groom before "seeding"—he could both use a smaller disk for the local Member and save a lot of "mentally challenged" computer time.  The same would be true in spades for you, if you elect to do a Copy Media Set over the Internet straight to the true Cloud member of your Cloud Media Set.

     

    Being a tech forum dealing with backup, and especially with Retrospect, I think we need all the nuance we can get from emoticons.  For example, look at my first two paragraphs in this post.  Notice that the first sentence in my first paragraph, and the third sentence in my second paragraph, seem rather sarcastic.  Ordinarily I would have put "winkie" emoticons after them to show that I didn't really intend to be sarcastic.  However, to make a point with you, I left the emoticons out in this post.


  24. I've found Retrospect 13's local 'storage optimized' grooming process to be a massive improvement over 12.5. It's faster, and it works! So far I'm very pleased with the R13 upgrade.

     

    Question 1) I'm trying to figure out exactly how cloud based media gets groomed though - with Performance Optimized grooming, the description says it deletes whole RDB files. Does this mean -

     

    a) In order to reduce the size of the media set (bucket) during the groom, a new RDB file is uploaded containing all but the groomed information, then the old RDB file is deleted, resulting in a smaller bucket at the end, as opposed to local storage where the RDB file gets trimmed of the groomed data? Or -

     

    B) does an RDB file just sit there untouched as more and more internal pieces of it are marked as 'useless' until everything in the RDB file is useless and it gets deleted?

     

    Just trying to wrap my head around how much storage we will be using over time. Should it be the same as what's on our local drive?

     

    Question 2) I desire storing everything locally for fast large restores. If we use a D2D2C model with local backup first, then transfer to cloud backup later, do we need to groom both media sets separately, or will grooming the local set push that grooming reduction along to the cloud media set? Or should we maintain two separate backup scripts to backup locally and to the cloud set? How does this scenario work?

     

    Thanks,

    -Derek

     

    Hi, Derek; it's good to have the voice of your experience in this thread.  :)

     

    I think you should read the thread started by jethro, starting with a careful reading of the first long paragraph of this post—which is the result of my having figured out the inadequately-documented brilliant  :wub:  key concept in Retrospect 13's handling of both "seeding" and "restore to door" for Cloud Media Sets.  You should then skip down two posts to read my step-by-step procedure for doing "seeding", which I have continually revised in the light of new information from Mayoff and careful thought.

     

    What you should take away from those posts is that the local Member of a Cloud Media Set is just an intermediary for "seeding", which is created on a shippable hard drive purely for the purpose of being uploaded to a true cloud Member, and whose Retrospect catalog entry is AFAIK hijacked by that true cloud member as soon as its provider account parameters have been typed in.  When you get your "seeding" drive back from the cloud provider, Retrospect has AFAIK no knowledge of it unless you create another Disk Media Set whose Member is the contents of that drive—and I'm not sure why you would want to do that.

     

    It is clear to me, even from the inadequate description in "Chapter 1 • What's New" of the new User's Guide, that "performance optimized grooming" is designed  to minimize get/put operations on true Cloud members.  So the answer to your Question 1) is B] (which I must write that way because—thanks to a "peculiarity" in the Retrospect Forums software—if I write it as 'b' or 'B' followed by ')' it gets turned into this B) smiley—as happened in your post).  Furthermore I'm not sure that "more and more internal pieces of it are marked as 'useless'", unless that marking is done in the catalog for the Cloud member (which is still maintained on a local non-cloud drive), because marking part of an .rdb file as useless would involve expensive-and-slow gets and puts in the cloud.  My guess is that the only rewriting of an .rdb file in the cloud is done when "everything in the RDB file is useless and it gets deleted".  That IMHO is what "Chapter 1 • What's New" in the Retrospect 13 User's Guide means when it says "On a technical level, this faster grooming mode only deletes whole RDB files instead of rewriting them."  Which is why you have to do the kind of calculations jethro does further down the thread.

     

    The answer to your Question 2) is contained in my step-by-step procedure for doing "seeding" in jethro's thread.  It is, as I said two paragraphs above this, that the local Member of a Cloud Media Set is just an intermediary for "seeding"—which effectively disappears from Retrospect's knowledge after that "seeding" is done.  If you groom the local Member of a Cloud media set before "seeding" it—and BTW I'm not sure whether that can be "Storage-optimized grooming" or whether it can only be "Performance-optimized grooming", that grooming  is reflected in what is "seeded" to the true Cloud member.  Afterwards you must backup to and groom the true Cloud member separately, and any grooming you may do afterwards to your original Media Set that you copied into the local member of the Cloud Media set will have no effect on the true Cloud member. 

     

    P.S.: Expanded my answer to Question 1), added an answer to Question 2).  Sorry for the intervening break in time.

×