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
    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?
  4. 1 point
    By default, Retrospect Client will bind to the first available active IP address. In a dual-NIC setup (e.g. network card and wireless in a laptop) that "first available" can vary. So you'll need to tell the client which IP to bind to -- see this page for details. Obviously, only works for static IPs. Luckily it sounds like that's what you are using. That might be enough to get you going. Otherwise, could you re-post the problem but refer to machines as "clients" for the ones you want to back up and "server" for the one doing the RS backup? Like David, I'm getting a bit confused as to what's what!
  5. 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
  6. 1 point
    David, I had to laugh when I read your suggestion. One of the HARDEST MOUNTAINS YOU WILL EVER CLIMB is to try to convince the management of a small software company to hire a good tech writer to create and maintain their documentation. They see this as a straight money losing proposition. I've tried with different companies over the years, and if there is a convincing argument I've yet to find it. They never think the subsequent decrease in support costs and increase in customer satisfaction will make up the difference. As with most companies, Retrospect's manuals fall into the category of "informative but not instructional". They tell you what the program can do, but not how to use the program to achieve the results you want. It's better than nothing, and you've got to appreciate the volume of the docs, but it's sometimes a treasure hunt to find what you're actually looking for. It is quite expensive to do it right. If you want to see somebody who does it right, and is much bigger than Retrospect, take a look at Fortinet. Just Google "Fortinet Cookbooks" and get on the Fortinet Youtube channel. It's phenomenal. Mark
  7. 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!!!!
  8. 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)
  9. 1 point
    Just ran a backup on a 2014 iMac with wired Gb network (the Macbook Air is on wifi), and things are decidedly looking more useable than before Retrospect 16. The scanning took just 2 minutes 11 minutes or so and the entire process 20 minutes. Retrospect is back in the race now. I still can't make out if it's using instant scan or not, but with this speed it must be. /Martin + Normal backup using Razr at 2019-03-06, 18:19:20 (Activity Thread 1) 2019-03-06 18:19:20: Finished scanning backup set data files To Backup Set Razr... - 2019-03-06 18:19:20: Copying Macintosh HD on razr 2019-03-06 18:30:18: Found: 3796060 files, 863974 folders, 596.4 GB 2019-03-06 18:30:50: Finished matching 2019-03-06 18:32:18: Selector "Martin's machines" was used to select 3 681 740 files out of 3 796 060. 2019-03-06 18:32:30: Copying: 2330 files (3.9 GB) and 0 hard links 2019-03-06 18:35:25: Building Snapshot... 2019-03-06 18:35:25: Checking 863 974 folders for ACLs or extended attributes 2019-03-06 18:36:42: Finished copying 83 900 folders with ACLs or extended attributes 2019-03-06 18:36:55: Copying Snapshot: 2 files (1.2 GB) 2019-03-06 18:37:28: Snapshot stored, 1.2 GB 2019-03-06 18:37:28: Comparing Macintosh HD on razr *File "Macintosh HD/Users/mw/Pictures/Photos Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-shm": didn't compare *File "Macintosh HD/Users/mw/Pictures/Photos Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-wal": different data size (set: 32 992, vol: 45 352) *File "Macintosh HD/usr/local/var/mongodb/diagnostic.data/metrics.2019-03-05T19-37-16Z-00000": different data size (set: 360 448, vol: 368 640) *File "Macintosh HD/usr/local/var/mongodb/diagnostic.data/metrics.interim": different data size (set: 3 457, vol: 2 913) 2019-03-06 18:39:34: Execution completed successfully Completed: 2 330 files, 3.9 GB Performance: 1 595 MB/minute (1 332.2 copy, 2 003.9 compare) Duration: 00:20:13 (00:15:14 idle/loading/preparing)
  10. 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)
  11. 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."
  12. 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."
  13. 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.
  14. 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.
  15. 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
  16. 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.
  17. 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.
  18. 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!
  19. 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.
  20. 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.
  21. 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."
  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. 0 points
    rfajman and others, As to ProactiveAI, you have to read the Knowledge Base article I linked to in my preceding post in conjunction with pages 236-251 in the Retrospect Windows 15 User's Guide. The "AI" was added to the end of "Proactive" to signify the adoption of a new decision-tree algorithm for determining the priorities of "client" backups. IMHO It really doesn't constitute artificial intelligence, unless you count the use of linear regression along with a decision tree as rising to that level. OTOH it's evidently better than the preceding algorithm, on which Dantz/EMC's patent seems to have expired in 2016. The fact that you have to go through this instructional mess is yet another example of the IMHO gross stupidity/laziness of a policy adopted by Retrospect Inc.'s august Documentation Committee in 2015. Prior to that year, Retrospect Inc.'s policy was to describe new features of a major version fairly comprehensively in the "What's New" chapter of the UG for that version. The descriptions in that "What's New" chapter would then, for the next version of the UG, be incorporated in appropriate sections of follow-on chapters in the UG—allowing the"What's New" chapter to be overwritten with fairly comprehensive descriptions of the next set of new features. Starting in 2015 the august Documentation Committee adopted a policy of only overwriting the "What's New" chapter without incorporating its previous contents in follow-on chapters. The Committee relied instead on individual engineers to create KB articles containing the previous feature descriptions. For some new features, such as the one facilitating moving Members of Backup/Media Sets to larger disks, the engineer(s) couldn't be bothered to create a short KB article. So how to use those features, especially for Retrospect Windows, is locked forever in the minds of Retrospect Inc. engineers—and maybe harassed Retrospect Tech Support people. Starting in March 2018 the "What's New" chapter in the UGs became merely marketing blurbs, useless for administrators trying to learn how to use new features. I created Support Case #59820, stating the problem plainly on 20 March 2018. I was told by a senior Tech Support engineer that, sometime this side of the indefinite future, Retrospect Inc. intends to do a comprehensive rewrite of the UGs. I think it's time for us administrator users to each inscribe the letters "TUIT" on a round piece of paper, and snail-mail it to : Retrospect, Inc. Attn.: August Documentation Committee 1547 Palos Verdes Mall, Suite 155 Walnut Creek, CA 94597 United States That will communicate to the August Documentation Committee a notice that now is the time to "get around to it".
×