Jump to content

Nigel Smith

Members
  • Content count

    78
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by Nigel Smith


  1. ObDisclaimer -- I know little more about Windows than what Mr Google tells me.

    With that out of the way...

    It would be worth checking if any process has that catalog file open (which would make it read-only to RS, hence the "locked" error). Click "Search Windows" in the Taskbar, type in "resmon", then hit <Return> to launch Resource Monitor. In the "Associated Handles" section type ".rbc" in the search box and hit <Return>. Mouse over each path in the "Handle Name" column and see if any refer to your catalog file. (When I do this I get two lines back, one for "explorer.exe" referring to a registry key, the other for "Retrospect.exe" pointing to the currently running backup's catalog).

    You could try increasing the other logging settings (yes, "7" is the max) -- I have *no* idea what you'd be looking for but, if it was me, I'd create a new set, flush the log, do a manual backup of a single folder to that set, save that log and flush, then do a manual backup of that same folder to the borked set, save that log, then compare the two logs to see what was different.

    If nothing shows there then I'd be thinking along the lines of:

    1. David's suggestion of trying the trial version of v16 and seeing if that solved it
    2. Restore previous version of catalog then repairing it to bring it up to date
    3. Retiring the old set (keep it in case you need to restore from it at some time) and starting a new one
    4. If desperate to keep a single running set, archiving the old catalog (just in case...) and starting a "new" set by recataloging your current backup data

  2. Have you got the new drive fitted yet?

    If so (i.e. hardware fault is now out of the equation), I'm thinking you've hit an internal limit on catalog size/contents or member size.

    How big is the "locked" catalog file (in Windows Explorer). In Retrospect's properties for that Backup Set, what's the "Used" space and file count?

    Then copy that locked file of to your C drive, back to G, and "relink" it as you did before to unlock it. Check the above again -- what are the numbers this time?

    If the unlocking trick works, try adding another member and continuing the backups. If everything continues working it was a "member size" limit (Ooo-errr!), probably from a weird coming together of RS, Windows 10, and Synology's volume presentation. If, however, the catalog "locks" again very quickly you may have hit a file-count limit -- you might be able to groom the old catalog and then carry on, but maybe it's time to start a new set.

    Otherwise, it's log time! Towards the bottom of the page from David's link above you'll find instructions on how to access "Secret Preferences" and change the log levels. You can generate a lot of noise with these, so I'd start by leaving everything as is except for winding up "Backup Sets and Catalog Files" to the max. Try another backup and let us know what the Operations Log reports.


  3. 1 hour ago, bookcent said:

    There is knowledge base article here, so 10.5 is what I need

    https://www.retrospect.com/au/support/kb/rebuilding_mac_v6_catalog

    Nice catch! Had forgotten that -- our main v6 backups are Internet Backup Sets, which can't be rebuilt in any recent version. At least you won't have to do the multi-terabyte restores I'm (slowly!) going through 😉

    I know v10.5 will run on OS X 10.6.8 through 10.9, not sure if it'll cope with Yosemite or higher though. Anyone?


  4. 56 minutes ago, pbartoli said:

    Just to be clear, I have only one Retrospect Server running, on the Server Mac.

    Then I'm very surprised that you have something listening on port 22024 on the Console-running Mac. You might want to find out what that is, if only for your own peace of mind.

    Check System Preferences first -- the clean Mac I did the test install on (above) *did* have Retrospect Engine running at the the end of the install process, even though I never asked for it or entered any license info etc, and was listening on 22024 until I turned it off (and unchecked "Launch on System Startup" to be sure it stayed off).

    Otherwise, in Terminal on the Console-running Mac, enter "sudo lsof -iTCP -sTCP:LISTEN -n -P | grep 22024". The first word of the returned line is the reported name of the process, the first number is its Process ID (PID) -- you can use either in Activity Monitor to work out what is going on.

    Again, if it is RS Engine I don't believe it would cause your problem -- but why spend the resources if you don't need it?


  5. On 7/3/2019 at 4:29 AM, x509 said:

    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.

    Very true -- I think this will catch out most people the first time they try it so thanks for the reminder.

    The latest manual does include that information, albeit in the "Disaster Recovery" section. IMHO there should be a big banner announcing that fact in the "Restore" section as well, or at least the "If you have experienced disastrous data loss..." paragraph amended to "If you want to restore your System drive or have experienced disastrous data loss...".


  6. 4 hours ago, bookcent said:

    I have some old AIT-1 and AIT-2 turbo tapes...

    Old? How old? What version of Retrospect were these tape sets created with? It sounds suspiciously like you've got RS v6 sets, which can't be rebuilt in v10 or higher.

    If I'm right (and you want to keep the data), your best option is to find an old Mac on which you can reinstall v6, restore everything to a disk drive, back it up again with the new RS. You'll probably lose snapshots but, if you get the options right, you can retrieve all the data including "versions" of the same file.


  7. 21 hours ago, pbartoli said:

    Nigel, that's not a typo

    That implies that you've also got Retrospect Engine running on the Console Mac. Is that deliberate? If not, try shutting that Engine down and see if the situation improves (I don't believe it should cause a conflict, but the fewer "unnecessary" processes running the better).


  8. 1 hour ago, pbartoli said:

    3. OK Ping works, the console can reach the server. Port 22024 is open on console Mac.

    Hopefully that's a typo. You should be scanning *from* the Console Mac, checking it can see the open Port 22024 on the server Mac.

    I've tried with a "clean" 10.14.4 Mac -- installed RS, checked it works, updated to 10.14.5 and it still works -- so I don't think it's the recent OS update that's the problem.

    Try another machine -- if that works then uninstall/reinstall Console on the problem Mac. I'd also clear the relevant KeyChain password entries (Keychain Access and search for "Retrospect") before the reinstall, though I'm not sure that's necessary (have I borked my settings? I'm finding that *anything*, even *nothing*, in the password field allows me to connect!).

    The only other way I've been able to replicate your never-ending "Connecting..." is by trying to add an IP that doesn't have RS Engine running. RS Console doesn't handle that gracefully -- you very quickly see a "...failed with error 61:Connection refused..." in system.log (launch Console.app, select "system.log", type "retrospect" in the search bar), but the wheels just keep on spinning... So you could try removing all servers from RS Console and quitting it, launching Console.app and setting it up as above, then launching RS Console and adding the server again -- see if the log gives any clues.


  9. 10 hours ago, haggis999 said:

    I'm very grateful for your assistance on this, though I'm not quite sure how copying the catalogue was enough to unlock it.

    Meh -- computers!

    I'm afraid my stock answer in these situations is "Don't know why, don't care why -- it worked, and that's enough for me!".

    Any chance you can increase the capacity on your Synology next? Looks like you're below 10% free space so, depending on how it's formatted, you might be taking a hit to write speeds. Of course, if performance is still OK for your workflow, carry on as you are 😉


  10. To add to David's sage advice:

    Is Retrospect Engine running on the server? Check with Activity Monitor viewing "All processes" to be sure or, in the Terminal, "ps -axww | grep RetrospectEngine".

    Is Engine's port open? In the Terminal, "sudo lsof -iTCP -sTCP:LISTEN -n -P | grep 22024" and you should see a line starting with "Retrospect", showing it listening on port 22024.

    Can your Console Mac reach the server? Use Network Utility to "Ping" 192.168.2.50 or, in Terminal, "ping -c 10 192.168.2.50" (regardless of what IP Scanner tells you, it's worth a double-check). If you can ping the server, is the port visible to your Console Mac? On the Console machine use Network Utility to scan 192.168.2.50, setting both "ports between" fields to "22024" for speed. Or, since we're relaxing with Terminal 😉 , "/System/Library/CoreServices/Applications/Network\ Utility.app/Contents/Resources/stroke 192.168.2.50 22024 22024".

    If the first two tests fail, troubleshoot Retro Engine starting up on the server -- it'll help to know your OS version for that.

    If the first two pass but the last tests fail, check for firewalls or similar network security.

    If they all pass, it might be something like a change of Retrospect Engine password or a problem with the Console install (re-install or try a different machine).

    'Fraid that's all off the top of my head. Let us know how you get on.


  11. On 6/28/2019 at 1:22 PM, haggis999 said:

    It therefore seems odd that chkdsk claims there are zero bad sectors.

    Totally normal. chkdsk reports on "current usable disk", and doesn't include those previously found bad sectors -- they've already been re-allocated (note that it doesn't say that there are no bad sectors but that you have "0 kb in bad sectors" -- not quite the same thing). S.M.A.R.T. works at the hardware level and so also reports those sectors which have previously found to be bad and thus re-allocated.

    Hopefully, the new disk will sort things out. Otherwise the steps you took above indicate that you have read access to the catalog file (could do a restore) but not write access (the repair options you chose require the original catalog to be deleted). You could always try copying the catalog over to your C drive and using it from there. Or you could do a complete rebuild to a new file in a different location.


  12. 13 hours ago, DavidHertzberg said:

    Thank you, Nigel, but DovidBenAvraham already wrote a "Guide to Retrospect for Busy Backup Admins"

    Nah -- long on detail, short on practical examples. For most of the questions about RS (indeed, software in general) the answer are already there or can be inferred from available information, but the questioner can't frame the query to meet a technical writer's expectations.

    Instead of "our software does this using this menu item" (kind of obvious *if* you know the software author's name for the function you require) you could do a more Q&A "operations" based approach -- "You want to back up? -> using a cloud service to store your data; -> using a NAS; -> using an external drive" or similar. A "busy admin" doesn't want to know the technicalities behind block-level backups, he wants to know how to use path filters in the real world.

    But I'm guessing I won't be able to persuade you to write this -- which is a shame.

    Also:

    10 hours ago, DavidHertzberg said:

    My impression from a quick Advanced Search of the Ars Technica Mac Forum is that Drobo storage devices were more popular some years ago than they are now, because of the criticism recounted here in the Wikipedia article on those devices.

    Similar criticisms can be levelled at Synology, QNAP, our Isilon cluster...

    We had some Drobos, and their USP at the time was BeyondRAID's incremental expandability. Unit full of disks but need more space? Pop a disk, install a bigger one, let it rebuild while still having access to your data. Much cheaper, easier, and *much* less downtime than backing up your entire RAID, replacing *all* the disks with higher capacity versions, restoring your data. Struggling grant holders could spend just enough money for this year's data capacity and upgrade when the next year's funding came through.

    But HDs and enclosures were a lot more expensive then, relative capacity increases larger, software-based volume expansion more common, and client (rather than Drobo) performance tended to be the speed bottleneck. Other companies introduced their own ways of adding disks without the hassle of reformatting. Things have changed and, for similar usage, we now tend towards over-provisioned desktop RAID arrays (single machine use) or NASs (multi-user), making sure they are not only full of big disks but can also be expanded across multiple units if required.

    Drobo's models, especially "business", are looking a little long-in-the-tooth now -- I was hoping for more after their merger with Nexsan. And we've always been interested in Nexsan, if only so we could say "I've got to go check the Beast in the Server Room" 🙂 but, unfortunately, the units are too deep for our sealed racks.

    The optimist in me would love to see Drobo's innovation on Nexsan hardware running optimised Retrospect -- an excellent turn-key on-prem backup solution for SMB (even if I wouldn't buy it for here). The pessimist says "Oh God, it's EMC all over again...". The pragmatist thinks that, as long as Retrospect gets some love, I don't care who owns it.

    Time will tell, I guess.


  13. 11 hours ago, haggis999 said:

    Retrospect can sometimes be a very frustrating program...

    I probably should, at this point, mention that the minimum Retrospect version required for updated Windows 10 is v15.6

    I'm always laughed at for making things work well past their sell-by date, so I'm not one to talk 😉 , but be aware that will be the first solution suggested by more official sources...

    That said, "Catalog file is locked" can happen for a bunch of reasons. Start with standard troubleshooting (shut everything down, restart in sequence, verify volumes on both PC and NAS, make sure RS is "up to date" -- you say you have 12, I'd assume 12.1 is a free update, maybe 12.5 as well but I don't follow Windows versions). Make sure you don't have more than one version of RS on your HD (not even in the Trash).

    Once everything is checked, use Task Manager to make sure RS *isn't* running, then launch the app manually. Doing all operations from within the app (no double-clicking catalogs or run files), try running the backup again, checking in Task Manager to make sure a second instance isn't being launched. If there's still a problem what are the *exact* errors recorded in the Operations Log?

    And if there are still problems it would help to know what the NAS is (make, SW version, format and capacity of target volume, etc), what you are backing up (just the "host" PC, or are there other clients?), any other sets using the NAS as a target (including their capacity settings and actual size) -- more info is better.

    Catalogs do get corrupted, so you could go back to a previously backed up version and "rebuild" any recent changes into it and carry on from there -- if you haven't a back up then you could do a complete rebuild from your NAS data, though that could take some time...

    Plenty of things to try, so let's not give up yet!


  14. Why not publish your own? "Hertzberg's Guide to Retrospect for Busy Backup Admins".

    I'd buy that for a dollar!

    I'm actually semi-serious here. You know your stuff and write well. It might be worth a pitch to the Take Control guys (who you may know of from the TidBITS mailing list/magazine). Retrospect got a mention in "Take Control of Backing Up Your Mac", but there's nothing else in any depth.


  15. Is the "Skip this member" box checked (IIRC, RS will automatically check this when you hit the space limit)? Make sure you uncheck it when setting the new size limits.

    How big is the current set member? There are limits, both in Retrospect and in the NAS's file system, and it may be that you are falling foul of one of those.

    Regardless of the above -- why not just add another member in the same place, since it seems you have plenty of free space on the NAS? While most people think of "add member" as being a way to add another real-life disk or volume to a backup set, you can also use it to add another "virtual disk" to the same directory of a NAS-based set. (Useful if you want to off-site -- rather than repeatedly copying a single, ever-growing, multi-terabyte, file you can have multiple smaller files in the set and you only have to copy the most recently changed. Think of each file almost as "virtual tapes".)


  16. On 6/17/2019 at 7:42 PM, zz-pdb said:

    I have a Linux (Ubuntu 18.04 LTS) system that has two network interfaces, and its doing its multicast advertising on the wrong one.

    Retrospect Client binds to the first available interface -- Client queries the OS for active interfaces, OS responds with an array of those available, Client binds to first item in the array. That suggests three possible approaches:

    1. If one interface *always* comes up before the other, re-do your network settings so that one is on the Retrospect subnet. This will stuff up any other software that also only binds to "first available" but you want on the *other* interface
    2. If interface order can vary you'll have to get creative with your machine's startup scripts -- basically you're looking to get the interface you *don't* want Retrospect to use to come up after Retrospect has been initialised. Again, this could stuff up other software
    3. You might be able to do it later by taking down the interface you don't want to use, stopping and starting RetroClient (so "retrocpl --stop" then "rcl start" -- turning the client off and on will not do the job), then restarting the "unwanted" interface.

    Unfortunately the Linux client has nothing equivalent to the "ip" and "ipsave" commands available on Mac and Windows.

    There may be other ways round this, depending on your network setup, but I'm afraid I'm no Linux guru...

     


  17. While it's a good idea to enable Full Disk Access in Mojave to allow Retrospect to back up all the files on a machine, it'll rarely have an impact on external volumes. Privacy mainly acts on parts of the user folders -- ~/Library/Mail, ~/Library/Cookies, etc -- and any Time Machine Backup folders. It generally won't be in play when backing up a mounted NAS volume unless that volume has been set as a TM backup target, *possibly* if you're redirecting User directories to the (non-startup) volume, or something similarly funky.

    In fact, "Error -1101" is almost certainly not a Full Disk Access issue, since that generates an error when scanning -- an error that includes the path to the folder, text to the effect that 'Retrospect has detected it is not listed under "Full Disk Access..."', and a link to the KB article explaining how to fix the problem.

    In both cases above it is most likely a name, permissions or volume integrity problem. But the various flavours of NAS and client implementations of SAMBA/AFP can make this difficult to troubleshoot...


  18. Glad it's sorted -- the rogue attempted startup, anyways.

    That "...localsnapshots"  volume is cruft left over from previous OS's Time Machine -- 10.14 doesn't use it any more. As to why it's being scanned -- you say you're only backing up a couple of directories from the User folder on the system drive. If they are defined as Favourites then nothing else should be scanned (assuming you've tagged them appropriately for your script etc). If you are doing it via Rules, eg. "back up files on this computer if their path matches /Users/..." then Retrospect has to scan every file and folder on the machine looking for matches. That will include other mounted volumes if your tags etc are set that way.

    Needless to say, for fast scan times when you are only backing up a subset of a computer's data, Favourites are your friend.

    Bonus tip 😉 Step away from the Console log! There's ridiculous amounts of guff in there these days, often with multiple updates a second. Step over to the Eclectic Light Company for a primer on using "log show" and how to isolate log items by time period, use predicates to filter by event or program, etc. I haven't tried their Consolation log viewer myself, but you might find it more friendly than using Terminal.


  19. On 6/2/2019 at 7:32 PM, minidomo said:

    Thanks to your reply, I looked up that page reference and disabled Instant Scan on our five clients as well but I'm still seeing this message show up in the macOS Console log (apologies for the confusion).

    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.

     

    On 6/2/2019 at 7:32 PM, minidomo said:

    There are only two folders on Kitchen that I have Retrospect backup at all, and these are in the current user's home folder.

    How are you choosing those folders -- are they "Favo(u)rites", or are you using rules?

    • Like 1

  20. On 5/25/2019 at 8:37 AM, PaulMikeC said:

    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)"

     

    Just a note -- that returns the username of the "current active GUI user" (for want of a better term). So if "backup" logs in it will give "backup", if "admin" then logs in using multiuser switching (i.e. "backup" is still logged in but "admin" is active) it returns "admin" -- and if "admin" logs out (but "backup" is still logged in) it returns "root" because you are at the login window. May not be an issue for you with your setup but it would confuse the hell out of me...

    I tend to hardcode these things -- apparently /var/log is a popular choice for log files 🙂

    On 5/25/2019 at 8:37 AM, PaulMikeC said:

    Anyway, so sorry to have wasted everyone's time.

    I'm glad you did! I've never got Script Hooks to work and had assumed the system was borked. Now you've shown otherwise I'll attack it again. Slack integration, here we come!


  21. 27 minutes ago, Indi-Tech said:

    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.

    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...)


  22. 2 hours ago, Nigel Smith said:

    I'm trying to find a PC client to test against...

    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:

    image.thumb.png.e41b8bc9bc7878f90b661f47c26ef4fd.png

     

    "Windows folder path exactly matches E:\Test_Data" -- no trailing backslash, so nothing is matched:

    image.thumb.png.a06c46374ede7e36c6d954b12cc7c00f.png

     

    "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:

    image.thumb.png.5a094415dcb424a3ab8c1f10b03ed8de.png

     

    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:

    image.thumb.png.d1bb874e6af93c108b776f4d10d096ae.png

     

    "Windows folder path matches pattern \Test_Data\" -- matches Test_Data only on both drives:

    image.thumb.png.6a682de9a04a59330dcf840ece7f10eb.png

     

    "Windows folder path matches pattern E:\Test" -- matches Test_Data and Test_Data2 only on the E drive:

    image.thumb.png.a1f2f21b696bd41822864cdae07d8e77.png

     

    "Windows folder path matches pattern st_Data" -- matches Test_Data and Test_Data2 on both drives:

    image.thumb.png.5dc57d00596b63d22e71a93c3d5442c8.png

     

    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!

    • Like 1
    • Thanks 1

  23. 12 hours ago, x509 said:

    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.

    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.


  24. 20 hours ago, x509 said:

    I can only comment that it's not exactly great software design to vary from standard Windows practice in specifying a path.  There are several different SAVE AS dialogs in Windows, I'm not sure why, but the key point is that none of them require a trailing backslash.

    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:

    On 2/27/2019 at 10:31 PM, x509 said:

    As an example, I have top-level folders 2018 and 2018.  The selector "path matches \2018" does not automatically select files or subfolders to back up.  Change matches to matches pattern and suddenly files in folder 2018 do get backed up, so it seems.

    ...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.

×