Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 10/22/2018 in all areas

  1. 1 point
    I'm backing up a couple of Macs and Retrospect seems to place an inordinate load on them. My Macbook Pro 17", for instance, is hyperventilating several hours per day even though I hardly use it. I had Crashplan until they cancelled the service, and even though they backed up every 15 minutes, it was totally inconspicious and effective. Retrospect is a steamroller compared to that. Admittedly, Retrospect backs up more files, but still. Every now and then backups went smoother, and that was when Instant Scan did its work (as verified in the logs), but most of the time Instant Scan simply bogs down the machines but doesn't actually work. I had a week-long exchange with Retrospect support about this, trying to figure out why Instant Scan is totally ineffective, but once they escalated, I was told Instant Scan is no more. Not that it's having problems, no, that it has been abandoned. Does that mean my Mac backups will continue to be so grossly overloading the machines? I'll quote verbatim the last message I did get from Retrospect below. To me it sounds like Retrospect on MacOS will forever remain a dog. (I should mention that Instant Scan already didn't work before I upgraded to 10.13 and APFS. I also assume Retrospect support meant to say "APFS" and not "AFP", which makes no sense in relation to 10.13. And makes no sense in any case on the local machine where Instant Scan works. Or maybe they actually did mean AFP and then I understand even less.) "Dear Martin, Retrospect Engineering Reply can be found below. Instant scan doesn't work on AFP, and most likely customer is using AFP if they are on OSX 10.13.We recommend disabling instant scan in ALL cases, we are disabling instant scan by default in future versions of Retrospect.Thank you for using Retrospect,The Retrospect Support Team "
  2. 1 point
    lhlo (demerits for picking a cutesy-poo "handle" for which I can't figure out whether the first letter is upper-case 'I' or lower-case 'l'), First, read the boxed-in paragraph below the screenshot at the top of page 448 in the Retrospect Windows 9.5 User's Guide. If that paragraph describes what happens when your Member is full, un-check the checkbox and increase the "Use At Most" number of GB appropriately. Second, if that doesn't work, do what it says on pages 449-451 of the UG under "Adding a Disk to a Backup Set". Add the new Member on the same disk as existing Member, and give it the appropriate "Use At Most" number of GB. This post describes that as the workaround for an earlier version of Retrospect Windows. So this is your "poor second choice", but next time you'll remember to set the "Use At Most" percentage appropriately when adding all new Members.
  3. 1 point
    It all depends on what the problem is. If it was introduced at the file system level, e.g. a disconnect while writing data, then fine. The problem will be with the volume presented to Disk Utility and will (since this is a hardware RAID) be present on both drives. Fix the volume, fix the problem. If it's a disk problem then no, don't go there! One disk should be showing as "failed" -- simply pop, replace, rebuild RAID. Perhaps worth noting that RAID =/= backup -- it will protect (somewhat) against hardware failure, but not e.g. data corruption. And personally, I wouldn't trust *any* volume, RAID or not, that "unexpectedly" unmounted. Get that sorted before continuing!
  4. 1 point
    bradp015 and Lennart_T, bradp015 can as of Retrospect Mac 14.6 do what he suggested in his OP, so long as he is simultaneously backing up a different Favorite Folder on the same drive in each script. He could divide his whole disk into Favorite Folders, which only apply to Retrospect, and have his two scripts back up the Favorite Folders in a different order. Alternatively bradp015 could do what Lennart_T suggests, with a Backup script and a Copy script. However he should be sure to assign the same Activity Thread, in the Summary tab for the Scripts, if he schedules the two scripts so that they could possibly overlap in execution. If he doesn't make sure to do that, the Copy script will ignore new or changed files that are being backed up—since it uses a Catalog File that is not updated for the Media Set until the end (barring any optional Comparing) of the Backup script run. P.S.: On 10 January 2017 I suggested in this Product Suggestions—Mac OS X thread that a modest enhancement to Retrospect would enable overlapping a Backup to a particular Media Set with a Copy Backup or Copy Media Set from that same Media Set as the source. That enhancement assumes that the Copy script would be scheduled at least a minute after the Backup script. On 2 April 2017 I converted that suggestion into Support Case ##54601 for a Feature Enhancement. That Support Case has been closed, with no evident action taken on it by Retrospect engineering since then. Considering that Retrospect 15 now enables multiple Activity Threads (Execution Units for Retrospect Windows) even for the Desktop Edition, IMHO Retrospect engineering should reconsider that enhancement for Retrospect 16.
  5. 1 point
    No, there isn't. No, you can't. Both the source as well as the destination must be different for scripts to run concurrently. You could run a normal backup script from the source computer(s) to media set A. Then you could run a "Copy Backup" script from Media Set A to Media Set B. That way the source computer(s) is/are not involved and free for other uses.
  6. 1 point
    Ok, problem solved (or worked around). I followed the advice from this old thread, even though this is a NTFS drive under Windows : But I also removed all the tickboxes under the Windows Security backup options in the script. Disabling both (which I don't really need anyway) does solve the problem and a re-run doesn't backup anything anymore that was already backed up before.
  7. 1 point
    Here's a thread I just found, entitled "Disk Media Sets Have Wrong Free, Capacity Columns", discussing the problem for Retrospect Mac 9. If you search the cumulative Release Notes for Retrospect Mac, there are several entries containing the word "capacity". However the only one with much relevance seems to be "Fixed: Media Set available capacity lists correct values (#5370)" for the Retrospect Mac 12.0 Console.
  8. 1 point
    Sorry, Lennart_T; I termed you a "now-two-Retrospect-variant-expert" only to describe what I thought was your work history. I thought that you had had a long-time job that included administrating a Retrospect Windows installation, and that you were then laid off and found a job that included administrating a Retrospect Mac installation. I didn't realize that you have Retrospect Mac at home. Whatever the historical reason, you certainly are an expert in both variants of Retrospect. I rely on you to deal with many of the difficult administrator problems posted on these Forums, since I have only used Retrospect Mac (versions 3 through 6, then versions 12 through 15) for my home installation. Thanks.
  9. 1 point
    We could not bring the hard drive back to life. Lennart_T suggested to "Repair" the media set in Retrospect which I ran yesterday. Today I am happy to report the repair was the correct fix and I have a backup for the entire lab. Thank you Lennart_T Once we have the hard drive for the failed computer replaced it will be added to the backup schedule.
  10. 1 point
    CherylB, Congratulations, a search of the Forums shows you are the first administrator reporting error code -808 for Retrospect Mac. Nobody has reported this error code on Retrospect Windows for about 9 years, but the most appropriate thread—one for a Backup—seems to be this one. The now-two-Retrospect-variant-expert Lennart_T then suggested "I don't know what caused it, but you should recreate the catalog file to rectify" in the second—and last—post in that thread. Ununnilium never reported whether that worked. However 15 days later, in another thread concerned with running out of RAM during a Catalog File Rebuild, he/she reported "As a followup, I noticed that the backup set [Retrospect Windows term for a Media Set] was created."
  11. 1 point
    It's during the matching. The first thing to try is to repair the hard drive on Akumar's iMac, but I don't really think it would help. At least it can't hurt. https://support.apple.com/guide/disk-utility/repair-a-disk-dskutl1040/mac If that doesn't help, try to "Repair" the media set (in Retrospect). If that doesn't help, try "Rebuild" the media set (in Retrospect).
  12. 1 point
    No, don't do a Copy Backups, because it will only copy the most recent backup of each source unless you have specified a number of snapshots in your Grooming policy—per this 2016 post by a Retrospect Inc. employee. Unless your Copy Media Set run finished just before copying those backups, following up with a Copy Backups run will leave backups un-copied. Just delete the stalled-run data, Rebuild the destination Media Set, and run the whole 15-hour Copy Media Set again. Sorry to be the bearer of bad news.
  13. 1 point
    We have released a patch that users of Retrospect 14 and earlier can use if backups incorrectly show a deferred status. https://www.retrospect.com/en/support/kb/deferred_date_on_mac You will install a new Retrospect console and continue to use your earlier Retrospect Engine. This fixes the issue without purchasing an upgrade.
  14. 1 point
    bradp015, You fail to understand the overall idea, which is that you will run a Copy Media Set script once and then run a Copy Backup script daily. I don't have time to write a post describing the procedure just for you, but here is a post I made in September 2016 describing a superset of that procedure—one for creating and maintaining a running copy in the cloud of backups to a local Media Set. In steps 1) through 6), ignore anything concerning Grooming or a cloud account—which means you can essentially convert steps 3) and 4) into whatever it takes to set up you new local duplicate-of-the-original Media Set. In both steps 5) and 6), don't check No Verification unless you like living dangerously (cloud providers are supposed to have such error prevention that lengthy-and-expensive verification isn't necessary). Ignore step 7).
  15. 1 point
  16. 1 point
    This might help (even if the mentioned screen dump seems to be lost in the mists of time):
  17. 1 point
    Here you go. https://www.retrospect.com/en/support/kb/moving_retrospect_from_one_macintosh_backup_computer_to_another_macintosh_backup_computer
  18. 1 point
    Guys, Sorry for going silent on this thread. I do have Instant Scan on. I'm working on some suggestions from Retrospect support. As soon as I have something definite, I will report it here. So far, if I run an immediate backup, the backup works properly. x509
  19. 1 point
    JamesOakley, It sure as heck gets more of their attention and memory than simply posting about a bug on this Forum, which nobody at Retrospect Inc. reads anymore (per CEO J.G.Heithcock). That fact is AFAIK one reason Retrospect Inc. instituted Support Requests; previously the organization had a sad record of often taking 4 years or so to fix bugs. Besides, how much time do you really need to spend on a Support Request? After supplying installation details that they definitely need to isolate the bug, all you need to do—as the post linked-to in the preceding paragraph says—is to copy-paste paragraphs from your post(s) here. You can upload screenshots as part of the Support Request. If you really want to get someone's attention, you can also phone Werner Walter as indicated in this post, or even send an e-mail to Brian Dunagan as indicated in this post. However I'm afraid that Brian truly needs to devote his full attention to organize the engineers in fixing this "bad release". I'm beginning to think that x509 may be right; that, in order to "play catch-up ball" after this situation (third and fourth paragraphs), Retrospect Inc. may have entrusted some enhancements to R. non-V. to developers in China—without ensuring thorough testing. I think I can safely say that the old-timers at Retrospect Inc. will be sufficiently be scared by knowing that they have put out a "bad release". If you read between the lines and follow the references in the second and third paragraphs of this article section, you will realize that Retrospect Mac practically "went down the tubes" as a product in 2009-2011 as a result of the "bad release"—one that was really the fault of EMC management rather than the developers— of Retrospect Mac 8.0. P.S.: In last sentence of first paragraph added link to Engst 2009 TidBITS overview of Retrospect Mac 8, where "Cracks in Retrospect’s architecture started to show ...." reflects delays in fixing bugs.
  20. 1 point
    This is a pretty serious regression since the 12.x versions. Certain errors (specifically including a client being unreachable) no longer fail elegantly with an emailed report, but cause the whole engine to hang so that nothing is backed up. Further more, the hang is serious enough that it can't be restarted from the dashboard - it requires the task manager with elevated permissions.
  21. 1 point
    x509 Do you have InstantScan running on the drives in question? I have encountered situations before where, although InstantScan is active and reports no detectable errors, the volume databases stops updating and so as far as Retrospect is concerned no new files have been added files have been added, changed, or deleted on the volume. When a file is added, changed or deleted the volume database should be updated fairly soon afterwards so if the file time stamp of the volume database is not updating then InstantScan is not updating. The InstantScan volume databases are in the C:\ProgramData\RetroISA\RetroISAScans folder. To reset stop the InstantScan services, delete the volume databases, the restart the InstantScan services.
  22. 1 point
    insont, That's good, because I just found a 15 May 2018 Knowledge Base article change confirming what you've been saying. The paragraph "Mac Customers: Please note that Instant Scan is not supported with APFS." has been added below the first paragraph in the KB article "Instant Scan Frequently Asked Questions". which is under the catch-all heading "Resources" in the KB . That first paragraph begins with the sentence "Retrospect 10 for Macintosh and Retrospect 8 for Windows introduced a new feature called Instant Scan." This section of the permalinked old version of the Wikipedia article says those versions were introduced in 2012, so the original article almost certainly dates from sometime shortly after that year up through April 2015—when the companion article "Instant Scan Advanced Options" was published. Sorry to have previously expressed doubt, Martin. Pretty sneaky announcement there, Retrospect Inc. ; you didn't even point Martin to it in your final reply to his Support Case.
  23. 1 point
    Well, I did write support to ask if they had plans to fix Instant Scan in the future or if they'd given up on MacOS, and got some encouraging news: /Martin
  24. 1 point
    David, I copied verbatim what Retrospect support sent me. How can I prove that to you? And yes, I created this login specifically to post about this, since the reply from Retrospect upset me. I didn't expect, however, to be accused of lying in the process. About "recent visitors block is disabled" I know nothing. I haven't touched my profile from the default. I'm sorry if I broke some kind of rule by not doing that. BTW, since you doubt my veracity, I'd suggest you ask Retrospect support if this is true. Either they confirm what I just said, making me somewhat happy, or they backtrack and say they are going to support Instant Scan in the future or that I misunderstood, and I'm even happier. To me their reply seems not quite thought through and not good for the product, so you asking could make them think again. Oh, and the case is nb 00061949 that contains this exchange, including the message I quoted. You're welcome to reference that. Martin
  25. 1 point
    Assuming you are talking about a "Disk Backup set", this is what you do: Exit Retrospect. Move (not copy) the folder with the *.rdb files to its new location. Launch Retrospect Configure-->Backup Sets. Change the location in the "Members" properties by clicking on the "Browse" button. See attached picture.
×