Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. 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.
  3. Yesterday
  4. GTA_doum

    Client Restore to New Hardware

    And years later... This bug is still present! Unable to restore my Windows 2016 server to a bigger drive on a replacement computer... I will have to resort to another backup tool to be able to backup and restore, I already spent all my Saturday on this and do not see a solution for this issue with this software, and after seeing this post here, I'm even more convinced I will not find a solution before the end of the day, so time to try MacRium...
  5. 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?
  6. Last week
  7. 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.
  8. Agree about the Transfer and Verify (although Rules are hardly irksome), but I don't understand about Restore -- sessions are listed by Machine + Volume + Media Set, so it's trivial to do a point-in-time (or Browse and select particular files) for any client/volume pairing in any Storage Group. In Windows it's actually more clicking to get to previous snapshots/sessions. I've not tried it, but in Windows do you have to restore from a particular source? Can you easily search for every occurrence of "Important.docx" across a Storage Group, or would you have to search (and restore from) each "component set" individually? As you rightly say, it's potential in improving Rebuilds is massive, if it can be done. I'm not sure how similar Mac and Win RS actually are! There may be more to it than just how their respective consoles allow you to view what's under the hood. Creating Storage Groups by splitting a single over-arching catalog into a "meta catalog" plus a bunch of client/volume "component catalogs" was a very pragmatic solution to a pressing problem -- whether that could be done the same way on both platforms is something way outside my understanding. What we really need is a preference so we can switch both Mac and Win consoles to our preferred method of display 😉
  9. 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.
  10. I know what RS does at the filesystem level. But in the UI, which is where I suspect most of us interact with RS most of the time, it is presented as "just another media set" on the Mac and as something different in Windows. Again, I prefer the Mac software's consistent approach -- you obviously don't. And I can't disagree with your preference since Storage Groups aren't "just another media set" (eg lacking cross-client dedup within the set). I'd prefer it even more if there was a consistent approach, one way or the other, across platforms -- but that's probably asking too much. It may have changed in v18, but in v17 you had to rebuild the entire Storage Group on both platforms, even if only a single "component catalog" was damaged. A pain, but at least the rebuild is also parallelised across multiple threads. See this old post for my workarounds, either of which could possibly be adapted to twickland's particular problem.
  11. 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.😎
  12. Trust me, it isn't! Agreed. But whether Mac or PC handling of them is correct (c'mon -- Mac wins every time!) is a matter of perspective. Looking top-down, a media set only has one catalog. A Storage Group only has one catalog. It looks like any other media set in the RS UI, and the manual even states it should be treated the same as any other media set. So it *shouldn't* show the component directories, since no other media sets do. When it comes to UX and abstraction, consistency trumps absolute accuracy every time. And why display something that shows no usable purpose? I don't know, and I don't really care, why Mac and Win do this differently. I know which I prefer, so do you, but those are only opinions and neither of us is "right". While I would hope that you are right about this, I'd recommend that anyone who wants to use this in production thoroughly tests it first. There are limits on destination volume size -- my "use as much space as you want" Disk Media set splits every 8TB, for example -- and I'd want to be sure that the above allowed you to separate across "proper" logical/physical volumes rather create more RS "media set" volumes in the same place. Nice work on the password protection checking!
  13. Earlier
  14. (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.
  15. 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.
  16. Hi David, I 'm running retrospect mac 16.1.2 It's supposed to support up to macos Catalina 10.15.
  17. (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.
  18. Which just goes to show how tricky UI design can be because, IMHO, a Storage Group should be treated like any other media set -- those don't show internal client/volume pairs, so why should a Storage Group? Mac consistency, FTW! I think the generic use-case for parallelising backup clients is that "the server processes data faster than a single client supplies it". You can parallelise with multiple scripts, each with its own destination set, or with one or more scripts writing to one (or, less often, more) Storage Groups. My personal experience suggests that for "local" clients (those your RS Server can direct-IP or multi/subnet broadcast to wherever they are in the world), multiple scripts/sets is best. The benefits to me are organisational, de-dup within sets, faster catalog rebuilds when things go wrong (because you only have a subset of clients per media set), etc. But if you have "remote" or hybrid-working clients then Storage Groups are the way to go, mainly because (as at my last set of tests, anyway) there is no way to back up different remote clients to different media sets -- it's "one big bucket", hence the slower catalog rebuilds, although there's no de-dup (even across volumes of the same client). The only way to parallelise write operations to a single set is by using a Storage Group. And having multiple remote clients, which often have restricted upload speeds, are when parallelising on the server can really help you get all your backups done. As always, YMMV.
  19. 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.
  20. The main reason for me to stop using Storage Groups is that it takes too long to start the Retrospect console. When syncing with the server, it counts up to 149 media sets and when it's done, it actually shows 35 media sets. That's probably because Storage Groups contain "sub media sets".
  21. 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.
  22. local/Users/.../Library/Containers/com.apple.mail/Data/ I have performed all steps explained in this url, https://www.retrospect.com/kb/macos_full_disk_accessss but Retospect can't acces to this directory in users mail data. Any clue?
  23. 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.
  24. I'm updating this guide for RS 18. See any errors/glitches? Please tell me and I'll fix the document. THANKS!
  25. Lennart_T

    Retrospect 10.5.0.110 Windows 10 20H2 64

    Well, Retrospect 10.5 very old and is not supported on such new version of Windows 10. So, most likely will your problem go away by upgrading.
  26. Backing up data only to internal HD, speed is amazing 4gb/minute. Problem after rebooting computer drive is 90% busy, until I run dism.exe /online /cleanup-image /Restorehealth Each time it fixes corrupt files, and the computer runs very fast, until next backup. Does any experience this problem? Will a updated version of Retrospect solve the problem? I've used Retrospect in business since version 1. All comments are appreciated. Henry Christle.
  27. 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. 🤐
  28. Thanks, David, for the heads-up. The update release seems to have fixed the problem. After updating, there was one last gasp from the client with the -530 error, and since then, it's been back to normal; no further -519 or -530 errors for proactive backups.
  1. Load more activity
×