Jump to content

DavidHertzberg

Members
  • Content count

    1,416
  • Joined

  • Last visited

  • Days Won

    49

DavidHertzberg last won the day on March 25

DavidHertzberg had the most liked content!

Community Reputation

79 Excellent

About DavidHertzberg

  • Rank
    Occasional Forum Poster

Profile Information

  • Gender
    Male
  • Location
    New York, NY
  • Interests
    Retired applications programmer, with a few Macs at home.

Recent Profile Visitors

2,613 profile views
  1. DavidHertzberg

    Client Restore to New Hardware

    GTA_doum, First, you don't say what version of Retrospect Windows you are running. Given that this Wikipedia article says Windows Server 2016 has at least two successors, I suspect you aren't running the latest Retrospect Windows release. But that may not matter. Second, you don't say how much bigger your "bigger drive on a replacement computer" is. Does that "replacement computer" have a version of Windows Server already installed? If so, and you want to keep it, you'll want to restore only the non-OS portions of what you have got backed up—and the drive on the replacement computer must be big enough for those plus the OS that's already there. If not, then you'll want to wipe the drive on the replacement computer and— with enough space—follow the applicable "Disaster recovery" procedures on pages 316–328 of the Retrospect Windows 16 User's Guide. Finally, you don't say whether the "bug" that "is still present" gives you the same error message as in rfajman's OP in this thread. If so, I suggest you read the same 2014 Knowledge Base article I suggested he consult in February 2018. My suggestion evidently solved his problem; he was still posting here in 2020.
  2. twickland and Nigel Smith, Last night I repeated the tests reported in this up-thread post, because I was pretty sure I'd remembered the Options phrase incorrectly. After creating "StorageGroupTwickland" as password-protected, with a Catalog on "Macintosh HD SSD" and a large-enough Member on "Macintosh HD Sierra" (an extra partition on the HDD that I originally inherited with my 2010 Mac Pro), I first ran a No Media Action script to backup "Macintosh HD" and then reran the same Backup script adding "Macintosh HD New". At the end of the second run, the Summary Options for "StorageGroupTwickland" still included "Has password". I then did a Rebuild of "StorageGroupTwickland", and discovered that Rebuild elimination of "Has password" really results from kludgey Storage Group implementation. The Rebuild GUI asked me to Add a Member, and the only appropriate Member is "1-StorageGroupTwickland" in the Retrospect folder and "StorageGroupTwickland" sub-folder on "Macintosh HD Sierra". Note that "1-StorageGroupTwickland" is an empty folder; unlike the "1-Macintosh HD" and "1-Macintosh HD New" sub-sub-sub-folders contained within their respective sub-sub-folders in the "StorageGroupTwickland" sub-folder, it contains no .rdb files. Thus, despite what the head of Retrospect Support says in this up-thread post, the Catalog Rebuild process cannot read "the header of the .rdb file to identify if it is encrypted". Maybe Retrospect 18 attempted to fix this, with results per the OP. Are .rdb headers of password-protected Media Sets also so marked, or are they marked only in the .rbc Catalog? Was Rebuild of a password-protected Storage Group alpha-tested?
  3. You're correct about Restore of a client-volume pairing, Nigel Smith; I didn't look closely at the lower part of the Mac screenshot in this section of the KB document.🙁 But that section doesn't make it clear whether doing a Restore from such a pairing will give you the Restore Assistant options as described on page 106 of the Retrospect Mac 18 User's Guide. However I later tried clicking the Restore button, and it gave the options—though I didn't actually do a Restore. I don't have a Windows machine, but I was fairly sure you can't "easily search for every occurrence of 'Important.docx' across a Storage Group". IMHO you're over-estimating the current capabilities of the "meta catalog" for a Storage Group; I looked at one via TextEdit on my Mac "backup server", and it wasn't comprehensible but was quite small. However I later tried clicking the Restore button and using the option to do a search for filenames containing "Retrospect", and it found files in each of the component Media Sets—though I didn't actually do a Restore. The "backup server" source code was made common across the Windows and Mac variants in 2009. I'm pretty sure the only special Retrospect Windows provisions are its still-built-in GUI and its different terminology—which sometimes sneaks into Retrospect Mac messages as "backup set". I'd love "a preference so we can switch both Mac and Win consoles to our preferred method of display". But IMHO as an outsider that doesn't have any possibility of happening—given evident redirection since June 2019 by StorCentric, except as a feature of the projected new LAN Console connecting a Mac or Windows machine to a Drobo NAS variant of the "backup server" via a Web server. That new LAN Console isn't expected any earlier than Retrospect 19.
  4. I much prefer the Retrospect Windows approach, as shown in the "How to Use Storage Groups" KB article. That article shows that, in Retrospect Windows, you can restrict Restore and Transfer (Retrospect Windows term for non-Finder-level Copy) and Verify to a particular Backup Set (Retrospect Windows term for Media Set) without using a Rule (termed a Selector in Retrospect Windows). If that restriction were also extended to Rebuild—which I suspect would be easy as far as the "backup server" is concerned, the OP's original error messages in both this thread and the"Rebuilding only a portion of Storage Group Set?" thread you cite up-thread would have been easily remedied via Rebuilds of the component Media Sets. My guess—as an outsider—is that the "hide the existence of a Storage Group's component Media Sets" approach of the Retrospect Mac Console has as much to do with the relative lack of engineer competence in Console modifications as it does with a difference in philosophical approach. That's not casting an aspersion on any current engineer, only acknowledging the reported departure of the original Console designer some years ago.
  5. Sorry, Nigel Smith, but a Storage Group has one Catalog for itself plus one Catalog for each component Media Set. On my "backup server", within Macintosh HD SSD->Library->Application Support->Retrospect->Catalogs, there's a "StorageGroupTwickland" folder (my naming imagination is limited on Friday nights) with a StorageGroupTwickland.rbc Catalog File directly following it. Within the "StorageGroupTwickland" folder are Catalog Files "Macintosh HD.rbc" and "Macintosh HD New.rbc", created when I successively ran scripts backing up first one—then both—other local drives to StorageGroupTwickland. As a final proof, last night just for kicks I ran another Rebuild of StorageGroupTwickland; the Console Activities panel showed Rebuild activities simultaneously running (different Activity Threads) for StorageGroupTwickland.rbc and the two component Media Sets. As for "no usable purpose", if twickland had been running Retrospect Windows 18 he might have been able to individually Rebuild his component Backup Sets (Retrospect Windows term for Media Sets)—and thus recover his existing Storage Group backup. Of course he would then have had to individually Transfer Backup Sets (Retrospect Windows term for Copy Media Set) for those component Backup Sets to the corresponding component Backup Sets of a new Storage Group that still had the proper consistent password protection, but the Retrospect Windows UI would have enabled him to do that too. IMHO the inadequate explanation of underlying functionality—which I've had to supplement in this post as well as up-thread— in the "How to Use Storage Groups" Knowledge Base article, which has finally simply been copied into the Retrospect 18 User's Guides, is a sterling example of the erroneous policy—begun IIRC in 2016—of having the engineers explain new features in KB articles because it was too much trouble/expense to revise the User's Guides. I'm not casting aspersions on individual engineers—they're not trained as technical writers—but on Retrospect Inc. management as a whole. I'll see if I can test this over the next few days. As for the "nice work", it was mostly recognizing the unexpected when it appeared under my nose.😎
  6. (Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here. Any apparent aspersions I cast are meant to apply to the widest applicable group of Retrospect "Inc." employees, not to an individual employee.) Results of my testing (Retrospect Mac 16.6 under macOS 10.12 Sierra on "backup server"): Once you Rebuild a Storage Group that has been defined as password-protected, "Has password" disappears from Options in the Overview pane in the panel produced by selecting the Storage Group in the Console's Media Sets list and clicking the Summary tab. This is for a Storage Group for which a single local HDD had been the source in the first run of a Backup script (resulting in a single component Media Set), and then for which a second local HDD had been added as a source in the second run of the same Backup script (resulting in two component Media Sets). After the second script had been run—but before the Rebuild of the Storage Group, the Options had still shown "Password-protected" in front of "No automatic grooming". My new conclusion: At least as far back as Retrospect Mac 16.6, there is a bug—resulting in the removal of password protection from a Storage Group after a Rebuild—in what I said should happen in the first paragraph of this up-thread post. However Retrospect Mac 18.0 introduced a another bug—resulting in twickland's -2262 errors—whose uneven occurrence in Retrospect Mac 18.0 may be be causing the refusal to accept a password twickland also reported in his OP. You can't use password protection (or probably encryption) for Storage Groups; I'll add this to Support Case #80364. Interesting revelations of my testing: [1] When I created a "StorageGroupTwickland" as password-protected, Retrospect Mac 16 immediately created a "StorageGroupTwickland" folder within the "Retrospect" folder on the destination local volume—with an empty "1-StorageGroupTwickland" folder within it. When I then made the Backup script runs, Retrospect also created "Macintosh HD" and "Macintosh HD New" folders within the "Retrospect" folder on the destination local volume—with "1-..." and "2-..." folders within those folders. [2] Because I had mistakenly defined the mandated Member for "StorageGroupTwickland" as slightly too small, Retrospect asked for allocation of an additional Member when the first Backup exceeded the defined space for the Member "1-Macintosh HD". I defined it on the same destination volume, but there's no reason why I couldn't have defined that additional Member on another volume—permitting component Members on multiple volumes (which I previously thought couldn't be done for a Storage Group). Each defined Member size for a particular destination volume appears to define the size of an allocation for each component Media Set on that volume.
  7. xavierbt, This Knowledge Base article says you need to upgrade to Retrospect Mac 16.5—I've upgraded to 16.6 because of its bug fixes. This other KB article says what you need to do for "Full Disk Access" in Catalina; the URL—with the two extra 's's at the end—in your OP is the corresponding KB article for Mojave.
  8. (Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here. Any apparent aspersions I cast are meant to apply to the widest applicable group of Retrospect "Inc." employees, not to an individual employee.) IMHO your opinion, Nigel Smith, is wrong in this case—a very rare situation.😮 That's because a Storage Group is really a hack or kludge (latter term spelled as if derived from the Scottish word for toilet, although it probably actually refers to a U.S. company that invented an automatic feeder for printing presses) for grouping together multiple Media Sets so that they can be referred to as if they were one Media Set. As I explained most recently in the first paragraph of this up-thread post, each time you back up a machine-volume combination that hasn't already been backed up to a particular Storage Group you automatically create within it a new component Media Set. As the second paragraph of this later up-thread post says, redesigners of the Retrospect Windows GUI chose to show those components—redesigners of the Retrospect Mac GUI chose not to show them. I suspect that wasn't for "Mac consistency", but instead was caused by coding difficulty—traceable to the Retrospect Mac Console designer's having retired subsequent to 2008. The problem described by twickland in this thread evidently has to do with new Media Set components automatically added to a Storage Group that was originally defined as password-protected (although it would also be applicable to a Storage Group that was originally defined as encrypted). I originally hypothesized in the first paragraph of this up-thread post that the Retrospect "backup server" maintains a file at the Storage Group level containing the password/encryption status for all components, and that that file had become corrupted by the time twickland backed up a new machine-volume combination. However it later occurred to me that the engineers might have failed to code for the case of a Storage Group defined as password-protected/encrypted; if that "conceptual bug" occurred—meaning there is no such file at the Storage Group level, component Media Sets later automatically created for the Storage Group would not be defined as password-protected/encrypted. Rebuild for a Storage Group in either variant can only be done for the Storage Group as a whole, explaining why twickland reported "the storage group disk media set was failing only with new backups". I may know by tomorrow which version of my hypothesis is correct, per Support Case #80364 (the strangest I've ever filed; I refused to do any testing). Two other client-server backup applications have tried to parallelize (sorry, U.S. spelling) the single-destination-set use-case "the server processes data faster than a single client supplies it", but they can only do it for a tape destination. As you've said, Nigel Smith, Retrospect has simplified parallelization via multiple scripts by hiding scripts' multiple Media Set destinations—which must be on a single HDD or cloud "bucket"—within a single Storage Group. You're also correct; there's no way to back up different "clients" tagged "Remote Backup Clients" to different explicitly stand-alone Media Sets. As I urged Alanna to do in this 2020 post, I filed Support Case #73054 suggesting that "Remote Backup Clients" be treated as a prefix to a Tag for which a suffix would be allowed. The "Remote Backup Clients" prefix would still tell the "backup server" to not reach out for such "clients", but to wait until an individual "client" reached out to a running Proactive script using public/private key-pairs. However, in contrast to the present limitation, a running Proactive script wouldn't back up—using Storage Group parallelization—a "client" reaching out unless the full Tag—including the suffix—matched a script-defined Source.
  9. Why are you using Storage Groups in the first place, macpro? The justifications for doing so are summarized in the third paragraph of this 2019 post, supplemented by the first non-disclaimer paragraph in this 2020 post. If your use-case doesn't fit those justifications, IMHO you shouldn't be using Storage Groups.😎 But let's assume your use case does fit those justifications. I don't think you really understand what the Media Sets list in the Retrospect Mac Console shows when you use Storage Groups. Because of deficiencies (IMHO) in that GUI as opposed to the Retrospect Windows GUI, the Mac Console doesn't show the component Media Sets within a Storage Group. Those component Media Sets nevertheless exist as far as the "backup server" is concerned , though. You almost certainly have 149 Media Sets, including those components. The Mac Console GUI just shows a single line for each Storage Group, no matter how many component Media Sets it contains, which is why your Console shows only 35 "media set" lines. Look at the top screenshot on page 42 of the Retrospect Mac 18 User's Guide, and contrast that with the top screenshot on page 48 of the Retrospect Windows 18 User's Guide—where the more-complete GUI shows a line for each of the component Backup Sets (the Retrospect Windows term for Media Sets) within a Storage Group. 149 Media Sets includes one for each combination of "client" and drive—or Favorite Folder—you've ever backed up to your Storage Groups Having that many component Media Sets allows you to do a Proactive backup simultaneously of up to 14 (assuming your "backup server" machine has speedy hardware and at least 20MB RAM) combinations of "client" and drive. One use case for that would be your having many "client" machines that cannot be connected to the "backup server" at different times-of-day, such as a "virtual" office using a VPN or—using Remote Backup—doing Work From Home. BTW, you don't say what version of Retrospect Mac you are running, or what Edition. Retrospect 18 bans Storage Groups for Desktop/Solo Editions.
  10. xavierbt, When you last posted to this forum in 2018, you were using Retrospect Mac 10.5. Is that still true? If so, and you are now running it under macOS 10.14 Mojave—which is what the Knowledge Base article you reference is about, I think you'll have to upgrade to Retrospect Mac 18. Lennart_T gave sledder the same bad news about Retrospect Windows 10.5 (which came two major releases after Retrospect Mac 10.5) running under the latest version of Windows 10 in this post in another thread. The second table in this new Sales article—linked to from this new Knowledge Base article—will tell you which Edition you need and how much it will cost. BTW, notice those underlined phrases in the first paragraph of this post that cause the mouse pointer to change to a pointing hand when you pass it over them? If you click on any of them, your Web browser will be redirected to the post or article it points to. When posting on the Retrospect Forums, you can create one of these links by clicking the leftmost icon in the second-from-left section of the posting toolbar, and then pasting a URL such as https://www.retrospect.com/kb/macos_full_disk_access (note that I deleted the extra two 's'es that you inserted at the URL's end) into the topmost field in the dialog. You can then type whatever text you want to show for this "link" into the second field in the dialog, and click the "Insert into post" button at the bottom of the dialog. The leftmost icon in the second-from-left section of the posting toolbar shows "Link" when you pass the mouse pointer over it.
  11. DavidHertzberg

    Retrospect 10.5.0.110 Windows 10 20H2 64

    sledder, Am I understanding you correctly, that you're backing up one or more internal HDDs to another internal HDD on the same "backup server"? If so, you're a candidate for an upgrade to the Retrospect Windows 18 Solo Edition (top table, left-most Edition column), with a perpetual license price of US$49. The Solo Edition no longer backs up from a NAS source. I'm not sure whether your Retrospect Windows 10 Catalog file(s) are compatible with Retrospect Windows 18; if Sales and Tech Support say they're not, you'll have to Rebuild the Catalog file(s) from the destination Backup Set(s).🙁 However, I'm surprised you're seemingly worried only about the risk to your business of HDD failure. Many centuries ago people started using fire, and the danger of flooding has always been with us.😮 IMHO—and the opinion of every expert who writes about backing up— you should at least be periodically doing a Duplicate of your Backup Set(s) to an external HDD, and taking that external HDD off-site for use if the Backup Set(s) machine dies.
  12. You're welcome, twickland. Let me just note that the cumulative Release Notes show the original and later releases of Retrospect Mac 18.1 seem largely devoted to fixing errors and omissions in features that were "New" or "Improved" in 18.0. Given no knowledge whatsoever of the code, I'd bet an old programmer's nickel (US$0.05) on your problem being an error in "ProactiveAI: Fixed issue where ProactiveAI could not back up from cloud data sources (#9437)" in the original 18.1.0.113 release—even though your "clients" weren't cloud sources. If I were to utter anything about an appearance of testing having been rushed, the head of Retrospect Tech Support might accuse me of "posting derogatory information about any member of Retrospect/StorCentric", so I won't utter that. 🤐
  13. twickland, My aging brain has now come up with a new hypothesis, based on my outsider's understanding of the way Storage Groups work. If you create a Storage Group, Retrospect will have to create within it a new component Media Set each time you back up a machine-volume combination that hasn't already been backed up to that Storage Group—I've tested this. If the Storage Group was created as password-protected or encrypted (page 41 of the Retrospect Mac 18 User's Guide), then Retrospect will have to create the new component Media Set as appropriately password-protected or encrypted. This implies there should be a file at the Storage Group level that saves the password and level of encryption, so Retrospect can later apply those to a newly-created component Media Set. If the 2 "clients" that had the problem were the last ones added to a Backup or Proactive script that uses the Storage Group, it sounds to me as if the file (if any) at the Storage Group level became corrupted before the 2 clients were added to the script. If so, the component Media Sets for those 2 "client"'s drives would have been created with a different—or no—password versus the one originally specified for the Storage Group. I strongly recommend you create a Support Case, but also speak to Retrospect European Tech Support. If you upgraded to Retrospect 18 within the last 30 days, you're definitely entitled to personalized support for this issue; however—assuming my hypothesis is correct—you've exposed a vulnerability in Storage Group processing that should get the attention of Tech Support in any case. Tech Support may be able to tell you how to read the proper file at the Storage Group level, and then how to Finder-move or Copy-Media-Set-copy (using a Rule) the component Media Sets for those 2 "clients" to a new Storage Group created with the password and level of encryption the file at the Storage Group level now contains. Obviously—if you can do this—you'd then have to remove those 2 "clients" from their existing Backup or Proactive scripts, and add them to equivalent scripts specially created for them.
  14. twickland, You're in luck, because the Retrospect engineers appear to have fixed this bug—along with one other—in a more-recent Retrospect Mac 18.1.1.120 release on 24 June 2021. In the cumulative Release Notes, it's listed as "Fixed ProactiveAI: Fixed issue where failed activities would appear for disconnected data sources with -530 errors (#9486)". That doesn't say anything about -519 errors, but maybe the cause and the fix for those is the same as for the -530 errors.
×