Jump to content

DavidHertzberg

Members
  • Content count

    1,281
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by DavidHertzberg

  1. Thank you for the compliment, Nigel Smith; I did a number of revisions to my preceding post to make it clear without being too lengthy. I just submitted a Support Case (note to self: #73687), covering both the relevant User's Guide deficiencies—both Mac and Windows variants—and the apparent Cumulative Release Notes error I spotted per this up-thread post. As far as the Mac User's Guide deficiency is concerned, it may help to be aware that according to DovidBenAvraham Retrospect Mac 8—including a totally new GUI and terminology changes as well as the enhancements of Retrospect Windows 7.5—was hurriedly released in 2009 after EMC first end-of-lifed Retrospect Mac and then allowed the re-hiring of some of the employees who had worked on it. According to the head of North America Sales, an old-timer with whom I had a longer-than-expected phone conversation the other day, one of those employees was both brilliant and rigid—and he was the one who rewrote the Mac UG. Then he moved to VMWare, so he wasn't around to deal with Retrospect Mac terminology and documentation problems. One of those problems is that the Mac UG "now uses the term backup to include both session and Snapshot data". Of course the Retrospect Mac Engine, which since late 2009 has been common code with the non-GUI part of the Retrospect Windows Engine (not the Windows-only GUI ), still uses Snapshots in the Retrospect sense; you can see that merely by watching the Console text summary of a running Backup script. And of course the session data isn't stored in the Catalog for an active backup; it's only the Snapshot. So I said in the Support Case that, besides copying "Eppinizer"'s explanation of "active backup" onto page 120, they're going to have to enhance it to include an explanation of "Snapshot" referring to the Glossary definition on pages 264-265. P.S. (because I needed some sleep): As I interpret Joriz's posts on the first page of this thread, he has three interlocking problems in his campaign to have a disaster-recovery backup—preferably off-site—that is up-to-date: (1) His boss won't pay for more than the 3 x 2 = 6 LTO-7 tapes (costing US$65 apiece, according to my Googling) currently owned by the company. (2) Any disk-to-tape script he runs on weekdays must fit into the portion of 24 hours that remains after his server-disk-to-backup-disk incremental Backup scripts have run. (3) Veeam is churning bigger Retrospect incremental server disk backups than it ought to, because Retrospect is seeing VMWare files Veeam already backed up as having been changed in some way. To cope with these problems, I have made the following two suggestions: (a) Run a disk-to-tape script nightly, but make it as short as possible by having it add to tape only what the Snapshot of the latest disk-to-disk Backup shows has just been backed up. (b) Do something to prevent Veeam seemingly re-making backups of files it has already backed up. Suggestion (a) can be implemented by either using Copy Backup scripts whose source is disk Media Sets with grooming retention of only the latest backup—with a Groom script run only once a week, or by using Copy Media Set scripts that rely on the “Don’t add duplicates to the Media Set” option to screen out everything except what has been just backed up. The first alternative would IMHO run at least a little faster, but would require a US$69 update to Retrospect Mac 17; the second alternative would allow more frequent grooming of the disk Media Sets, which might be desirable if Joriz is running out of space on them. Suggestion (b) can be implemented either by finding out how to prevent VMWare-Veeam from churning, or by switching from Veeam to R. V. (and it's only my guess, which I'll check with Sales, that R. V. would churn less)—which would undoubtedly be very scary to both Joriz and his boss. P.P.S: I added to my Support Case a suggestion that the Retrospect term "Snapshot" be changed to "Manifest". It's the same number of characters, and younger administrators are probably more familiar with a cargo or customs manifest than they are with a Kodak snapshot. The point is that the term "manifest" hasn't been co-opted by the Computer Science community to mean something else What do you think?
  2. Nigel Smith, I finally figured out the explanation for the confusing Copy Backup popup option explanation in the Retrospect Mac 17 User's Guide (you're citing that version, though Joriz runs 16.6) page 121. We must detour to page 177 of the Retrospect Windows 17 UG, where it is written of Transfer Snapshot—the equivalent operation with the same options described in a slightly-different sequence: So why did they butcher this explanation for Retrospect Mac 8 and thereafter? The reason is that the term "snapshot" was abolished in the Retrospect Mac GUI because by 2008 the term had acquired a standard CS meaning, eventually even at Apple. Starting in 1990 the Mac UG (p. 264) had defined it: The term "active Snapshot" is not defined even in the Windows UG; it means a Snapshot that the "backup server" has given the status "active" by keeping it in a source Media Set's Catalog. As we see from Eppinizer's first paragraph quoted here up-thread, it is the single latest Snapshot if the source Media Set has grooming disabled—but is the "Groom to keep this number of backups" number of latest-going-backward-chronologically Snapshots otherwise. So that's why the choices in the Copy Backup popup have the word "backups" as plural. I'll create a documentation Support Case asking that the august Documentation Committee put Eppinizer's definition of "active" backups/Snapshots into the UGs. But "a backup that is kept in the Catalog" sounds silly.
  3. In regard to the churn rate of disk-to-disk backup of your Veeam backup files, Joriz: First, make sure you have left un-checked "Match only file in same location/path" in the Options->Backup->Matching tab of Scripts for your Backup script. Per pages 98-99 of the Retrospect Mac 16 User's Guide, this will make sure that any separate copy of an incremental backup file will not be backed up again. Second, I suggest you consult the Veeam Backup and Replication forum of the Veeam Community Forums. Here, for instance, is a 2016 thread in which the OP asks "Till now Retrospect is managing the tape library but we need a possibility for outsourcing out of date Veeam backups we don't need anymore but we don't want to delete finally. Is it possible to create a job in Retrospect which writes the related backup files from Veeam onto, with the possibility to restore them again to it's original destination if needed?" There is a Tape sub-forum there, but the OP in the thread I linked to in the second sentence of this paragraph posted down-thread (spelling mistakes are his, not mine) about what is probably also your single-tape-drive situation: Third, I have to ask whether you have considered using the Retrospect Virtual application instead of Veeam. I don't know anything about R.V., and have been forbidden to discuss it on these Forums. However I'm pretty sure it's cheaper than Veeam, even though your boss —and apparently you—is used to Veeam. R.V. only runs on a Windows machine, but you must have one of those to run Veeam. R. V. doesn't seem to have a tape backup capability of its own, but—considering it is marketed by Retrospect "Inc."—it probably has destination disks that can be backed up onto tape by Retrospect non-V. Mac.
  4. Nigel Smith and everybody else, They aren't supposed to be "the same thing with expanded options." Page 120 of the Retrospect Mac 17 User's Guide says (as does page 137 of the Mac 16 UG) : To answer the questions "What is an 'active backup'?" and "why does Copy Backup offer 'Copy all backups' as a choice in the drop-down?", here's a 2016 post by "Eppinizer"—IRL Jeff of Retrospect Tech Support—answering those questions in two separate paragraphs: I just looked at my test runs in Activities; my early test runs were of a Copy Backup script. The second of those runs copied all backups of "David's MacBook Pro" from Media Set Red, not merely the latest No Media Action incremental Backup. So I think that the Release Note I quoted in this up-thread post is wrong, and I've left voicemail messages for both the head of Tech Support and the head of North America Sales asking them to re-check it. In the meantime I now think that Joriz should either run a test himself, or use Copy Media Set for his incremental disk-to-tape backups and rely on the “Don’t add duplicates to the Media Set” option to restrict the copying to the most recent backup whose Destination was the Media set he is using as the Source.
  5. Joriz and Nigel Smith, While searching the Retrospect Mac Cumulative Release Notes for a possible answer to another administrator's problem, I just noticed this for 17.0.0: (Transfer Backup Set is the old name for Copy Media Set; it is still used in Retrospect Windows, which is why the common-code Engine uses the term.) In my early tests mentioned directly above, I was seeing the same problem using Retrospect Mac 16.6. Because the problem went away when I changed the disk drive location of 1-CopyTestDestination, I thought it resulted from my original test setup. Instead it evidently resulted from an intermittent bug, . Joriz: If you can't get your penny-pinching boss to shell out the equivalent of US$69 for an upgrade to the Retrospect Mac 17 version of Desktop Edition—which is the Edition I assume you are using, you'll have to use a Copy Backup script with schedules specifying No Media Action for your daily tape incremental backups. Leave the “Match Source Media Set to destination Media Set” and “Don’t add duplicates to the Media Set” options check-marked. I think you'll want to pick the "Copy most recent backups for each source" option from the popup, but see the next paragraph. Nigel Smith: Maybe this bug was why you wrote "I don't know what the practical difference is." Though it's probably not useful for Joriz, the popup options for Copy Backup—when it's working as designed—include "Copy most recent backups for each selected [my emphasis] source". Apparently that lets you specify which backup onto a selected source Media Set should be copied, using the Browse button on the selection dialog shown for that option. P.S.: Corrected the Joriz paragraph, which I had messed up.
  6. j.a.duke, (1) Are you using a Storage Group as the destination for your Proactive script? I'm not recommending it; the reason I ask is that the Retrospect Mac 16.6 GUI for Storage Groups is really half-baked, and there's no indication that the GUI has been improved even in Retrospect Mac 17.0.1—which was released on 1 May. (2) Otherwise your OP sounds as if you've got a problem with the hierarchical structure of your destination disk drive. The the hierarchy you list has two "FT_TD" folders at different levels of the hierarchy, one above the "Retrospect" folder and one inside it. Maybe that's getting the Console confused. My practice is to let Retrospect create a "Retrospect" folder at the top level on the destination disk, and let it create folders for the individual Media Sets underneath that. But then I've got a simpleminded home installation. Do you have more than one "Retrospect" folder on your destination disk drive?
  7. Joriz and Nigel Smith, In my first job as a programmer in the mid-1960s, I worked as a consultant with one U.S. Air Force-written project cost and schedule control application that ran for hours on a "big iron" IBM 7090 or 7094—using multiple half-inch tapes for I/O because those machines generally didn't have then-incredibly-expensive disk drives. I was paid—indirectly by the U.S. Navy—to personally supervise those runs, which were made at one of the computer service bureau offices belonging to my employer. Thus I became quite familiar with factors affecting tape life. The IBM 729s and 2400s we used then and the LTO-7 drive Joriz is using have one thing in common; they make read and write scans linearly up and down the tape. The tape is moved by rollers that touch the tape and it passes over a read-write head (a second read head for LTO does read-after-write verification) that even for LTO also touches the tape. It's the repetition of high-speed linear scans that wears out tapes. (As I write this I am using Retrospect Mac 6.1 to back up my ex-wife's old Digital Audio G4 onto a DAT drive—which uses helical scanning with a rotating head instead of linear scanning, but DAT-based Digital Data Storage was abandoned because it couldn't keep up with LTO's capacity increases.) AFAIK LTO tape wear doesn't depend on whether the read-write head is writing when the drive does those linear scans, but at least the read-write head has to be reading at least a servo track—except for rewinds—because that's the only way the read-write head can position itself for non-direct-access as a result of those scans. I just spent the best part of 24 hours doing comprehensive tests of both the Copy Media Set and Copy Backup features of Retrospect Mac 16.6. At first I didn't think they worked, but that was because I had placed the Media Set member 1-CopyTestDestination in the spare space on my portable USB3 HDD—which wasn't large enough to hold a complete copy of 1-Media Set Red that occupied the rest of that HDD. After I did a Rebuild of CopyTestDestination to place 1-CopyTestDestination on the larger spare space of my "backup server"'s SSD boot drive, both Copy Media Set and Copy Backup functioned as pages 116-122 of the Retrospect Mac 16 User's Guide say they should—but see my post directly below. (Switching my destination from USB to boot drive halved the speed of the script runs—even though it straightened out the function testing, so you'll have to do speed testing with your tape drive , Joriz.) The "Copy most recent backups for each selected source" option on the popup menu of the Sources tab for a Copy Backup script functions exactly as it states, Nigel Smith. I tested by first running a Copy Media Set script after running a Recycle Backup of three source drives and a Favorite Folder onto Media Set Red, and then interspersing No Media Action Backups of one source drive with No Media Action Copy Backup script runs using the "Copy most recent backups for each selected source" option. However I also tried a No Media Action Copy Media Set run after a No Media Action Backup run; the “Match Source Media Set to destination Media Set” and “Don’t add duplicates to the Media Set” options caused that Copy Media Set run to copy only the latest backup of that source to Media Set Red, exactly as did the Copy Backup run with the "Copy most recent backups for each selected source" option. Thus Joriz can use either Copy Backup with the "Copy most recent backups for each selected source" option or Copy Media Set for daily tape backups.
  8. DavidHertzberg

    client not being recognized

    denno, Does the MBP which you can't Add have multiple network interfaces? This sounds to me, whose LAN is much less complicated, like that situation. First read this "Client Security" section in the Retrospect Mac 17 User's Guide. Make sure you have done what it says for the MBP you can't Add. Next, open the Advanced tab of System Preferences -> Retrospect Client for both the MBP your iMac Pro "backup server" can see and the one it can't see. Look at the Public Backup Server field on the tab for both those MBPs. Are they the same? If they're not, Click The Lock to Make Changes, and then click the Edit button and set the Public Backup Server field on the MBP that can't be seen to the same address as the one that can be seen by the "backup server". However the P.P.S. of this post in that same thread says that field was introduced in Retrospect Mac 15 for Remote Backup—which I gather you aren't using, so it may not be applicable in your situation unless it's been expanded for use in ordinary public/private keypair security. But read the preceding portions of that post. If that hasn't solved your problem, read the rest of that thread—concentrating on the posts by Nigel Smith. BTW you should probably upgrade your "backup server" to Retrospect Mac 17.0.1, which has a lot of bug fixes even if none related to this. P.S.: In regard to your post directly below, Retrospect.app is the Console—not the Engine which is installed in a "seekrit location".
  9. amkassir and Nigel Smith, Reading this article and this article reinforced my understanding of snapshotting of APFS-formatted volumes under High Sierra, Mojave, and Catalina. The key points are (a) snapshots are a capability of the APFS filesystem—but a capability that backup applications must be programmed to initiate, and (b) APFS snapshots are made on a source volume and consist of links to files (links taking up essentially no space, which I knew)—so a backup application that initiates a snapshot must then copy the linked-to files. Time Machine and CCC do both these things, but Retrospect doesn't do them yet. The second article says: and, because "a snapshot essentially marks all the currently used data blocks on a volume to be preserved; that is, no changes can be made to them": Both those articles describe how to use commands in the Terminal to create and to restore from snapshots, assuming the source volume containing them is still available. This article describes how CCC makes copies of hourly, daily, and weekly snapshots that it initiates on the source volume; it also describes CCC's Time-Machine-like policy for retaining its copies of those snapshots. The procedure this article describes for Restoring from a CCC-retained copy of an APFS snapshot is simpler than the procedure in the Retrospect Mac 17 User's Guide, but it only works for a startup drive if you've still got one that's functioning. That's why Bombich Software says: Also note that AFAICT the CCC snapshotting capability only works if the destination volume is also formatted with APFS. AFAICT that rules out USB drives that that don't have the capacity of the source drive, NAS drives, and also the cloud as destinations. It is also of interest to everyone that the Retrospect Knowledge Base articles on "macOS Catalina Support", "macOS Catalina – Application Data Privacy", and "macOS Mojave – Application Data Privacy" were updated on 5 May.
  10. Joriz (if Nigel Smith is a good boy he can read this too 🤣 ), Let me start out by guessing that you didn't institute off-site backup because you wanted to play with tape drives, but because your employer seems to be a business that has the responsibility of promptly recovering from the disaster of the server room flooding. (If I emphasize flooding, it's because U.S. companies have been in the habit of putting their server rooms in the building basement underneath the cafeteria—with predictable results. Besides, Belgium borders on the North Sea.) Nigel Smith, from his statement in another thread, seems by contrast to be an administrator for an educational or research institution—where it's the responsibility of the researchers to do their own backup during COVID-19 Work From Home. The reason I suggested daily Copy Backup scripts up-thread is because I thought they would run faster than Copy Media Set scripts, and you seem to be concerned with adding to the total elapsed time of your disk-to-tape runs. In connection with this, I'm not sure from your OP whether you run disk-to-disk Backup scripts on Saturdays or Sundays; from the 10 p.m. start time of those scripts it sounds as if you wouldn't want to run one on Saturday or Sunday night—unless you have employees using the fileservers over the weekend. I'd guess you do, though, and therefore currently have the requirement that a disk-to-tape script run starting at 8 a.m. on Saturday complete before 10 p.m. on Saturday. But if you switched to daily disk-to-tape runs, they'd be incremental and therefore run faster than your current weekly disk-to-tape runs—which seem to be the equivalent of Recycle Backups. You can make sure an incremental disk-to-tape script runs after its corresponding disk-to-disk script run, by designating the same Activity Thread for both scripts. Page 225 of the Retrospect Mac 16 User's Guide says "By assigning activities to the same activity thread, it ensures that they will run one after the other."; an Activity Thread is assigned for a Backup script in a "Use ..." popup at the bottom of its Summary tab that is shown—but not explained—in the screenshot on page 94 of the UG, and is assigned for a Copy script by a "Use ..." popup at the bottom of its equivalent Summary tab. Caution: do not let a Copy Backup/Media-Set script execute in a different—or "Any"—Activity thread from its corresponding Backup script; I discovered a couple of years ago that doing this will allow a Copy Backup/Media-Set script with a particular Media Set as a source to execute while a Backup script with the same Media Set as destination is still running—which I thought was a wonderful feature until the head of Retrospect Tech Support pointed out that a Backup script doesn't update the Catalog File of its destination Media Set (which the Copy Backup/Media-Set script reads) until the end of the run. But so long as you observe this precaution, you are guaranteed that a daily Copy Backup/Media-Set script will not start executing until its corresponding daily Backup script is finished. Therefore you have a full 24-hour day for the combination of the two corresponding scripts to run. Up-thread I suggested using daily Copy Backup scripts instead of Copy Media Set scripts, because I thought they'd run faster. But now I'm not so sure, and I don't have the capability of running a test for it. That's because, contrary to what the UG implies on pages 137-138, my test the other night indicates that "the most recent backup [my emphasis] for each source contained in the source Media Set" doesn't work as of Retrospect Mac 16.6. The source Media Set for my Copy Backup test had been backed up with Recycle last Saturday morning and then backed up withe the incremental No Media Action on Sunday and Monday mornings, but the Copy Backup test copied the entire source Media Set instead of only the last incremental Backup The Match source files against the Media Set and Don’t add duplicate files to the Media Set options didn't have any effect because I had specified Recycle in the Schedule for the script. As for tape wear, I'm afraid that—because of the fundamental non-random-access nature of tape drives—each successive Copy Backup run would probably cause Retrospect to read its way down the last tape mounted on your LTO-7 tape drive to get to the point where it should start writing. Possibly leaving the tape in the drive from one night to the next would prevent it from doing this, but that would only be true if Retrospect remembered the name on the label of the tape from the last run—and therefore didn't have to rewind to read the label—but I don't think it trusts the drive user to that extent. The Linear Tape File System might add that capability, except that Retrospect doesn't use LTFS for Backup operations. And besides, I suggested that you unload the current tape from the drive after each Copy Backup run—and temporarily store it in your boss' office so that it would be in a separate room from the backup disks.
  11. Joriz, Sorry for the delay, but I needed to correctly run a test of a Copy Backup script early this morning. The test copied the last Recycle backup of my MacBook Pro to an extra Media Set that fortunately happened to be occupying spare space on the portable USB3 hard disk drive that has been my destination for Backup runs since early Saturday morning (my scripts switch between 3 such portable HDDs weekly). The successful test run was itself a Recycle, since I had used up the destination Media Set's space on previous tests. The purpose of the test was to get timing for a Copy Backup script versus the Backup script that copied the same data. The Copy Backup script took 30 minutes to copy 65GB of files. The original Backup run, by contrast, took 190 minutes to Backup the same files to the destination Media Set that was the source for that portion of the Backup run. The Copy Backup copying rate was 2.4GB/minute, which is about 7 times the speed of the 0.361GB/minute copying rate of the Backup run. That is what I expected, since my previous experimentation has shown there's a lot of processing work that the Client program does on a Backup run—and my MacBook Pro is is a "client" on my LAN (which has a 6GB/minute speed—allowing 20% overhead for TCP/IP headers). The same Saturday morning Backup run also did a Recycle backup of two drives that are internally mounted on my Mac Pro "backup server" machine; the copy rates were 2.0 GB/minute for the old HDD drive and 2.3GB/minute for the SSD drive. Therefore I simply don't believe that "The disk to tape can be run in the weekend because it needs more time to backup [my emphasis]", as you wrote in this up-thread post. You wrote in your OP "For the Disk to Tape backup I made an individual script for each tapeset. The script type is set to 'Copy Media Set'". I think your disk to tape scripts are actually Backup scripts, whose sources are the same FILESERVERx SMB shares that are the sources in your disk to disk scripts.. They probably run somewhat slower than your disk to disk scripts because their destination is a tape drive (the source and destination of my test Copy Backup script is the same portable USB3 HDD, so that should produce a somewhat equivalent slowdown). I need to go to bed now, so I'll later add suggestions to this post about how to do a Monday-through-Friday Copy Backup script run after each disk to disk Backup run, as I suggested up-thread.
  12. amkassir and Nigel Smith and others, I had phoned the head of North America Sales, and he just phoned me back. He checked within Retrospect "Inc.", and was told that there was ""a ton of coding" done in 17.0.1 to support the additions to pages 154-156 in the latest revision of the Retrospect Mac 17 User's Guide. So what I wrote in the third paragraph of this up-thread post was wrong—I've now corrected it, even though my bare-metal Restore of a High Sierra MacBook Pro slightly more than a year ago seemingly was a klunkier version of the same procedure. Maybe Apple made a bare-metal Restore substantially more difficult with Catalina and Mojave, and the engineers had to revise Retrospect to compensate for that. In regard to CCC, amkassir, here's "Leveraging Snapshots on APFS Volumes", and here's "Everything you need to know about Carbon Copy Cloner and APFS". My understanding of these two documents is that CCC simply creates a snapshot on an APFS-formatted source volume, and uses the contents of that snapshot as the source. If you're doing a bare-metal Restore, that snapshot itself is not available—only the copy of the snapshotted volume that CCC made on the destination volume. If the source volume was poisoned by ransomware before the snapshot was made, then you can only restore a good copy of the source volume if you had CCC also save a the contents of a previous snapshot. That would require a destination volume with—if the source volume is nearly full—twice the capacity of the source volume. So my "Must back up multiple machines to a destination more compact than the same number and capacity [my emphasis] of disk drives" requirement still argues in favor of also using Retrospect.
  13. Joriz, First of all, there's something unusual about one fact in your OP in this thread. There you state you are "running Retrospect [presumably Mac] 13", whereas in this post 8 months ago you stated you were using Retrospect Mac 16.1.2. Did you go back 3 major versions—assuming you continued working at the same company—in the last 8 months, and if so why? Second, I agree with Nigel Smith that your provisions for offsite backup are inadequate for a company that probably can't afford to lose up to a week's worth of data in the event of a flood or fire in its server room. I think you should run a disk-to-tape Copy Backup script every day as soon as the disk-to-disk Backup script is finished, and then store the tapes belonging to the current OFFSITE Media Set outside the server room—possibly in your boss' office. You would bring the tapes back to the server room at 8 a.m., and put them back into the tape library device while the disk-to-disk Backup script is running. That way if the server room is flooded sometime during the rest of the day, you'll still have tape backups as of 8 a.m.. A Copy Backup script should run faster than a Copy Media Set script, since it can be set up to "Copy most recent backups for each source" (see pages 161-162 in the Retrospect Mac 13 User's Guide).
  14. Joriz, First read pages 14-15 of the Retrospect Mac 13 User's Guide. That's why grooming isn't doing anything to reduce the size of your disk Media Sets. If even one source file backed up to an RDB file is still current, then performance-optimized grooming won't delete the RDB file. You should be using storage-optimized grooming unless your disk Media Sets are in the cloud—which you say they aren't. (It seems the term "performance-optimized" can trick administrators who aren't native English speakers, such as you.) There's a reason performance-optimized grooming was introduced in the same Retrospect Mac 13 release as cloud backup. It's because rewriting (not deleting) an RDB file in a cloud Media Set requires downloading it and then uploading the rewritten version—both of which take time and cost money.
  15. amkassir, As for your "Somehow I'm running a version newer than the newest version available? " problem, if you have an open Support Case I suggest adding an Additional Note about it. I've said before that my impression is that 17.0.0 was released in a hurry, and I now think that the 17.0.1 release was equally hurried—since a post by me in another thread said that on 3 April the head of North American Sales publicly predicted a bug-fix release "in about two weeks". IMHO as an outsider, StorCentric management is insisting "full speed ahead" on the development of a "backup server" Engine that will run on a Drobo—with a LAN or Internet-connected Console that will run on a Mac or Windows machine. Add to that the possible personnel fallout from COVID-19, even though J.G.Heithcock revealed in connection with the merger that Retrospect Inc. was now a "virtual business, with fewer engineers than at EMC, who use Google Chat for meetings" with at least the engineers (most of whom must at least be in their fifties, which worries me) working from home. As for your "How is it that Retrospect costs so much more than these but can't manage a streamlined restore?" question, Retrospect "Professional" has been targeted since 1990 at customers with the following requirements: Must back up multiple machines to a destination more compact than the same number and capacity of disk drives, which in many cases still means to tape. Must store at least copies of the backups off-site, because of the danger of fire or flood (a favorite location for organizations' on-site server rooms has been in the basement underneath the cafeteria—so use your knowledge of cafeterias to imagine what can happen) or strikes at the worksite. Must allow an employee to easily restore an obsolete copy of one or more individual files, not just the entire contents of a machine's disk drive. Must allow recovery from a ransomware attack that may not reveal itself until several days after the drives of one or more machines have been poisoned. Must prevent an individual employee disabling backup of his/her machine to speed processing—not easy to do with a "push" backup application. If you don't have any of these requirements, then you can save money by using only CCC or SuperDuper. If however you do, then you're better off with Retrospect plus CCC/Super Duper, at least while Retrospect "Inc." is "working with Apple to resolve the low-level [APFS] filesystem issues" (page 154 of the latest Retrospect Mac UG ). The procedure described on pages 154-156 is essentially a clumsier bare-metal Restore work-around for administrators who can't also run CCC or SuperDuper on all their machines. Stupidly trying to nuke-and-pave my MBP in April 2019, I did an even-clumsier work-around.
  16. amkassir and anyone else worried about the "promised detailed document providing directions for doing a Catalina Disaster Recovery operation'", Retrospect Mac 17.0.1.141—released 1 May— includes "Improved: Disaster Recovery support for Mojave and Catalina - See details" and "Improved: Disaster Recovery redesigned workflow for El Capitan, Sierra, and High Sierra - See details". Both "details" are pages 154-156 of an enhanced Disaster "Recovery" chapter in the Retrospect Mac 17 User's Guide. The only real enhancement is shown in the "macOS High Sierra and Higher" section on pages 154-156; everything else in the chapter is AFAICT the same as it was on pages 143-153 of the Retrospect Mac 16 UG, except for the addition of the section title "Mac OS X Mavericks and Lower" on page 156. (The macOS versions named in the two Release Notes aren't the same as those named in the section headings, but let's not quibble over Yosemite—which isn't mentioned in the UG chapter.🤣) It also includes Linux Client AES-256 link encryption. Arise ye prisoners of Proactive (note the eventual release date); Retrospect 17.0.1 includes "ProactiveAI: Fixed issue where dialog appeared for clients not found on network (#8547)". 😂 A Retrospect Windows administrator got Tech Support's attention (via a Support Case?) about the annoying dialog, and the head of Retrospect Tech Support replied—a rare event on these Forums for several years—that the bug would be fixed in the very next release. 17.0.1 seems to be the promised bug-fix release for 17.0.0, especially for Storage Groups. However there are also bug fixes for other features, including 3 fixes for Remote Backup. I guess Work From Home showed the need for these, and probably also uncovered bugs in Storage Groups and the speeded-up ProactiveAI. There were code changes (did Apple "resolve the low-level filesystem issues"?) for Catalina/Mojave disaster recovery, but the added procedure in the Disaster Recovery" chapter of the UG validates amkassir's Carbon Copy Cloner approach. It spells out a klunkier pure-macOS way to do the same thing, without the "august Documentation Committee" having to make an embarrassing suggestion to purchase CCC. (In my 1950s middle school days we would have said "well, duh-yuh"—implying narrator stupidity, but IMHO StorCentric obliged the engineers to come up with an alternative—so Retrospect "Inc." wouldn't have to admit to "being asleep at the switch" for not having documented the same procedure nearly two years ago.) P.S.: Revised third sentence of last paragraph; there were code changes to enable the the UG page 154-156 procedure to work for Mojave and Catalina
  17. DavidHertzberg

    Retrospect 17 Client Connection Popup

    Hofstede and anyone else experiencing this problem, Arise ye prisoners of Proactive (a cultural reference to the stretched-out release date); Retrospect Windows 17.0.1.165—released 1 May— includes "ProactiveAI: Fixed issue where dialog appeared for clients not found on network (#8547)". 😂 It also includes Linux Client AES-256 link encryption.  This appears to be the promised bug-fix release for 17.0.0, especially for Storage Groups. However there are also enhancements, including 3 for Remote Backup. I guess Work From Home showed the need for these, and probably also uncovered bugs in Storage Groups and the speeded-up ProactiveAI.
  18. Nigel Smith, Based on my experience with a long-time close acquaintance (we've never been in each other's apartments), I'm rather skeptical about your Work From Home approach of issuing "everyone an external hard drive to use with Time Machine or Windows backup"—unless your fellow employees are one and all fairly familiar with computer hardware. My acquaintance is quite knowledgeable in her specialized field—which isn't related to computers or engineering, and is a part-time teacher of university courses that require her to grade student exams and papers etc.. I happened to ask her in January 2018 how she was backing up her Mac, and she said she had bought some kind of wireless external HDD to use with Time Machine. I no longer recall the details, but the HDD was USB-powered and had a battery that was good for 10 hours. It turned out she wasn't routinely plugging in the USB cable to her Mac—her only USB electrical power source, apparently because she was afraid of tripping over a USB cable in her small apartment. So Time Machine was not in fact backing up her Mac; thank goodness she hadn't had a disk crash. How do you know some of your fellow employees aren't as ignorant as she was? OTOH I think your idea "to try Remote combined with Rules" is brilliant for Work From Home.😀 Backup of my MacBook Pro with a No Files Rule—which is essentially what the idea institutes for Rule-excluded "clients"—takes about 3 minutes. If "multiple Proactives using Remote tag, each using a different [presumably Media] set, each with different Rules to filter by client name" actually works with Retrospect 17's faster Proactive scanning, it would get around the problem described in the second and third paragraphs of this up-thread post. But it would only get around the problem for Work From Home, where at-home machines can be presumed to have previously been on the same Retrospect-backed-up LAN—and therefore are guaranteed to have known and non-conflicting client names (otherwise they couldn't have been used as Sources in pre-Work-From-Home backup scripts). It wouldn't get around the problem for the general use case for which Remote Backup was designed in 2018, in which the company might have distinct salespeople David in Davos and David in New York (who wanted to work in Denver, but management said he couldn't)—each of whose machines might be named "David's MacBook Pro". I suppose in that case the Rule could also specify Source Host Login Name (page 178 of the Retrospect Mac 17 User's Guide), which might be needed if the company had two home office employees named David in different Subnets—e.g. because they worked in different home-office buildings. I'd like to add your idea as an Additional Note to my Support Case (note to self, #73054), crediting you and linking to your post directly above. In the first Additional Note to that Support Case (split off because of the approximately-2000-character limit on a Support Case Problem Statement), I proposed—as per the sixth paragraph of this post in another thread—allowing "Remote Backup Clients" to be treated as a prefix in a manually-defined tag such as "Remote Backup Clients A" or "Remote Backup Clients B" that could be used as a Source that backs up only those "client" machines defined with that particular full Tag. If a Retrospect Tech Support test shows that your idea works, the "backup server" Engine modifications that my proposal requires would be unnecessary—at least in the short term. Both your idea and my proposal would, by making it unnecessary to use a Storage Group as a destination in order to get effective multi-threading among multiple simultaneously-running Proactive scripts, also temporarily make unnecessary the enhancements to the half-baked Retrospect Mac GUI for Storage Groups (described by the phrase "For ... in Retrospect for Mac, a Storage Group can be treated like a media set" in the Restore and Transfer and Rebuild and Verify sections of this Knowledge Base article—see fredturner's OP in this thread) .
  19. denno, The instructions for doing a Rebuild of a Media Set are on pages 192-193 of the Retrospect Mac 17 User's Guide; I hope they're what you're following. Presumably you're talking about step 2 in the instructions, where "Retrospect displays a dialog asking you what type of Media Set you would like to rebuild." Forgive me for saying this, but you seem not to be aware of the development in Retrospect Mac starting with version 8. Page 32 of the UG says The File Media Set was superseded by the Disk Media Set (UG page 262) in Retrospect Mac 8, and is considered obsolete because of its limitations—although last fall it turned out that there was an administrator who was still stuck with using File Media Sets (which Retrospect Mac still supports). If you're still using File Media Sets on your Drobo, may the Lord have mercy upon you.🙄 If so, I'd phone Retrospect Tech Support and get guidance on how to convert your File Media Sets to Disk Media Sets—or on how to rebuild a Catalog File for a File Media Set. If you are already using a Disk Media Set, select "Disk" and continue with the instructions beginning with step 3. BTW, you still haven't supplied a description of what machine(s) and drives you're backing up as Sources. Also, although maybe I shouldn't say this because the manufacturer of Drobo (StorCentric) now owns Retrospect "Inc.", possibly—based on a 2010 thread about "Catalog File out of sync with Backup Set" that eventually found a cure with a Retrospect Driver Update for a tape drive—there's a problem with your Drobo device. Is it new, and did you also just upgrade to Retrospect Mac 17—in which case you're entitled to 30 days of free personalized Tech Support (see my third paragraph in this post) even if you didn't sign up for Annual Support & Maintenance?
  20. denno, Welcome back to the Forums; it's been about 10 years. Presumably you are no longer using Retrospect Mac 8; would it be too much trouble for you to post your version of Retrospect, plus the OS and hardware of the machine(s) you are backing up? You may have a hardware problem; try Disk Utility on the Source drive whose backups results in the error. The very-knowledgeable Lennart_T suggested in this 2017 post doing a Rebuild of a Media Set catalog instead of a Repair of it. The last two paragraphs of this 2017 post by me describe an even-more-time-consuming method of dealing with catalog problems. Both methods require having all the Members of the Media Set available, so you might consider doing a Recycle backup of all your Source disks if those past Members are not available.
  21. Nigel Smith, You've obviously not been "blessed"—as Alanna evidently has—with a directive from management, or a demand from other employees, that nearly everyone in the centralized office Work From Home because of the COVID-19 pandemic. An easy way to handle that, which avoids quickly setting up a VPN and then making all those employees bring their home routers—with router-brand-specific GUIs you've no experience with—into the office so you can (if the VPN permits it) open ports 497 and 22024 for TCP and UDP (requiring thorough hand-washing by you and the other employee before and after), is to use the Remote Backup feature introduced with Retrospect 15.6 in the fall of 2018. The 2018 customer use case for Remote Backup was for—e.g.—a company with its main offices in Britain that has a few salespeople such as Sally in Shanghai and Albert in Adelaide, each of whom has files on his/her laptop that the company's backup administrator wants to be sure are backed up on a "backup server" running 24/7 in Britain. The "backup server" can't "reach out" either if Sally and Albert's machines don't have predictable Internet addresses, either because Sally and Albert don't work from fixed local offices, or because—in the case of Sally—that office cannot be contacted from England via Retrospect multicast because of a Great Firewall. Therefore Remote Backup piggy-backs on Retrospect's public-key cryptography facility. The Retrospect Client installer for each particular Remote machine designates the Internet address of the "backup server" and includes a customized public key. The "backup server" maintains a table of Remote-machine-specific public keys and their calculated corresponding private keys. When a Remote "client" machine contacts the "backup server" using the address stored on its Client with a backup message specifying its own calculation of the private key—and encrypted with the customized public key, the "backup server" uses the calculated customized private key from the table to verify that the message is from the authorized Remote "client" and the corresponding public key to decrypt it. (Please excuse sloppiness in the preceding sentence; I know nothing about cryptography, and I've no inside info.) Unlike Using Multicast and Using Subnet and Add Source Directly, that approach does not reveal to the "backup server" the Name of any Remote Backup machine—which would be meaningless for an administrator since it isn't resolvable to a fixed reachable-by-the-"backup-server" IP address. Thus such a Remote "client" cannot be specified by Name as a Source for any backup script. To solve this problem, in 2018 the Retrospect Inc. engineers devised a kludge. Retrospect has a Tag facility for grouping multiple machines; thus only the Tag for those machines need be specified as a Source in a script. The Remote Backup facility interprets the exact Tag "Remote Backup Clients" as a synonym for all "client" machines that can "reach out" to the "backup server" with a public key that is in the "backup server"'s Remote Clients table. Remote Client backup only applies to Proactive scripts, so unscheduled "reaching out" can occur any time such a script is running—in a sequence depending on when the Remote "client" happens to connect to the Internet. That's the limitation that can make the "Remote Backup Clients" Tag a true kludge for Work From Home. As Alanna discovered in March, any Proactive script that specifies the exact Tag "Remote Backup Clients" as a Source will backup all "clients" appearing in the Remote Clients table that "reach out" to the "backup server" while it is running that Proactive script. Since an individual Retrospect script is not multi-threaded (because it is executed within a particular Activity Thread) if its destination isn't a Storage Group, all those "Remote Backup Clients" would be backed up one-by-one. This wasn't a problem in 2018; if salespeople Sally in Shanghai and Albert in Adelaide are in different time-zones from each other, they're presumed not to have their laptops connected to the Internet at the same time, and—if the company has only a few such remotely-located salespeople—it's OK to back them up via a single Proactive script running 24/7. However that kludge creates problems when a massive number of employees in the same time-zone start working from home because of COVID-19. Let's assume that each such "client" takes 0.5 hours to back up, and you want to back up each such "client" daily. That assumption puts a limit of 48 "clients" that can be backed up with a single Remote Backup script, even if all such "clients" are connected to the Internet 24 hours per day. (That this assumption is not unreasonable is borne out by the fact that my 2016 MacBook Pro takes about 0.5 hours for an incremental Retrospect non-Proactive backup, even though its speedy connection to my Mac Pro "backup server" is over an in-the-apartment MoCA cable connection.) But the kludge is eliminated if the destination is a Storage Group; if so a single Proactive script is multi-threaded—the maximum 16 threads can back up 768 0.5-hour "clients" daily on a fast-processor "backup server" with 16MB available RAM. So if you're forced to use Remote Backup , you can't "do similar by running multiple Proactive/Scheduled scripts, each targeting their own backup set, all stored on the same destination resource." P.S.: Insert second paragraph showing how Remote Backup uses Retrospect public-key cryptography to allow a "client" to "reach out" to a "backup server" P.P.S.: Revise second paragraph, because I think I understand public-key cryptography a little better now—but the last un-parenthesized sentence is still sloppy
  22. DavidHertzberg

    Bitlocker and Retrospect 17

    Hofstede, If the Retrospect Engine and Client "are completely unaware that Bitlocker is enabled", then all files on the Backup Set surely are encrypted. So why use Retrospect's encryption facility to double-encrypt them? I'm a Mac administrator, so maybe there's something I don't understand about BitLocker.
  23. DavidHertzberg

    Bitlocker and Retrospect 17

    kidziti, The OP in the 2013 thread I linked to in my preceding post, sjacobs, made this March 2015 post regarding his/her then-recent installation of Windows 10. I would describe his/her tone as "happy as a clam". He/she says "Both of these are remote clients - I run the the backups from a separate Windows box and use remote clients for all of the computers that I need to back up. So I am never doing any local backup." There is no indication he/she had to disable BitLocker, so I don't think you have to worry about any problems with your soon-to-be Windows 10 Pro laptop. In December 2016 sjacobs reported problems backing up a CentOS Linux machine using the 64-bit Linux Client and a Proactive script. He/she said "This is my only Linux client - all other clients are Win clients - and do not exhibit this same issue. So I am sure it must be something peculiar to the Linux environment on this machine...". He/she hasn't posted to these Forums since then, so I don't know if he/she's still using Retrospect and looking at them. You could try sending him/her a Message; please post here on what he/she says about using Retrospect with BitLocker on Windows 10. The cumulative Release Notes for Retrospect Windows 17.0 don't show any fixes that seem related to Windows 10, much less BitLocker. But I'm a Mac administrator, so I may not know what I'm talking about.😀 FWIW, there's supposed to be a new release of Retrospect 17 coming out within a few days. P.S.: The cumulative Release Notes for Retrospect Windows show Client certifications for various releases of CentOS starting in September 2017, so the chances are sjacobs filed a Support Case and is still a Retrospect user.
  24. DavidHertzberg

    Bitlocker and Retrospect 17

    kidziti, You may not be aware that we have a Search function in these Forums, used via the oval box towards the upper-right corner of the Web page. Just remember to click "use all search terms" if that's what you want. Clicking on the magnifying-glass icon gives a more complete set of search options. Using it, I found that this 2013 post seems to be the most complete answer to a BitLocker problem an administrator encountered with Windows 8. In the OP's post at the end of the thread, I suspect he/she meant to type "now" instead of "not" in "I am not able to access C:." Nobody seems to have posted concerning BitLocker on Windows 10.
  25. x509, IMHO Mihir Shah is well aware of Retrospect's reputation for taking a long time to fix bugs. My evidence is in the Support Case system. From 2017 it hit any administrator filing a Support Case with a strongly-worded pitch for buying Annual Support and Maintenance. In fact I felt it necessary to include a fifth paragraph in my boilerplate post on filing a Support Case for a bug, saying an administrator doesn't need to be signed up for ASM to report a bug. Sometime in the last month or so that ASM pitch has disappeared, which I take as an indication that Mihir Shah realized the pitch—which apparently was added to the Support Case system because Tech Support's departmental budget was largely dependent on ASM—was deterring administrators from reporting bugs and therefore the engineers from fixing them.
×