Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Fredspon

    Duplicate-Copy has stopped working in 15.6

    Thanks very much for your help. After exhaustive testing I finally went for the Transfer Backup Sets option with the following changes in Options:- Verification Off (to speed things up). Executions > Transfers > Copy Snapshot ticked but everything else un-ticked (Especially the Recycle Source Backup as I want the original backups to remain intact as they are recycled by their own scripts after 3 months). Executions > Matching > Match source catalog file un-ticked. With Scheduled Executions set as recycle. Having now run this a few times “live” I am happy that it does exactly what I want it to do. Once again, thanks for your help. I trust this terminology is within your preciseness?
  3. Last week
  4. Both the Recycle backup scripts—the "sacrificial" one and the "real" one—ran OK early this morning to "Media Set Blue". Of the possibilities discussed in the post directly above: I simply pushed the USB3 cable firmly into "G-DRIVE Blue" late yesterday morning; I didn't take special precautions. This wasn't the week for my cleaning lady, but last week—when the scripts also all ran successfully—was. The USB3 cable I used was the same one that was used when I had problems two Saturdays ago. I had upgraded my "backup server" to Retrospect Mac 16.1.0 before last Saturday's run, and I upgraded it to 16.1.1 on Thursday. So possibility 3 is the winner. The Retrospect Inc. engineers must have fixed the Recycle bug in 16.1.0, even though there's no mention of that in the cumulative Release Notes. I can't believe they released 16.0 without having tested Recycle for APFS-built Media Sets; I too would be ashamed! In New York State you're not allowed to call yourself an "engineer" unless you've passed a Professional Engineer exam. That's why, when my employer from 1996 to 1998 gave me that title, I used "programmer" on the section of my resume covering that time period. There is now an exam option in software, but it appears that the "engineers" at Retrospect wouldn't be able to pass it. The term "beta test" was already in wide use when I started programming professionally in 1964, but it appears that Retrospect .0 releases are not previously beta-tested. Don't you think they should be announced as "preview releases", even though that would slow the cash flow to Walnut Creek CA?
  5. PaulMikeC

    Event Handlers

    Hi David, Yes, that thought had actually occured to me too, so during my experiments I did in fact also try removing the name-extension from the event-handler script file, and even in desperation changing the filename to all-lowercase, again to no avail. However, I have in fact solved the issue, and it turned out to be a classic case of "User Error". 😉 Actually, the event-handler script does work fine when named 'RetroEventHandler.sh', and its owner can be left untouched (i.e., it does not have to be changed to 'root'). As a seasoned developer, I’m rather embarassed to have to admit that I was simply looking in the wrong place for the generated log file. I just plain forgot that since the event-handler script is being run as 'root' by the Retrospect Engine, a tilde ('~') character at the start of a pathname (such as the '~/Desktop/eventhandler_log.txt' file defined in the sample script's 'log' function) would of course resolve at run-time to the home directory of the 'root' user , rather than the logged-in user. So, when I looked instead in my boot disk's '/var/root/Desktop/' directory, there indeed was the expected log file, faithfully recording events all along! {EDIT:- My 'root' account happened to have a Desktop folder, since long ago I used to enable the 'root' user (via Directory Utility) and occasionally log in as 'root' to perform some system tasks. On a typical system with the 'root' user disabled, there might be no such 'root' Desktop folder, and so the log file would not actually get created.} For convenience, I’ve now changed the sample script so that the log file is written instead to the logged-in user's Desktop, by first obtaining that user's name via an idiom that I borrowed from a CCC sample pre-flight script, i.e. (in modern Bash syntax): me="$(stat -f '%Su' /dev/console)" and then inserting that 'me' variable's value to form the new log pathname: "/Users/$me/Desktop/eventhandler_log.txt". {EDIT:- Although, it might be easier to just hard-code the log pathname, e.g.: if the same user is always logged-in on the backup server; or, to ensure the log gets written to a fixed location.} Anyway, so sorry to have wasted everyone's time. At the moment, all is well with my tests of the sample event-handler script. Now to tackle implementing the VMs pause / resume functionality that I mentioned earlier. --Paul
  6. DavidHertzberg

    Event Handlers

    cmgsupport and PaulMikeC, This Knowledge Base article says: My eventually-achieved understanding of the first sentence in that quoted passage is that you have to rename your script file to "RetroEventHandler" (without the quotes). It is not sufficient to put the script file in the proper folder per the KB article. Did you do the renaming? Sorry it took me so long to spot that; I looked at the KB article several times. I haven't messed with script files myself, but you could PM saskia. P.S.: In view of what PaulMikeC has written directly below, my apology to him—and presumably to cmgsupport—for suggesting that he missed the KB article statement that the script must be named "RetroEventHandler" . However I strongly recommend that he file a Support Case suggesting that either the KB article or the sample event-handler script(s)—or both—be revised to deal with the fact that the log file isn't generated in a directory where the script creator would expect to find it. Here's why and how to do this.
  7. PaulMikeC

    Event Handlers

    I have this issue too. My Retrospect "backup server" is also my everyday workhorse computer, a Mac Pro (Mid 2012) tower running macOS 10.13.6 'High Sierra'. The backups cover various local source volumes, including several internal, external & (occasionally) network drives, with the destination being a local 5-bay external enclosure, and are scheduled for overnight runs. I recently upgraded my Retrospect Mac Desktop Edition to 15.6.1 (from 13.5, and before that, 9.0, 8.x & 6.x), and was pleasantly surprised to see that this venerable Event Handling feature had been re-introduced in version 14. Some more background info:- For extra insurance & convenience, I also use other services & utilities to make additional types of backups, such as Dropbox online sync, and emergency clone. For instance, I make a nightly bootable clone of just my tower's boot disk via Carbon Copy Cloner (CCC) v5.1. That work is split into two CCC tasks: the first one clones everything except my VirtualBox virtual machines (VMs)' storage files; and, the second one runs much later and clones only those VMs-storage files. That second task uses pre-flight and post-flight scripts to, respectively, pause and resume any running VBox VMs before and after the cloning. I would like to do the latter's equivalent in Retrospect, via event handling. At the moment, I’ve simply copied as-is (from the 'Sample SH' subfolder in the Script Hooks download) the 'RetroEventHandler.sh' sample shell-script, into the boot disk's '/Library/Application Support/Retrospect/' folder. Unfortunately however, it seems I cannot get the Retrospect Engine to invoke the shell-script at all. I've tried various approaches, such as changing the file's ownership to 'root', restarting the Engine, and rebooting the tower, but all to no avail. (OTOH, for me too, the shell-script runs fine when manually executed in Terminal, either with appropriate test arguments or via the 'harness.sh' sample wrapper shell-script.) Any assistance would be welcome.
  8. Indi-Tech, First, I think you got a bit too cute with your screenshots. Favorite Folders belong to drives, but you edited-out the parent drive(s)with its/their disclosure triangle—although I think I see the ghost of one at the very top of your topmost "After browsing" screenshot. Also, assuming these are screenshots of the Sources panel, you appear to have re-arranged the columns so that the relevant ones would appear within the width of a Web-browser window. Second, I did a Forums search; the only recent part-of-a-thread that seems relevant starts with this post. Although I've been using Retrospect Mac for 19 out of the last 24 years, I only started using a Favorite Folder about 6 months ago. But that Favorite Folder, with which I've had no trouble, is on a HDD that is locally attached to my "backup server"—whereas you state that that these Favorite Folders are on drive(s) on a "client" machine. Based on what henry-in-florida said in the linked-to post, I'm now going to make a wild-a**ed guess that your problem is somewhat similar to the problems I had for two years with -530 Client Not Found errors—and that these Favorite Folders are the on the first "client" backed up in one or more of your scripts. The short version of my cure would be to Remove the "client" in Sources and re-Add it with Add Source Directly—not Use Multicast. Before doing this you'll have to make sure that the "client" has a fixed IP address on your LAN; after doing this you'll have to re-checkmark that "client" and its Favorite Folders in each of your applicable Scripts, dragging the "client" in the Summary list pane of each Script in order to get it into the desired backup sequence. I actually got the clue for the cure for my -530 errors from something henry-in-florida wrote. The explanation I eventually came up with for my -530 problems is described in the last quote and the two sentences following it in this post in another thread. The symptoms you describe for your -1101 errors sound similar to my Phase I -530 situation starting in February 2017. My first cure, which worked until November 2017, was to schedule a "sacrificial" script 5 minutes before each "real" backup script, in which only the first "client" was specified and in which the No Files Rule was used. My assumption, based on a suggestion made by a networking expert on the Ars Technica forums, was that my -530 errors were caused by a timing error during startup of the "backup server" Engine—since I was only getting -530 errors if I didn't boot my "client" and "backup server" machines until at least 10 minutes after the "real" script's scheduled start time. After this stopped working in November 2017, I found that I could avoid problems by pausing all scripts, clicking the "backup server" Locate button for my first "client", and then killing the "sacrificial" script. That sounds rather like what you are doing to temporarily avoid -1101 errors. Here is how and why to submit a Support Case. You'll notice that Retrospect Inc. personnel no longer look at the Forums, even the "Retrospect bug reports" one. The Retrospect Inc. engineers did try to find the cause of my -530 bug in May 2018—many months after I submitted a Support Case, but their test version of the Engine and Console didn't fix it. My guess is, as reflected in the first quote in this same post in another thread, is that Use Multicast—which once worked beautifully in Retrospect—is now inhibited by features added to some home networking equipment. The engineers in Walnut Creek CA simply don't have the equipment to reproduce the problem, so they have tried to find it from logs etc. they requested I submit. P.S.: henry-in-florida reported that Adding with Subnet Broadcast worked for him, and he didn't need to Add Source Directly; I tried it briefly last year and it solved my -530 problem. If I'm reading page 79 of the Retrospect Mac 16 User's Guide correctly, Subnet Broadcast doesn't use the now-troubled Multicast feature. Like Use Multicast it allows a backup administrator without IT training to add additional "clients", but only after an IT-trained person—IMHO one with even more knowledge than is required to set up fixed IP addresses—has set up Retrospect. P.P.S.: Indi-Tech, if you're going to us these Forums for help you should check recent threads before starting a new one. twickland reported the same problem with Favorite Folders less than a month ago; for some reason his post didn't show up on my Forums search. He was using Retrospect Mac 16.0.1; does your "Latest version of Retrospect" mean that same version? There is now a 16.1.1.100, BTW.
  9. I do want to reply to that statement. You wrote to David in what I think is a demanding tone "How about starting with the client having (2) NICs and tell us how to get the Retrospect server to connect to a specific client NIC." English is not my native language, so I may have misunderstood. It is a common mistake in these forums to believe they ARE the official support, so I provided you with the fact they are not. And then I wrote that IF you want proper support, this isn't the right place. I wrote that with a good intension.
  10. Nigel, Thank you for doing all these tests. I got dragged into this morass only when scripts that apparently had been working, stopped working. So I was in "break-fix" mode, or just trying to solve the problems of broken scripts, so I could move things along. I appreciate all your testing here. I'm going to download this thread so I can save it in my folder of "informal" Retrospect documentation. x509
  11. No worries. It is odd, we ask for help here on the forums and are told to go ask Retrospect tech support. We mention we are using the software for basic needs and get accused of being condescending and have our legitimacy questioned. Only one person that's responded provided on-topic and useful information that was concise and to the point, without attacking the poster. Curious to hear your thoughts on why a favorite stops being recognized as a favorite when nothing has changed on the client or server. We have a different thread for that on these forums, we won't be continuing that topic here.
  12. Gee, Indi-Tech, and yet you only joined these Forums on 2 May 2019. Maybe your big boss belonged under a different Forums "handle"? Anyway, good of you to condescend to ask for help from us home professionals. I'll deal with your Favorite Folder problem later, to the extent I can, after I've had dinner and watched a movie.
  13. We are an independent technology consulting and support company. Counter to your statement, we are using Retrospect at the low end of the scale. Our own knowledge base of Retrospect support tickets goes back to 1999, 2 years older than the Apple ID of the company founder was established. 😎 The big boss does recollect something about this issue in the deep past and having to, "bind", the IP in a sort of way. Not because of multiple NICs but because of scanning subnets and having issues, or something like that. Our content creation clients with 100TB plus RAID units from Facilis and 45 Drives could never use something like Retrospect and have files backed up in time. At least, not based off our tests. We use Retrospect for office operations and for home professionals, small businesses with smaller files. You know, like it's the 1990s again. 😎 We recently had a working Retrospect backup setup mysteriously forget the favorites that were set, preventing the backup from working until the favorites were re-established. No change to the setup was made before the malfunction occurred. Not the kind of reliability we can use with our bread-and-butter cliental. And exactly the kind of behavior Retrospect has always exhibited. It's a good product but seems to have been stuck in time in some aspects.
  14. DavidHertzberg

    PSA: Wikipedia article on Retrospect going away in current form

    I spoke by phone with the head of North America Retrospect Sales earlier this afternoon. He said there are no immediate plans for instituting a charge for the Linux client. I told you so (last quote). He also said that further enhancements to Shared Scripts in the Web-based Management Console are now scheduled for September 2019.
  15. Engineering came to my rescue! It looks like this is fixed in Server version 16.1.1.301 and newer (still in internal testing, as of May 23rd, 2019). A server upgrade it therefore required if you intend on using Retrospect on FreeBSD 11.2+ or FreeBSD 12.0+.
  16. Indi-Tech, Retrospect Inc. could have, in fact, put a sentence or two about "ipsave" in the User's Guide. However a search of the cumulative Release Notes shows this feature was added in September 2014 to Retrospect Mac, and in March 2015 to Retrospect Windows. It therefore ran afoul of the User's Guide policy described in this post in another thread (which is not the only place I have complained about it). But Google shows you're a consultant (or someone has stolen your "handle" and logo), so you'll have to develop an encyclopedic mastery of the Knowledge Base articles to justify your charging the big bucks—which is why I think Retrospect Product Management intentionally adopted this "disappearing documentation" policy as part of its "go big or go home" strategy. lwhitten complained about the connection not showing in this post I linked to above. He/she was using "a trial of [Mac] v14", and you're using Mac version 16, so Nigel Smith must be somehow hitting the sweet spot in Retrospect versions—or there's another explanation. As for the speed of backup over a LAN, dittberner@dbr3.de complained about that for nearly 2 years before switching to another client-server backup application. I came up with a hypothesis here, but my hope—expressed a couple of posts down in that thread—that things would improve with version 16 has not been realized. My average speed in Recycle backups over my home LAN is around 600MB/min; my hypothesis might explain why ChronoSync—which you're probably using in Synchronize mode—is faster.
  17. I've not seen it in the manual but, to be fair, dual active NICs on a client isn't common and they can't document *everything*. Searching the KB for "bind" gets me that linked page as second hit -- although you have to be techie enough to know the term "bind" in relation to NICs and IPs... You don't always have to remove and re-add the client -- depends on how it was added in the first place. But it won't hurt to do so unless you are trying to preserve an easily-followed backup history (and, usually, you do this kind of shenanigans because you can't get any backup to begin a history with!). Connection not showing might be a client-version thing -- certainly works for me in e.g. 15.6.0 As to speed -- unencrypted will be faster than encrypted, fewer large files will be faster than a lot of smaller ones, and so on. Try your own tests and see where the bottleneck is, watch the network usage, CPU %s, and disk I/O rates at both ends, etc. And when you say encryption are you talking encrypted communications, encrypted backup set, or both? (IIRC, Chronosync offers encrypted comms but not the backup itself, instead recommending you use an encrypted disk if you want that sort of thing. But it's been a while...)
  18. Thanks Nigel, that did the trick! Is this in the manual, I don't see it? What to watch for when applying this method: 1. You'll need to remove and re-add the client. 2. The client will show that it is not connected to the network, when it actually is. We have confirmed that the proper NIC is now being used. Short test so speeds are low, or is it encryption, we're using the most basic version? (We rarely get more than 40MB/s with Retrospect when the same setup gets 115MB/s with Chronosync). Now there's all this great troubleshooting info for this topic in the forum where it is searchable! Indi-Tech appreciates the suggestions to "call tech support" and "read the manual", those are great tips for folks who know very little about technology in general.
  19. I've had a working setup that stopped recognizing the favorites I set. I had to manually "browse" each favorite to make Retrospect honor them again. Nothing occurred to the client or server that should have caused this. No updates, crashes––nothing. Latest version of Retrospect, client and server. Mojave 10.14.4 on the client and latest El Cap on the server. Before browsing. After browsing.
  20. Earlier
  21. As you can see from the color-named progression ("three cheers for the Red, White, and Blue") of my Media Sets in the OP, this morning I was scheduled to do my Saturday Recycle backup to "Media Set White"—whose "1-Media Set White" Member is on portable HDD "G-DRIVE White". Since the Retrospect Agent Reply in the post directly above this evinces a certain skepticism about whether my portable HDDs have been properly cabled to my Mac Pro "backup server" when I switched them, after I had yesterday un-cabled "G-DRIVE Red" (to take it to my bank safe deposit box) and cabled "G-DRIVE White" I ran a "sacrificial" script with No Media Action backing up my MacBook Pro's SSD to "1-Media Set White". This ran OK in 4 minutes. I then scheduled a repeat of the same "sacrificial" script to run 5 minutes before the "sacrificial" script with Recycle backing up to "1-Media Set White" early this morning. All three scripts ran OK in succession early this morning backing up to "1-Media Set White" : the No Media Action "sacrificial" script backing up my MBP , followed by the Recycle "sacrificial" script backing up my MBP, followed by the Recycle "real" script backing up my 4 drives—starting with my MBP's SSD—and a Favorite Folder. I have to admit I was disappointed with missing the opportunity to demonstrate my bug-proving prowess to Retrospect Tech Support. I can think of only 3 possibilities for why the Saturday scripts ran OK this morning: My "G-DRIVE"'s cables had previously been jiggled loose by me or my cleaning lady on previous Fridays, but not yesterday. This seems unlikely, because I'm pretty careful and because my cleaning lady only comes on alternate Fridays. One of my two "backup server" USB3 cables, which are swapped into use every Friday morning, is defective. This seems unlikely, both because the OP shows failures on four successive Saturdays and because the same two cables worked fine connecting "G-DRIVE"' portable HDDs on Sundays through Fridays. On Friday morning I upgraded to Retrospect Mac 16.1 from 16.0. Whoever wrote the Retrospect Agent Reply in the post directly above this made that upgrade suggestion; maybe he/she knew knew something about an undocumented bug fix involving Recycle and APFS. I'll test again next Saturday morning.
  22. I had a similar error back in 2014, but it was an unrelated issue. The platform is CentOS 7, but with FreeBSD kernel (FreeBSD 11.1 and older versions didn't experience this issue, but the current 11.2 and 12.0 kernels report the lack of xattr information differently). Basically, the FreeBSD kernel doesn't allow the Linux-based Retrospect client to read extended attributes / xattr of files, and so Retrospect refuses to back up any of those files. I don't need extended attributes, I just need the files backed up! The Retrospect Client is logging this for every file encountered: fetFileSpec: ExtAttrGetData() failed with error 61 When tracing system calls on retropds.23, I see this: linux_llistxattr() ERR#-61 'Attribute not found' Basically, as expected, it can't get the extended attributes. The Retrospect Server logs this differently, though: can't read, error -1114 (unexpected end of file) None of the files are changing in size, so there is no "unexpected end of file". Retrospect has full read/write access on the drive (obviously, since it is what places "retropds.23" there). It looks like the Retrospect Server is interpreting the message from Retrospect Client incorrectly! I've tried reporting the problem to Support on the Retrospect website, but since I'm running it on an "unsupported configuration" (that's worked fine for the past 6+ years), they won't even consider fixing the bug. Does anyone know of a way to get Retrospect to ignore xattr information? Or to get the Server to NOT skip files?
  23. Nigel Smith

    Selector doesn't work for only 1 Backup Script

    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!
  24. Nigel Smith

    Selector doesn't work for only 1 Backup Script

    I'm mainly going by (possibly wrong) logic and (possibly incorrect) Retrospect instructions... Windows Explorer and Windows Open/Save dialogs have a "current working directory" and "default working drive" (the C drive) -- for example, in an Explorer window address bar you can use full paths to go to a directory ("C:\Logs") but you can also use relative paths ("..\" will take you up one level from the currently shown directory). If you have a directory called "Data" on both C and D drives, typing "\Data" from any location on your system will always take you to C:\Data and never to D:\Data because there's an implicit "C:" before any path starting with "\". Retrospect Client (assuming you aren't defining volumes/favourites) runs at the "machine" level -- it can "see" all drives so, to reference a particular one, you must state which. I can do no better than quote (again) the tip from Retrospect's "Windows Path" filter dialog: Paths for FAT/NTFS volumes start with a drive letter and use backslashes (\) as separators, as in "C:\Data\". That might, perhaps, be clearer if it was written as: Retrospect path filters for FAT/NTFS volumes... Drive letters aren't exposed on networked systems because the "server" doesn't present them. In a UNC path, e.g. \\MyServer\FirstShare\TheFolder, you could consider the share name to be analogous to the local drive letter. It's just differences in the way Windows abstracts and presents absolute paths to directories/files accessible via various services. It's perhaps more obvious on Mac OS X, where every mounted volume including the system disk can be reached via /Volumes/<volume_name>. I'm trying to find a PC client to test against, but I wouldn't be surprised if you got the results you did because "match" requires a prefixed drive letter, while "match pattern" has an implicit "?:" at the start and so will match C:<pattern>, D:<pattern>, etc.
  25. Retrospect 16.1 for Mac and Windows has "New Retrospect Management Console: Pause/Unpause/Stop support", per this post in another Forum. Is that a truly new capability for a Web-connected Retrospect monitoring application (as opposed to the LAN-only Retrospect Mac Console), or is it already in Retrospect for iOS? If the capability is already in Retrospect for iOS, please post on what precisely the capability is.
  26. Nigel, Why you say that drive letter will be mandatory? So far it isn't. I'm running Retrospect 15.61. Now that I think about it, the way Windows networking works, Windows Explorer doesn't actually know about drive letters on networked systems. Or, maybe I should say, drive letters on networked systems aren't exposed in Explorer. I sure hope that Retrospect isn't going to screw all this up in a future release. What I do compulsively, you might say, is that I have a uniform usage of drive letters, as I explained in an earlier post, plus the use of Storage Groups. In my DATA storage group, I have the D drives from all systems. About your comment about total lack of consistency in Windows itself, I agree. Compared to the dark old days of DOS, Windows has enforced a lot of uniformity in the interface, even though there are many annoying inconsistencies. There is no question that Apple does a better job in the interface area. However, for my iPhone/iPad, Apple makes these strange changes from one iOS release to the next, and I'm forced to do Google searches. x509
  27. DavidHertzberg

    PSA: Wikipedia article on Retrospect going away in current form

    Despite the lack of non-Partner-applicable progress (other than "Pause/Unpause/Stop support", which I think may be already in Retrospect for iOS) described in the last paragraph of this post in another Forum, DovidBenAvraham will try to keep the mentions of Shared Scripts here and here in the Wikipedia article. If the promised deployment enhancements aren't in Retrospect 16.5—expected in early September 2019—however, DBA's afraid those mentions are going to have to be removed.
  28. Nigel Smith

    Selector doesn't work for only 1 Backup Script

    I can only comment that, as a Mac user, the total lack of consistency in Windows itself -- never mind other software houses' Windows apps -- gives me the heebie-jeebies... 😉 To be fair, I've just fired up Windows RS Server and checked, and the tip states: Paths for FAT/NTFS volumes start with a drive letter and use backslashes (\) as separators, as in "C:\Data\". ...so it doesn't say it requires a trailing backslash, but does include one in the example. However, you originally said: ...which didn't include the drive letter. That will be mandatory since, unlike your PC's Explorer Address Bar or an app's Open/Save dialog, the Retrospect filter has no concept of "current drive" or "current working directory", so a "match" or "starts with" must begin with drive-letter-colon-backslash. And there's no reason not to include the trading slash, just in case... Still doesn't explain why it suddenly works when you change to "matches pattern" though (I had confused that with "contains", my bad...). If I get time later I'll try a couple of tests.
  1. Load more activity
×