Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 01/25/2019 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. 2 points
    As promised. The Test Client: "NIG-PC" -- Windows 10 VM, Retrospect 15.6.0, with C drive and external E drive. Both drives had "Test_Data" and "Test_Data2" directories, each with a couple of text files inside. Server: Windows Server 2016, Retrospect Multi Server Premium v15.6.1.104 Client was added by Direct IP with "Volumes" tab "Client Sources" set to "Client Desktop" -- both C and E drives were visible A new disk-based Backup Set called "Filter_Test" was created A new filter called "Filter_Test" was created, initially blank and then edited as per the following screenshots After the filter was edited, an Immediate Backup was created: Source -- "NIG-PC"; Destination -- "Filter_Test"; Selecting -- "Filter_Test". The Preview button was clicked and, once the results generated, the screenshot taken. The Immediate Backup was then cancelled to clear any cached Preview and to force a re-scan for the next test The Results "Windows folder path exactly matches \Test_Data\" -- no drive letter, so nothing is matched: "Windows folder path exactly matches E:\Test_Data" -- no trailing backslash, so nothing is matched: "Windows folder path exactly matches E:\Test_Data\" -- drive letter and trailing slash included, matches only with "Test_Data" on E and not E:\Test_Data2 or C:\Test_Data: So, what about "matches pattern"? We know from the filter dialog tip that "* matches any or no characters and ? matches any single character", but x509 had no special characters in his filter yet still got matches. Let's see what we can find out, starting with a filter similar to x509's... "Windows folder path matches pattern \Test_Data" -- matches Test_Data and Test_Data2 on both drives: "Windows folder path matches pattern \Test_Data\" -- matches Test_Data only on both drives: "Windows folder path matches pattern E:\Test" -- matches Test_Data and Test_Data2 only on the E drive: "Windows folder path matches pattern st_Data" -- matches Test_Data and Test_Data2 on both drives: Conclusion Exact folder matching requires a full path, including the drive letter, and a terminating backslash, i.e. "E:\Test_Data\". The "matches pattern" condition includes invisible "*"s, both prefix and postfix, i.e. if you enter "st_Data" it is actually "*st_Data*". That may be what you want, e.g. the same folder name at different levels of the directory structure across multiple drives on a client, but could also greatly widen the matches beyond what was expected. As always, the more explicit you are the closer the filter results will match your wishes. Vagueness on "includes" can massively increase backup resource requirements, vagueness on "excludes" can result in important data being missed. So test, test, test -- and be careful out there! Note Yes this was all done with "includes" whilst x509 was having trouble with "excludes" -- that's simply because I think it is much easier to see none, one or two ticked boxes amongst a column of unticked in a fuzzy screenshot than to spot the gaps in a line of selected items. But the conclusions above also apply to "excludes", and it's simple enough to verify for yourself if you doubt it. Hope that helps someone!
  3. 1 point
    Earlier this year, I tried to restore my "production" system, following the directions in the V15 manual. That system is Windows 10 Pro 64. The V15 manual states on p. 99 (my highlights) So I blithely assumed that I could do a Restore of my C : partition, after it somehow got hosed. Wrong!! I ended up reformatting that partition, doing a fresh install of Windows, and then re-installing all the programs and doing all the config settings. So I was pretty frustrated about the experience. When I wrote a letter a few months ago to Retrospect management about a bunch of issues, I included this issue. I got a detailed response to all my issues from Robin Mayoff, which I do appreciate. However, it was very frustrating to read the following. When you perform a restore of a Windows operating system with Retrospect, it is very important to perform this restore while booted from a Retrospect Disaster Recovery disk. It is not possible to restore a modern version of the Windows registry or Windows system while booted from the C disk. This is probably why you got some errors and ended up needing to reinstall programs. Had I known this point, I could have saved myself several days of work. Why am I posting this now, months after the fact? I can't fully explain why, but "stuff" happened. Still I thought this point is important enough so that the next person with this problem might find this post and save themselves a lot of trouble. As the expression goes, I am "paying it forward" in appreciation for all the help I get in this forum.
  4. 1 point
    Interesting. I just finished discovering a specific set of bugs in Retrospect, and challenges in our router(s) and local network apps, that directly lead to the above anomalies in finding and/or connecting to clients. (Yes, all of the following has been submitted as a bug report.) I'm running a more Windows-centric network, with a little OSx tossed in, so my tools are a bit different. Tools: WireShark: shows packets actually traveling. Most useful is a filter of udp.port==497 || tcp.port==497 tcpdump (command line in linux and/or osx) - monitoring port 497 TCPview (from SysInternals, now owned by Microsoft) - sort on port. Look at what is listening to 497 and on what IP address(es) (command line) ipconfig and also "route print" In Retrospect: go into Clients -> choose a client-> access tab -> Interface -> Configure Interfaces ... and see what default interface IP address is. Things to watch for: Are UDP broadcast packets being received by clients? (eg 192.168.x.255, port 497) For multicast, are packets getting to clients? (eg 224.0.0.0/4 -- Retrospect uses 224.1.0.38 UDP port 497) Are clients responding to those packets (UDP broadcast or multicast) (initially to UDP port 497 on the backup system) If crossing subnets, is TTL set high enough to reach the client? What could possibly go wrong? Heh. Here are anomalies I've seen: Often, some app will create virtual interfaces. This includes npcap (for Wireshark etc), VMware, TAP-Windows (comes with Windows?), etc... This has led to: On some of my clients, some virtual interfaces have APIPA addresses (169.254.*) -- which makes it obvious when retrospect chooses the wrong interface to listen on! (Workaround: I uninstalled the TAP-Windows adapter as I don't need it. And I temporarily disabled npcap on the one workstation where that got in the way.) On my retrospect backup desktop, retrospect chose one of the VMware virtual adapters as the default adapter! This even though the real gig adapter has higher priority etc etc. (Workaround: create another adapter in Retrospect) The result in either case: I can't see the clients, even though ping works. I have a network security system. It regularly scans all ports on all subnets. Some (but not all) clients get confused by this, with the retroclient app hung up on an IP connection in CLOSE_WAIT status. The result: the client is never available for backups. Yet it is visible to subnet or multicast. We switched to a pfSense firewall/router. I just discovered that multicast forwarding is badly broken.(Workaround: manually installed pimd.) Similarly, UDP broadcast is often blocked by firewalls. Make sure the packets are getting through! Having fixed and/or worked around ALL of the above, and rebooted everything... I can now reliably use either multicast or subnet broadcast to connect with clients.
  5. 1 point
    Joriz. First I suggest you read this April 2019 thread—the whole thread all the way through the final post. The OP in that thread discovered that he was backing up a lot more data than he thought he was. He also found the data was mostly pre-compressed, so that what really mattered was the native capacity and speed. Second, the OP in that thread also found that the tape library was never cleaning its heads—so he was getting un-recoverable errors after only a fraction of a particular tape was used. Your "backup server" machine is quite old; are you sure whoever was responsible for it before didn't just cable-up a new tape library without finding out how to set up head cleaning? That's one reason why Nigel Smith asked the make/model question. See pages 50-52 of the Retrospect Mac 16 User's Guide for instructions on how to set up cleaning for libraries and drives. Third, you write "a manual file transfer of the same source is utilizing the 1Gbit network card". That sounds as if there might be more than one network card on either your "backup server" and/or your SMB-attached source machine—which brings up another set of questions. After you've looked into those questions, I would suggest you phone U. S. Retrospect Technical Support at (925) 476-1030; the people on these Forums are just volunteers like me‬. If your organization installed Retrospect Mac 16 within the past 30-45 days, you are entitled to free personalized support. Because it sounds as if your native language is not English, and because you posted so early in the morning even compared to New York time, it seems that you may be located in Europe. I've heard that European Retrospect Tech Support is handled by a contractor, whose personnel don't know that much about Retrospect (probably especially about Retrospect Mac). May I suggest you put your Location in your Forums profile?
  6. 1 point
    We are working closely with Apple and are testing each internal build as they come out. We will put out an official statement when we get closer to the release. I think we have a few more weeks before Apple posts it. Like all Apple systems, we will make sure it works with Retrospect.
  7. 1 point
    Lennart_T, I am shocked that you of all people would say such a thing (see the second and third paragraphs) about the UG. Since I'm sure you're just as tired as I am of dealing with the lack of UG updating, I suggest you write (which I've done) to Rod Harrison—the Chief Technology Officer of Drobo who probably now has some influence at Retrospect "Inc". If you want to impress him with a Swedish-stamped "snail-mail": Drobo Attn.: Mr. Rod Harrison, CTO 1289 Anvilwood Ave. Sunnyvale, CA 94089 USA However, if you are willing to enroll in LinkedIn—which I am not because of delete-finger tiredness—you should be able to get an e-mail address for Harrison there. P.S.: What Lennart_T and I said about the User's Guide not being updated is still valid; Nigel Smith's post below goes beyond what the UG says.
  8. 1 point
    Replying months later to Lennart_T's post, I finally (never mind why!) got around to doing a grooming operation. It was a success. Here is the selector I used in the groom job: Note that the S-1 ... folder never should have been backed up. The System Volume folder was explicit.y excluded in my universal "Always Exclude" selector. Just in case the System Volume exclusion didn't work, I also excluded files matching pattern 32{* and *{380* that are either 12 GB or 50 GB in size. Before the groom operation I did a Find Files operation on the Media dataset, to identify files and folder to groom out. AFter the groom operation, I did another Find Files operation to confirm that all those files were in fact groomed out, except for an S-1* folder inside the $RecycleBin, which should never have been backed up. (But I'll clean that up.) The groom operation recovered 345 GB and 15479 files. After I get some more experience with this grooming selector, I will incorporate it into the backup script. x509
  9. 1 point
    launchd still thinks it should load InstantScan, even if you've turned it off. Try the following in Terminal to stop launchd from trying to load retroisa now, and turn if off for the future: sudo launchctl unload /Library/LaunchDaemons/com.retrospect.retroisa.plist sudo defaults write /Library/LaunchDaemons/com.retrospect.retroisa Disabled -bool true Then check to see if it's worked: sudo launchctl list | grep -i retro ...and, with any luck, you'll see just retroclient and updater listed and not retroisa. How are you choosing those folders -- are they "Favo(u)rites", or are you using rules?
  10. 1 point
    Lennart, I can't thank you enough for this seemingly simple suggestion. Once I changed the dataset preferences to storage optimized grooming, I got this result: All the 50 GB files are gone, and so are all the folders in $Recycle Bin. Your suggestions together have enabled me to recover over 1 TB of wasted storage. x509
  11. 1 point
    Thanks a million Lennart. This worked - Recycled Disk and things are now backing up again!!!! 🙂 Not sure how I got the first one to back up without doing this, or why I wasnʻt told how to do this when I was told the disks need recycling. Iʻll keep a better eye on them now and do some grooming before they get so bad. Words canʻt express the gratitude I feel for your help from the other side of the world, when a company just down the road canʻt help me!!! Cheers and thanks bigtime!!!!
  12. 1 point
    More news after some more testing and waiting for instant scan to catch up. The CPU usage of RetrospectInstantScan seems to be in the low single digits percentage every time I look at them. That's amazing. It used to be above a 100% of a core when it didn't actually work. I have a backup running right now on this machine (iMac 2014 i7) and while copying files, RetrospectClient uses less than 10% CPU in Activity monitor (up to 30% in iStat Menus, though). I've seen it peak to around 60-70% before, but maybe that was before the index was properly built (even though I suspect the index has nothing to do with speed during upload, but who knows). If, in fact, there is an index (see below). The scanning period has not gotten faster than in the tests I did earlier, so I'm unsure if there's actually an index from instant scan. I suspect there isn't one. When looking in /Library/Application Support/Retrospect/RtrISAExec.dir, there's nothing there and I think that's where the index data is supposed to be. There is, however, a retroISA_log.utx file modified at the latest two days ago, with a size of 9.6 MB. Inside, the last entries are from March 5, so I think it stopped updating when I installed the 16.0 client. This leads me to think instant scan is no more, but that full scan has been made so much more effective that it doesn't matter much. Or, maybe the instant scan is saving data elsewhere. Why there's still an instant scan daemon mystifies me, though. Unless it's the old daemon they forgot to stop and delete. Another great bonus: there's a new feature in "sources", namely "automatic update" of the client, which seems to work, at least it updated one of the machines for me. That will be a huge relief, since it means we won't have to run around updating machines, or fiddle with the remote update thing, which I always found obnoxious. It seems to just do it on its own. Latest logs for the two machines, "after8" is a 2013 Macbook Air over wifi (with around 150 Mb/s) and "razr" is the 2014 i7 iMac on wired Gb. All backups to a Synology 1517+. Backup server is a 2019 Mac Mini i7. When looking at the log for the Macbook Air, you'll see it slower than the iMac, but a bit faster than it was before. It's not as fast as I'd like it to be, but it's within the range of acceptable. Arq runs for 13-15 minutes on the same machine, but that's without validation. Arq is also set to only backup the home folder, while Retrospect is set to backup the entire disk (with some exceptions). Now, interestingly, on the iMac, Arq is really slow at times, taking more than two hours to do a backup of the home folder in some cases and 20 minutes in other cases. I really don't know why. So right now, Retrospect rules on the fast machine, while Arq rules on the slower laptop. In conclusion: I think, for the first time, I can set MacOS machines to hourly proactive backups without completely hogging the machines (maybe 2 hour intervals would be more reasonable). The performance now is on par with Arq, and probably close to what can be done on the platform. Arq is still somewhat quicker, but that is maybe at least in part because it defers validation to a separate and more infrequent session, while Retrospect does it every time (if set to verify). But Arq also has slowdowns that I don't know the reason for. Remains the question why "Instant Scan" is still a setting in the client. Weird. Another side note: it looks as if backups have started working for sleeping machines, albeit very slowly. But I haven't looked into that systematically. + Normal backup using Razr at 2019-03-09, 12:52:07 (Activity Thread 1) 2019-03-09 12:52:08: Finished scanning backup set data files To Backup Set Razr... - 2019-03-09 12:52:07: Copying Macintosh HD on razr 2019-03-09 13:04:02: Found: 3797143 files, 864033 folders, 596.3 GB 2019-03-09 13:04:52: Finished matching 2019-03-09 13:08:23: Selector "Martin's machines" was used to select 3 681 955 files out of 3 797 143. 2019-03-09 13:08:46: Copying: 2406 files (2.5 GB) and 0 hard links 2019-03-09 13:11:20: Building Snapshot... 2019-03-09 13:11:20: Checking 864 033 folders for ACLs or extended attributes 2019-03-09 13:14:22: Finished copying 84 113 folders with ACLs or extended attributes 2019-03-09 13:14:35: Copying Snapshot: 2 files (1.2 GB) 2019-03-09 13:15:14: Snapshot stored, 1.2 GB 2019-03-09 13:15:14: Comparing Macintosh HD on razr *File "Macintosh HD/usr/local/var/mongodb/diagnostic.data/metrics.2019-03-05T19-37-16Z-00000": different data size (set: 991 232, vol: 995 328) *File "Macintosh HD/usr/local/var/mongodb/diagnostic.data/metrics.interim": different data size (set: 2 948, vol: 3 345) 2019-03-09 13:17:14: Execution completed successfully Completed: 2 406 files, 2.5 GB Performance: 1 108.6 MB/minute (943.9 copy, 1 354.4 compare) Duration: 00:25:06 (00:20:24 idle/loading/preparing) + Normal backup using After8 at 2019-03-09, 14:04:31 (Activity Thread 1) 2019-03-09 14:04:31: Finished scanning backup set data files To Backup Set After8 Martin... - 2019-03-09 14:04:31: Copying Macintosh HD on after8 (2) 2019-03-09 14:20:40: Found: 2412938 files, 532691 folders, 340.7 GB 2019-03-09 14:20:59: Finished matching 2019-03-09 14:22:12: Selector "Martin's machines" was used to select 2 344 605 files out of 2 412 938. 2019-03-09 14:25:48: Copying: 322 files (715.7 MB) and 0 hard links 2019-03-09 14:27:49: Building Snapshot... 2019-03-09 14:27:49: Checking 532 691 folders for ACLs or extended attributes 2019-03-09 15:01:46: Finished copying 358 898 folders with ACLs or extended attributes 2019-03-09 15:01:54: Copying Snapshot: 2 files (255.3 MB) 2019-03-09 15:02:04: Snapshot stored, 255.3 MB 2019-03-09 15:02:04: Comparing Macintosh HD on after8 (2) *File "Macintosh HD/Applications/Junos Pulse.app/Contents/Plugins/JUNS/accessRecovery.ini": didn't compare *File "Macintosh HD/usr/local/var/postgres/server.log": different data size (set: 123 352 400, vol: 123 367 500) 2019-03-09 15:02:34: Execution completed successfully Completed: 320 files, 712.1 MB, with 52% compression Performance: 662.4 MB/minute (431.5 copy, 1 473.2 compare) Duration: 00:58:03 (00:55:54 idle/loading/preparing)
  13. 1 point
    I installed 16.0 yesterday and am test running it now on my 2013 MacBook Air with MacOS 10.14.3, APFS. There is a process "Retrospectinstantscan" running so that's good news. Retrospect did a full scan of almost 2,200,000 files, over 300 GB, in 20 minutes. No indication that it was using any index from instant scan, but I don't think you can expect that so early after installing it. Will have to see over the next few days if it starts using an index. The preference pane for the Retrospect client does say that Instant Scan is enabled. (But so it did for the 15.6 as well, even when it wasn't.) After 23 minutes, it started copying files. The total running time, including copying of almost 8 GB of files, was an hour and 17 minutes, as compared to over three hours in my September post (see above). The scanning phase went down from about 2.5 hours to 20 minutes. Yay! The client clearly uses less CPU now. It also backs off if something else uses significant CPU, so the machine is running much cooler, without the usual jet engine sounds. Nice. I'll be back in a couple of days to see if Retrospect actually catches up to the performance of competing-product-that-shall-not-be-named-here. It still has a way to go, but it's entirely possible that a few days of indexing can fix that. /Martin + Normal backup using After8 at 2019-03-06, 11:52:18 (Activity Thread 2) 2019-03-06 11:52:19 : Finished scanning backup set data files To Backup Set After8 Martin... - 2019-03-06 11:52:18 : Copying Macintosh HD on after8 (2) 2019-03-06 12:10:57 : Found: 2414406 files, 532724 folders, 337,8 GB 2019-03-06 12:11:14 : Finished matching 2019-03-06 12:12:16 : Selector "Martin's machines" was used to select 2 344 893 files out of 2 414 406. 2019-03-06 12:15:24 : Copying: 4216 files (7,9 GB) and 2 hard links 2019-03-06 12:32:42 : Building Snapshot... 2019-03-06 12:32:44 : Checking 532 724 folders for ACLs or extended attributes 2019-03-06 13:04:33 : Finished copying 359 066 folders with ACLs or extended attributes 2019-03-06 13:04:38 : Copying Snapshot: 2 files (255,4 MB) 2019-03-06 13:04:47 : Snapshot stored, 255,4 MB 2019-03-06 13:04:47 : Comparing Macintosh HD on after8 (2) *File "Macintosh HD/Applications/Junos Pulse.app/Contents/Plugins/JUNS/accessRecovery.ini": didn't compare *File "Macintosh HD/usr/local/var/postgres/server.log": different data size (set: 121 455 000, vol: 121 471 000) 2019-03-06 13:09:21 : Execution completed successfully Completed: 4 217 files, 7,9 GB, with 25% compression Performance: 762,5 MB/minute (483,3 copy, 1 811,4 compare) Duration: 01:17:03 (00:55:45 idle/loading/preparing)
  14. 1 point
    CherylB, I think you misunderstand what I've been saying in this thread. Instant Scan was not supported for APFS volumes as of May 2018, and I don't think that's going to change with Retrospect 16—because the macOS facility it depends on (called FSEvents) wasn't implemented in the same way for APFS as it was for HFS+. But, according to what Retrospect Tech Support told insont per this October 2018 post, "In our next full release of Retrospect the client scan APIs will be completely overhauled .... For local backups you can help speed things up by changing your current api settings .... Client API changes are being worked on and preliminary testing shows them being upwards of 10 times faster than they are currently." IMHO that means non-Instant Scan will be speeded up so much we won't miss Instant Scan. P.S.: I even have hopes that the speed of actual Mac Client data backup will increase with Retrospect 16, because of the changeover to 64-bit APIs. This February 2018 post by dittberner@dbr3.de says he got much faster backup of his Windows server files when he switched from Retrospect Mac to another application; he says further down the thread "The other product is not comparable (much more expensive and other functions)." dittberner@dbr3.de later PM'd me (signing it with his male first name) the name of the other client-server backup application; its developer was founded 18 years after Dantz Development Corp., and its 64-bit application—meaning it won't back up sources booted with anything earlier than OS X 10.8—"is ideal for businesses in the Media and Entertainment industry". IOW, my hypothesis in this February 2018 post in the dittberner@dbr3.de thread seems to be true only if you assume that the client-server application stays with the same set of APIs—rather than change its APIs from 32-bit to 64-bit. P.P.S.: What I predicted seems to have come to pass with the release of Retrospect Mac 16.0 on 5 March 2019. First, the cumulative Release Notes say for Engine "Improved: Scanning faster on APFS volumes" and for Client "Improved Mac: Client scanning faster on APFS volumes". Second, the cumulative Release Notes also say for Client "Alert Mac: EOL notice for Apple Mac OS X 10.3. 10.4, and 10.5 - See details"—where the details are the temporarily-hidden updated version of the Knowledge base article I linked to up-thread which says "Now that the transition to 64-bit macOS file system data structures is complete, Retrospect can no longer support 10.3, 10.4, and 10.5 with the Retrospect 6.3 Client and Retrospect 9.0 Client."
  15. 1 point
    insont and cgtyoder and CherylB, I just discovered, while writing a post discussing this problem (among others) in my authorized Retrospect thread on the Ars Technica Mac forum, that this Knowledge Base article has been temporarily hidden from view (I found it again through my link in a prior post in this thread) while having been updated to refer to Retrospect 16 as of 5 March 2019. I take this as confirmation that the engineers have now completed what must have been a substantial effort in changing a lot of 30-year-old code, which the developer(s) of younger backup applications such as the one insont mentioned have not had to go through. OK, IMHO you've now got a definite date (probably 6 March) when the non-Instant lengthy APFS scan problem will be—at least preliminarily—fixed. If you still want to vent, feel free to do so. If you want instead to file Support Cases, those would provide retroactive justification for Retrospect engineers having made the effort. But IMHO it's time to make good on "I promise to stop complaining once Retrospect shows any sign of at least trying to do something about this."
  16. 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.
  17. 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.
  18. 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
  19. 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.
  20. 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!
  21. 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.
  22. 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.
  23. 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."
  24. 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
  25. 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
×