Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 12/07/2018 in all areas

  1. 3 points
    David, your condescending comments aren't needed here. Martin (and others, myself included) are frustrated at this slowness, and a little venting is not out of order. I don't understand why you feel the need to carry water for Dantz - if you don't have anything positive to contribute, you aren't required to post.
  2. 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 "
  3. 1 point
    insont and cgtyoder and CherylB, I haven't been denying that long scans are a real problem for Retrospect administrators backing up Mac drives formatted with APFS. I'm really sorry you folks have this problem. It's not a problem for me, because my two modern Macs are running macOS 10.13 High Sierra (just upgraded last week at the urging of Apple Support—keeping the machine's only drive still formatted with HFS+) and macOS 10.12 Sierra. One reason for my OS backwardness is that I had a deep-seated mistrust of APFS; I felt—and still feel—that a brand-new filesystem was a big challenge for Apple. That feeling was later confirmed by my reading here (along with other places) that Apple didn't publish full documentation on APFS until sometime in 2018. As I said 8 months ago in this thread, the developers of another backup application turned out to be also having problems with their equivalent of Instant Scan not working for APFS. But, as I tried to make clear in my latest previous post, the reason Retrospect has slowness of non-Instant scanning is probably because it has been using 32-bit Mac APIs for the last 30 years. Now here's something "positive" I can contribute. A couple of hours ago I phoned Retrospect Inc. Sales. A senior salesperson there told me the engineers are working on this problem, and that it's likely to be fixed in version 16. If you feel it's necessary to put additional pressure on Retrospect Inc., my advice is for each of you to submit a separate Support Case. Here's why and how to do that. Just copy your individual post(s) in this thread into the Description of Your Issue, which IMHO should be categorized as a Problem rather than as a Backup Error.
  4. 1 point
    David, Yes, I know that Retrospect doesn't implement instant scan anymore, but they sure do scan. Not so instant, though. And yes, Arq doesn't do fsevent monitoring, but where the full scan on Retrospect is comparable to the full scan in Arq, there's a nine-fold difference in scanning speed. Nine. At least. And yes, Retrospect has said they're going to fix it, but after seeing no sign of that for eight months now, can I not be excused for getting really irritated? Especially since Arq (and other products) show that this problem is clearly solvable? And considering that Retrospect cost me around ten times the price of Arq, the price-performance ratio between the two is 1:100. I promise to stop complaining once Retrospect shows any sign of at least trying to do something about this. And so far, nothing. /Martin PS: my name really is "Martin". "Insont" is only a handle. I thought that was obvious by now.
  5. 1 point
    Backing up my MacOS machines is still taking 3-5 hours every time, always with a heavy CPU load. And any interruption makes it start all over again, so in practice I have to leave the machines on all day just for Retrospect. I've reduced the backups to one day a week simply because I can't stand feeling (and hearing) all that hot air. Meanwhile I tried ArqBackup and it has none of these problems on the same machines. It blows through the backups in no time. It runs every hour with no noticeable CPU load. If a one man product like Arq can do this on APFS, why can't Retrospect? The performance difference is completely surreal. Arq seems to be very similar to Crashplan in this respect. Or rather, similar to practically anything except Retrospect. I'm starting to wonder if all that money I spent on three years of support on Retrospect wasn't wasted. It sure looks like they don't really care. No solution of any kind has appeared yet and this has been going on for quite a while now. If it wasn't for that investment, I'd have thrown out Retrospect by now. Sorry about that. I needed to vent. /Martin
  6. 1 point
    So how about updating the Gender in your Forums Profile, myhrik, from "Not saying" to "Male"—as I did years ago? In general I don't try to guess people's genders from their "handles", although I make an exception for those "handles" that are obviously male or female. OTOH I can't help but be aware that many backup administrators are women, and that a lot of those try to conceal that fact for fear that they won't be taken seriously on the Forums. Unfortunately myhrik's ancestors, when they invaded Britain, contributed a number of words to the English language—but not gender-neutral third-person pronouns. So I write "him/her" and "he/she" when the Forums Profile doesn't specify Gender and I can't guess. My other tactic is to address a poster with the second-person pronoun, which is gender-neutral in English (and has no difference between singular and plural, unless you're either from the American South—where they use "y'all" for the plural—or an old-time Quaker—who might use "thou" in talking to someone besides the Almighty). That's why so many of my posts begin with my naming the poster(s) I am responding to, myhrik.
  7. 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.
  8. 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!
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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."
  16. 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).
  17. 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.
  18. 1 point
    bradp015, I agree that it looks as if you have enough space on "4T HD" for another copy. The one thing that occurs to me is that you have two "Retrospect" folders on that drive. even though one of them is underneath the "NO USE SFA 3SAFE 4t 111116" folder. IME the parts of Retrospect that deal with creating Members on disk drives are programmed to either detect existing "Retrospect" folders or to create new ones. I'd hazard a guess that those parts get confused when there's more than one "Retrospect" folder on a drive. I'd suggest that you Finder-move the "SFA 3SAFE" folder that's two levels inside the "NO USE SFA 3SAFE 4t 111116" folder so that it—and its subsidiary "1-SFA 3SAFE" folder—are directly within the "NO USE SFA 3SAFE 4t 111116" folder, and then Finder-delete the "Retrospect" folder that the moved folder used to be underneath—along with the "Retrospect" folder's contained 0-byte "Backup Media" document. If you ever need to put the moved copy of the "SFA 3SAFE" folder back into action, you can first re-create a "Retrospect" folder and then Finder-move that "SFA 3SAFE" folder back inside it. Come to think of it, maybe the 0-byte "Backup Media" document is a marker to tell Retrospect that the "Retrospect" folder that contains it also contains a Media Set Member folder. If so, it would explain why Retrospect would get confused when it found more than one "Retrospect" folder containing a 0-byte "Backup Media" document on the same disk volume. Yes indeed, that's the sort of kludge I might have devised myself back when I was an applications programmer.
  19. 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.
  20. 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).
  21. 1 point
    bradp015, First, on your old single drive, you need to rename the folder inside your Retrospect folder to WhateverItIsSAFE. Then you need to rename the folder inside that to 1-WhateverItIsSAFE. Finally you need to create a new Media Set (only benighted users of Retrospect Windows have Backup Sets, sneer, sneer ) named WhateverItIsSAFE, and add as its first (and I presume only) Member 1-WhateverItIsSAFE on the old single drive. The procedure is described starting on page 99 of the Retrospect Mac 10 User's Guide (I can't cite the equivalent page in the Retrospect Mac 9 UG because that's only an Addendum to the Retrospect Mac 8 UG). If you have already defined a Media Set named WhateverItIsSAFE, you should instead Rebuild it—as described starting on page 213 of the Retrospect Mac 10 UG—and add 1-WhateverItIsSAFE on the old single drive as its first (and I presume only) Member.
  22. 1 point
    I got that feedback from support recently as well and reported it in another post here. Frankly, when using SSD's in clients, I don't see a huge advantage to ISA. Whether in incremental or full backup. It is a CPU hog and space hog. Maybe also duplicates processes already in place (in the case of APFS). I will compare again in 15.6 with ISA disabled to confirm this. Once turned off, intend to leave it that way. Locally, on HFS+ formatted (HDD) drives, maybe some advantage, but since the server does its thing quicker locally and is essentially unattended, I don't care too much. My 2¢... Henry
  23. 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.
  24. 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
  25. 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
×