Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Nigel Smith, I wrote in this up-thread post "I was proceeding to your next issue while writing this post, but I had to take an hour off and you've meanwhile beaten me to it." But IMHO your subsequent posts have not so far really "beaten me to it". That "next issue"—really three "ifs" in one long sentence, covered in this more-upthread post, was: My opinion on the first two "ifs" is based on what I wrote in the last two sentences of the first paragraph and entire second paragraph of this even-more-upthread post. It is that Remote Backup, designed for machines that don't have predictable Internet addresses, will backup any machine having the exact "backup server" Tag "Remote Backup Clients" that "reaches out" to the "backup server" with a public key that is in the "backup server"'s Remote Clients table. So long as such a "client" machine remains truly Remote, a Proactive AI script specifying "Remote Backup Clients" will back up any machine having that Tag—even if your home router's IP changes or you take the laptop to a different location. My opinion on the third "if" is based on my personal experience that Retrospect Mac 16.6's Piton Name Service will override Add Source Directly, so long as the Computer Name matches what is defined for that Source on the "backup server". So if you now now take the laptop in to work and plug in to the non-subnetted portion of your LAN, Retrospect will back it up—assuming its Computer Name is unique in the non-subnetted portion of your LAN and has not changed from when a Proactive script added it to Sources. If you've done further testing on these "ifs", please post your results.
  3. Last week
  4. Hey DavidHertzberg, Thanks, that would have been perfect; sadly our version came from the stone age; (windows v10) Where that is probably not possible yet; we will have to look to upgrade I assume Thanks ! // edit I found a way; if i open them up 1 by 1 i can right click and "print" this way, i can print the structure to pdf. cheers!
  5. svennd, You don't say which variant of Retrospect you are using, but since you use the term "snapshot"—which has been banned for the Retrospect Mac GUI since version 8 (Engine messages still use the term, since the Engine is common code underneath the variant GUIs)—I'll assume it's Retrospect Windows. Pages 8–9 of the Retrospect Windows 17 User's Guide are a minimal description of how to generate the new Restore Preflight report for a snapshot. What it generates is a CSV, which presumably you have to import into a spreadsheet program (whatever that is; I assume one candidate is Microsoft Excel) in order to read. The front screenshot on page 8 of the Retrospect Mac 17 UG shows how to tell that variant of Retrospect 17 where to save the CSV using a macOS GUI dialog. I assume the corresponding Windows GUI dialog would be similar, but whoever in Retrospect Product Management wrote the "What's New" chapter of the Retrospect Windows 17 UG seems to have felt it was more important to show a screenshot of how to generate the CSV—owing to the crufty old GUI of Retrospect Windows (guess which variant I use 🤣 ).
  6. is it possible to completely unfolded export a snapshot export directory list ? If i go to snapshots for a user, I can see his directory : - dir - dir - dir but I would like to see : - dir ---- dir under -------- dir under - dir - dir --- dir ------- dir I wrote export but a screenshot would be fine also; Even better would be if we could copy that directory structure somewhere. Not sure that is possible ? I want the full directory tree, but not all of those where backed up. (in the latest) Thanks!
  7. DavidHertzberg

    Retrospect Management Console

    Nigel Smith and anybody else, Here's a March 2020 article titled "How to Set up an iPhone VPN"; if you don't want to use a VPN app, look at the section "Manually Configure a VPN on iOS". I don't have any kind of "smart phone"—much less an iPhone—so I haven't tested out the procedure. Malcolm McLeary and anybody else, I had written an e-mail to the head of North America Sales, asking whether my temporary solution to the security hole in the Retrospect Management Console—that you had identified—would work. When I didn't get a reply I followed up with a phone call voice mail, to which he replied late Friday afternoon. He said he'd just come out of a meeting, and mentioned that there's now a supply chain problem for Drobo devices (I think we can guess where those are manufactured 🙂). I don't know how that'll affect the StorCentric-dictated priorities mentioned in the last sentence of this post in another thread; i.e. whether it'll permit diverting engineers to fixing the Retrospect Management Console problems discussed in this thread sooner or not. I didn't want to interrogate the head of North America Sales on whether this Retrospect Management Console answer will work; after all, I'd be asking a salesperson whether there's an additional feature available at no charge—without paying for the Management Console Add-on. So after a couple of days I tried it this morning; it seemed to work using a Retrospect Mac 16.6 "backup server"—but see the P.S. on Sales "helpfully" giving me the Add-On license. On my MacBook Pro "client" I executed the "Account Creation" procedure in this document, using my regular e-mail password and the Forums password it defaulted to. When I got the confirmation e-mail I clicked the Confirm Account link and assiged an organization name. I copied the UUID from the dialog onto a piece of paper, walked 45 feet to my Mac Pro "backup server", booted it and immediately paused all Retrospect activities, and followed the "System Setup" procedure's "Retrospect Backup" sub-section in the document—copying the UUID from the piece of paper. I then un-paused all activities, went to my MBP's Firefox browser, and opened a tab with the URL https://console.retrospect.com/dashboard?—which inserted the machine= and organization= fields at the end of the URL. I then clicked the name of my "backup server" in the left-hand column, and got a Dashboard delayed behind the actual "backup server" by 2 to 4 minutes. I guess that's the Heroku updating lag—RMC 's price you pay for not having to VPN into each site separately. I can log out the Management Console from my MBP, close the tab, and re-open it again with the the same URL—which on my MBP fills in the remaining fields. When I then click the Log In button on the top right of the Web page, entering the e-mail address I used for Account Creation and putting in the password—with no 2FA—gets me to a Dashboard panel. Above the Dashboard are additional buttons for Past Activities, Sources, Sets, and Scripts; clicking one switches to an appropriate panel. However this enables the security flaw Malcolm McLeary has identified—see the P.S. for why. Clicking the Scripts button gives me a panel with a New Script button on the top right; clicking that appears to enable me to create a new Proactive Script 🙄. Therefore I intend to disable Management Console on my Mac Pro's Retrospect Preferences, since I have no need for it so long as I can walk 45 feet. P.S.: A possible reason the security flaw is still present is explained in an e-mail I got yesterday afternoon from another Retrospect Inc. salesperson just as I was leaving for an appointment. It said he had given me a Retrospect Management Console Add-On license for free, apparently because my posting activity on these Forums—for which I'm not paid—is considered helpful for Sales. The e-mail apologized because the Add-On license might not have worked; when I returned home I hurriedly phoned back and asked the salesperson to remove the Add-On license, which I had intentionally never asked for. P.P.S.: That Sales e-mail requested I re-sign-up for a Management Console, which I did this afternoon using a different e-mail address. That Management Console had—as I hoped—only a functioning Dashboard the first time I logged-in, but later logins give it access to Scripts and the ability to create a new flawed script. (Possibly the "gift" Management Console Add-On license applies to my "backup server", not the RMC itself; I'll check by phone later today.) AFAICT I don’t have Remote Granular Management or Shared Scripts, which are Add-On features. P.P.P.S: This morning's No Media Action backup of my MacBook Pro—while running and afterward—displayed Past Activities, Sources, Sets, and Scripts on RMC using my newer e-mail address—so the "backup server" security flaw still exists for the RMC . That means my temporary solution doesn't work, so Malcolm McLeary should pursue a permanent solution—2FA or "Backup Sets Must Be Encrypted" preference. BTW naming of backed-up drives in segments on RMC Backup Report and Backups bar chart panes is erroneous, as it is on my Retrospect Mac 16.6 Dashboard panel—with different errors.
  8. Nigel Smith, Notice that I rewrote my two preceding posts in this thread, here and here, to explain what I think is going on with Remote Backup in light of your tests. Everybody, I had written an e-mail to the head of North America Sales, asking whether my temporary solution to the security hole in the Retrospect Management Console that Malcolm McLeary had identified would work. When I didn't get a reply I followed up with a phone call voice mail, to which he replied late Friday afternoon. He said he had just come out of a meeting, and mentioned that there is now a supply chain problem for Drobo devices (I think we can guess where those are manufactured). I don't know how that will affect the StorCentric-dictated priorities mentioned in the last sentence of my immediately-above post; i.e. whether it will allow the engineers to divert to fixing the Retrospect Mac problems discussed in this thread sooner or not.
  9. Earlier
  10. DavidHertzberg

    Tag selection whack-a-mole

    eeolson, I'm not one of your followers; I merely looked at your past posts in your Forums profile by clicking on your name. The underlying code for the "backup server" Engines of Retrospect Windows and Retrospect Mac has been the same since late 2009. The "stagnation" between Retrospect Windows 7.7 and 17 was only in the UI, which has been kept the same partly because of the bad reputation for reliability and temporary hardware compatibility restrictions of Retrospect Mac 8 (which was developed in a hurry after EMC reversed an end-of-lifing of the product)—but mostly because of a Windows limitation described in the second paragraph of the Wikipedia article section here. Retrospect Mac 9 fixed the problems in Retrospect Mac 8; this immediately-preceding WP article section describes its enhancements. Starting with the next WP article section is a version-by-version listing of the enhancements in the "backup server" between Retrospect Mac 10 and Retrospect Mac 14, which correspond to those of Retrospect Windows 8 through Retrospect Windows 12. Retrospect 15 (whose Windows version number was bumped from 13, in order to restore version number parity with Retrospect Mac 15) enhancements included e-mail protection, what is now called ProactiveAI, Remote Backup, data hooks, and the beta of the Management Console. Retrospect 16 enhancements included Storage Groups, deployment tools, and the features of the Management Console Add-On. Retrospect 17 enhancements include Automated Onboarding for the Management Console, speeded-up ProactiveAI, and Restore Preflight. In short, versions of Retrospect Mac beyond 8 exceed (green flags) just "patches that are packaged and sold as expensive upgrades". After using Retrospect Mac from 1995 to 2010—ending with Retrospect Mac 6, I started again using Retrospect Mac 12 in 2015—following a five-year hiatus caused by the death from old age of my ancient "backup server" machine (whose PowerPC hardware was incompatible with Retrospect Mac 8). As I said in the second paragraph of my post directly below your OP, I'm still using Retrospect Mac 16.6—because I don't need the new features or bug fixes so far introduced with Retrospect Mac 17. Nobody else on these Forums has reported a bug with the stickyness of Tag checkmarks. Some administrators—including me starting with Retrospect Mac 14—have had problems with -530 errors on client access, but I discovered a couple of years ago that I could eliminate those errors by using the “Add Source Directly” button at the bottom of the Sources->Add dialog (item 6 on page 74 of the Retrospect Mac 17 User's Guide). In response to my Support Case, Retrospect Tech Support has agreed that my submitted logs show a problem—caused IMHO by macOS/hardware changes that affect the Piton Name Service's use of Multicast—which the engineers haven't yet been able to isolate. What you describe for for your Proactive scripts sounds like a problem that was supposed to be fixed by the "ProactiveAI" enhancement in Retrospect 15. Precisely what version of Retrospect Mac are you using—not just for the Clients but for the "backup server"? Maybe your "backup server" is still running Retrospect Mac 12 (click "About Retrospect" in the "Retrospect" menu), because you're convinced you don't need to spend money upgrading. 😒
  11. Thanks David! Great to see I have followers. I've used Retrospect on about 30-40 servers in office environments since the days of TEAC cassette tapes. I've run in on over a dozen windows servers and more Mac servers. I always liked the Windows version better, but I've move all of my Windows clients to Veeam because it seems infinitely more reliable and mature. I still run Retrospect in mac environments, and I keep my clients current on their maintenance, so all of them run the latest shipping version. Believe me, when a update comes out, I install it and hope things get better. In my opinion, the switch from Retrospect 6 to Retrospect 8 was a very large step down in reliability, and I believe they are still issuing "patches" for that. But they are patches that are packaged and sold as expensive upgrades. I work with a team of IT support professionals, and we all feel similarly about Retrospect - it needs constant babysitting, the UI is erratic, adding and working with client computers in the server is glacially slow, clients often stop communicating with the server, the server engine often needs restarting, or the host OS rebooted. But hey, I restored a client's data yesterday, so I'm glad this was one week that Retrospect did not stop working between my weekly check-ins. So, what version are you using?
  12. (The disclaimer at the top of this post in another thread applies here.) Nigel Smith (the Forums ate my previous version of this post early this morning), When I said "sloppily written section of a KB article", it was with full awareness that from 2015–2020 the "official" documentation for Retrospect features was written by engineers as a series of Knowledge Base articles—some of which were in March 2020 copied as Appendixes to the User's Guides, IMHO partly because Retrospect Inc. could no longer afford to hire a tech writer to update the UGs. That full awareness extends to the notorious decades-long inadequacies of the engineers' alpha-testing that extends all the way back to the Dantz days (read the next page of Ars Technica 2016 Retrospect thread posts following this one). So I'm pretty sure that the engineer who wrote the KB article on Remote Backup alpha-tested his own kludgy feature by taking a machine that had already been backed up as one of a "backup server"'s Sources and having it connect remotely to a Proactive script. Sloppy test + doc. The foundation of the kludginess you've now encountered starts with the Automatically Add Clients option. Maybe it used "the industry standard method of onboarding work computers that are to be used remotely" as of 2009, but it's a potential kludge. Quoting from page 72 of the Retrospect Mac 17 UG: But the kludginess comes into full flower with the Remote Backup feature, which IMHO was developed as part of the 2018 "go big or go home" strategy. You've now discovered that it introduced a contradiction. Quoting from the " Server-Side Retrospect Engine Configuration" section of the 2018 KB article: In your testing, the running Proactive script created an ugly Add of a new Source before the running Engine was able to Automatically Add. Lucky you, 🤣 you get to write the Support Case—copying your posts above—because I can't repeat those experiments in my diminutive installation. If I were Emmanuel Macron, I'd award you the Croix de Guerre; if I were J. G. Heithcock, I'd be disturbed you found this contradiction. But the priorities of StorCentric—which wants a Drobo "backup server" (that post's 2nd long paragraph)—now over-rule those of Heithcock; don't expect the contradiction to be fixed this year.😎
  13. It would appear that "sloppily written" really means "Goes against my belief that..." ...so the official documentation stating that you can switch seamlessly between local and remote backups -- including an example using the industry standard method of onboarding work computers that are to be used remotely -- and the way Retrospect has been shown to work in practice are, quite simply, wrong. They must be wrong, because you say they are. So there really is no point continuing...
  14. You might want to edit your post following the results of my last test in the post before, where an "AlwaysRemote" client was indeed added without user intervention to the server and can therefore be seen in the server's Sources list -- what I'm calling a "client record" because that's where you set things like client options and tags.
  15. I don't think you read my preceding post thoroughly enough, Nigel Smith; perhaps I wrote it without enough concrete examples. Your scheme would work for RecentlyRemote "client" machines, but not for AlwaysRemote "client" machines. That's because there's no "client record" on the "backup server" for an AlwaysRemote "client" machine. It seems the Automatically Add Clients option will cause a Proactive script to create one, but not one that you like. Here's a couple of contrived concrete examples: Let's first say that I am a PhD Student at the academic institution where you are the backup administrator, and I initially do my research using an on-campus machine that was set up for me. You Added my machine to Sources, so it has a "client record" on the "backup server". Then the COVID-19 pandemic arrives, and you tell me to take my machine and go back to my home somewhere off-campus—where it will have an Internet address that's not on the institution's LAN. That makes my machine a RecentlyRemote "client" which you are still going to backup on your "backup server". Now let's instead say that I have been granted some kind of External PhD Student status, which says that I can do all my research remotely without ever having set foot on your campus. (Maybe I was originally admitted as a regular PhD Student, but I now can't be allowed in Great Britain because I come from the pandemic-ridden U. S..) I'm to use my personal machine for research, and you want to back up the research centrally, but you can't Add it to Sources because there's no way to connect it to the LAN. So there's no "client record" for my machine on the "backup server"—unless a Proactive script creates one per Automatically Add Clients; that makes it an AlwaysRemote "client". This is the original use case for Remote Backup, which IMHO was introduced in 2018 to back up the machines of hired-locally sales or support people; those people would receive all their institutional training via books or Internet, and would obtain their own machines in whatever country they were stationed—such as Sally in Shanghai or Albert in Adelaide. Presumably Retrospect Product Management determined that there were enough customers with such AlwaysRemote staff members that it was worth developing the original Remote Backup feature. Therefore I propose a scheme that will keep the AlwaysRemote capability while adding a RecentlyRemote capability, but introducing a "user-defined matching attribute" that will allow a "member of the class" of Remote tags to be used to specify whether a RecentlyRemote or AlwaysRemote machine should be backed up by a particular Proactive script. I was proceeding to your next issue while writing this post, but I had to take an hour off and you've meanwhile beaten me to it. As for where you said I was wrong, you quoted a sloppily-written section of a KB article. If you read that section carefully, you'll see that its "for instance" assumes that the "client" was first given "the initial full backup on the local network". That would make it by my definition a RecentlyRemote machine, not an AlwaysRemote machine.
  16. And the bad news is -- it does... "But Nige," I hear you say, "surely that's a good thing, allowing us to onboard Remote clients without making them come to the office?" I don't think so, because Remote Clients are automatically added: ...without the "Automatically Added Clients" tag, so there's no easy way to find them ...with the "Remote Backup Clients" tag, which means they will be automatically added to all Remote-enabled Proactive scripts ...with the client's backup "Options" defaulting to "All Volumes", so external drives etc will also be included I let things run and, without any intervention on my part, the new client started backing up via the first available Remotely-enabled script. Edit to add: I didn't notice this last night, but it appears that the client was added with the interface "Default/Direct IP", in contrast to the clients automatically added from the server's network which were "Default/Subnet". I don't know what this means if my home router's IP changes or I take the laptop to a different location (will the server consider it to now be on the "wrong" IP and refuse to back it up?) or if I know take it into work and plug in to the network (will the server not subnet-scan for the client, since it is "DirectIP"?). End edit Given the above I'd suggest everyone think really carefully before enabling both "Automatically add.." and "Remote Client Backups" unless they retain control of client installation (eg over a remote-control Zoom session) -- especially since I've yet to find out what happens if you have a duplicate client name (the next test, which I'm struggling to work out how to do).
  17. Nigel Smith

    No Proactive scripts running

    Jon, did you ever get anywhere with this? Just had a silly thought -- if the problem was that your Proactive scripts were running but none of your remote clients were getting backed up, make sure you didn't install Retrospect client on your server (see the very last point in the Remote Backup KB article).
  18. The trite answer is "Easily!". Note that tags are not applied to "client machines" -- they never have been, and the "Remote Backups Clients" tag is no different. They are applied to the "client record" on the server. They effectively say "allow incoming calls from this client" (when in the client record) and "allow incoming calls to this script" (when used in the script's Source). So I'm proposing a "class" of Remote tags, each instance having a user-defined attribute -- they all say "allow incoming" but finesse it with "and direct them to scripts with the matching attribute". Perhaps it is easier to think of them the other way round -- they would behave exactly the same as all other tags and, additionally, allow remote access. Are you sure? 😉 You've actually raised the next issue I want to test -- does automatic onboarding work with Remote clients? I haven't bothered with that yet, because our use of Favourites mandates local addition, but now I've time to scrub a machine and start a client from scratch again. Sorry David, but that's just plain wrong. From the KB article: "Clients can seamlessly switch between network backup on a local network to remote backup over the internet. You do not need to set up the remote backup initially. You can transition to it and back again" -- true as far back as Nov 2018.
  19. Briefly stepping away from the "David & Nigel Show" and back to OP's original question -- Fred, I hope you're still with us! At the moment, no. But rebuilding is parallelised, and once any client is complete it can be backed up again even while others are rebuilding. But I don't fancy doing multi-terabyte rebuilds for just one corrupt catalog either, and I can't (yet!) find a way of using backed up catalogs and the Repair function to shorten the process. I suspect that the "gold standard" work-around would be to: Remove "broken" client from original set's Source list (either machine entry or tags) Create a new Storage Group media set Move the folder of the backup files of the "failed" client to the new Storage Group, putting it in the same place in the SG hierarchy as it was Rebuild the new Storage Group media set Check you can restore from the rebuilt set Delete backup files and client catalog from original set Do a Transfer of the now-rebuilt backups from the new set to the original Check that original set's version of client is now working again Re-add client to original set's Source list Delete new Storage group data and catalogs If haven't tested this, but it seems like it should work. Try yourself on test data before using in anger! This shortcut, however, I have tried: Remove "broken" client from original set's Source list (either machine entry or tags) Create a new Storage Group media set Copy the folder of the backup files of the "failed" client to the new Storage Group, putting it in the same place in the SG hierarchy as it was Rebuild the new Storage Group media set Check you can restore from the rebuilt set Replace original catalog with the rebuilt one Check that original set's version of client is now working again Re-add client to original set's Source list Delete new Storage group data and catalogs And it works! But I'd urge you to give it a thorough thrashing in test mode before entrusting any of your precious data to this method... Both methods will do want we want -- rebuild just one client catalog out of many. The first requires an extra Transfer operation, the second the extra disk space for the data copy. neither comes with any official stamp of approval 🙂 Try them both and see what you think.
  20. I don't see how your scheme could apply different "Remote Backup Clients"-derived tags to different "client" machines, and later have a Proactive script recognize which tag should be associated with a particular "client" sending a "back me up" message to the "backup server", without initially having had that "client" machine on the same LAN as the "backup server". You'd want this to happen so that a particular Proactive script could say "my sources include some Remote Backup Clients, but not this one, so I won't even scan it". You pointed out up-thread that a Rule won't avoid scan + snapshot time. The reason your scheme would need to initially have each potentially-Remote "client" machine on the "backup server"'s LAN is that Retrospect provides no other way of defining a machine as a source. That Sources->Add would at a minimum have to capture the machine's Computer Name, because the machine's later "back me up" message would have to include the sender's Computer Name to allow a Proactive script to determine whether its list of "Remote Backup Clients"-derived tags applied to the sender. The "client" machine's name would have to be unique on that LAN, although it might only have to be unique to a subnet of the LAN if the machine's Retrospect Client stored—and later transmitted with the Computer Name—the subnet name. It's also not possible to define a Favorite Folder—or an added drive—on a machine that isn't connected to the LAN. (I've checked this out by shutting down the "client" on which I've drafted this post.) However you can add or remove a tag for a defined source. You were able to define Favorite Folders—on their existing drives—for your own laptops because you'd brought them in and connected them to your "backup server"'s LAN. However I'd advise you against having PhDs/PostDocs bring in their machines for temporary LAN attachment, because that's now a good way 🙄 for you—or them—to catch COVID-19. Taking a broader view, there are two different use cases for Remote Backup. As designed by Retrospect Product Management in 2018, the use case was for AlwaysRemote (my term) machines, those that would never be put on the same LAN as the "backup server". Product Management assumed that an installation would only have a few such machines, so they probably didn't worry too much that their phantom-Tag "Remote Backup Clients" would oblige a Proactive script whose sources included that phantom-Tag to back up all machines sending the "back me up" message. However Alanna's OP in another thread was the first on these Forums to discuss the RecentlyRemote (my term) use case, in which she evidently planned to back up—as split up among different Proactive scripts—many machines that had been recently moved for Work From Home in the same time zone. As I've said in the preceding three paragraphs, that won't work with your scheme unless the RecentlyRemote machines are first brought or sent to the "backup server"'s LAN location—and unless Proactive scripts and the Retrospect Client Installer are both enhanced to store Computer Names to be included in the "back me up" messages. I think my suffix scheme would be preferable, because it handles both the AlwaysRemote and RecentlyRemote use cases. It wouldn't allow you to define Favorite Folders for AlwaysRemote machines, but neither would your scheme per two paragraphs up. Most of the code for my proposed suffix-changing utility already exists, because it's included in the version of the Retrospect Client Installer described for Management Console Automatic Onboarding.
  21. The videos don't show that (although that's how the clients were installed, registered, and Favourites defined) as you can see, the tag changes were done to a machine that couldn't be contacted by the server (because it was at home and turned off!). The videos show that the list of machines ProactiveAI is going to try to back up is based solely on server-set tags, without reference to or need of contact with the client itself. So it's pretty obvious that I'm not forgetting that tags don't appear on client machines. Yes, but it isn't a huge leap to have multiple Remote tags that can be assigned server-side to both script and client and that message interpreted by the RS engine as "back me up with any matching Proactive script; legitimised because I have this public key stored in my pubkey.dat." It's almost the same solution as you propose but with three small and one big difference. The small ones are "no faffing with the client when changes need to be made", things are obvious to the Admin (no digging for secret strings), and the fact that adding Remote clients to scripts is exactly the same as adding any other tagged client (consistency is good). The big one is that you could apply multiple Remote tags to the client record so they can be backed up with multiple scripts (doable with multiple secret strings but nowhere near as easy or obvious to the Admin). I think they've assumed you'd have be a real idiot to want more than one remote-enabled script -- they've got me down to a T 🙂 From my playing, it alternates between the two available scripts -- but that's probably because there's no contention due to low client numbers and use of Storage Groups on both. I would hope it follows the "usual rules" -- if more than one destination is available for backup, pick the least-recently (yuck! Pardon my English, but I can't think of a better way of putting it) used.
  22. SMB is using the Windows short name because the name isn't being encoded for compatibility by the OS X SMB daemon -- and that's because the data is being put on the server by AFP clients. The permanent fix to this is: Lock out all your users On Mac Pro, mount the share using "afp://IP_address/sharename" Still on the Pro, mount the share again using "smb://IP_address/sharename" Move the troublesome data from the AFP-share window to the SMB-share window Turn off AFP on the Synology and force your users to SMB from now on, and maybe look at how to turn off signing in SMB config Step 4's the tricky bit -- set the windows to different views so you can keep track of which is which and decide how you are going to manage the transfer wrt clashing names, deletion of "AFP versions" when complete, etc. I'd probably do one folder at a time, copy that into a folder at the same level named "Transfer", delete the original, move the contents of "Transfer" to where the original was. (All the above just tested and confirmed with Catalina, an up-to-date Synolgy, a folder on the Mac named as yours with contents created by echo "Here's some text in a file" | tee "Animation (smaller)?"{0..9}.txt > /dev/null ...with an additional "testFile.txt" file to make sure "normal" files were also OK, and then copied to the Syn using AFP.) Or you could insist that everyone stays using, and only using, AFP, and pray it remains supported for as long as you need it... I may have given you a bum steer -- it looks like (for AFP and SMB at least) RS is using the system APIs to mount shares. If I turn the RS engine off and restart, my server shows no network mounts in /Volumes. If I turn on the RS engine the shares connected to via RS's Sources then appear in /Volumes, and if I add another share there it appears in /Volumes too. RS adds them as root/wheel while mounting via the Finder (non-root account) adds them as admin/staff -- entirely reasonable. Both work as expected from above -- SMB-mounted shows AFP-added files by short name and SMB-added files by full name complete with non-standard characters. AFP-mounted shows both versions with their full names. Both mount methods back up all files without error, so it doesn't look like the filenames are causing your errors in and of themselves. I still think you are losing connection with the server for some (unrelated to filenames) reason. As said before, RS backup-in-progress is much more sensitive to temporary disconnects than "normal" file sharing is, so it may be that your other users simply don't notice when it happens. It sounds like you have some time for testing -- if so I'd suggest you go back to scratch. Static IP on just one Syn interface, static on Mac Pro, direct cable connection between the two, does the problem still occur? If not, slowly add complexity until it does.
  23. I gotcha. Okay, so I'm getting "Share_Name' for Name, and the server's IP address under Machine. So it looks like OS-level mount. Side note: I get 'Unknown' for the shares in the OS column. Here's an example folder name that gets mangled: AFP - /Animations (Do we need to rerender smaller?)/ SMB - /AVFA3C~5/ I'm not entirely certain that the mangling is the reason for the -1101 errors though. EDIT: In the logs, the only files that were tagged as missing were in some folder with a mangled name (we have many). FWIW.
  24. Thank you for your YouTube videos, Nigel Smith; they clarify your "production" use. They show that you first cabled the laptops to the same LAN as your "backup server", and basically followed the procedure from the bottom of page 228 to the top of page 230 in the Retrospect Mac 17 User's Guide. However they show you manually created the Tag "Remote Backup Clients" and used it to identify specific Favorite Folders on your laptops, which explains why those Favorite Folder names appear in your (topmost) screenshot of the Proactive Activity list up-thread. That's what had confused me. What you're forgetting is that Tags are only defined on a "backup server"; they don't appear on the "client" machines that they group together. As I've said up-thread, a truly remote "client" sends a message to the "backup server" whose IP address is stored in server.txt—displayed as the Public Address of its Client. Apparently the message currently says "back me up with any Proactive script; legitimized because I have this public key stored in my pubkey.dat." Page 228 of the UG doesn't explain how the "backup server" knows which backup to on-demand restore for a particular remote "client". Maybe it does so by the IP address stored by a Proactive script in Sources for a particular Remote Client backup, which would explain "Remote Backup: Fixed issue where remote backup failed if client added by name (#7705)" in the cumulative Release Notes for Retrospect Mac 15.6.1. But a remote "client"'s current IP address could have changed. In any case what's needed is a "unique identifying attribute"—as you say, but one stored in association with the Remote Client that can be combined with the Tag "Remote Backup Clients" to designate which Proactive script is to backup that particular "client" machine. I propose a suffix to the Tag, stored in association with the machine's Remote Client. There should also be a simple Retrospect utility program, which would be run by the possessor of a Remote "client" machine to either establish the suffix or to change it. If you repeated your test after the Retrospect engineers instituted use of the suffix for Remote Backup, you'd have to run the utility program to establish a suffix on each of your two laptops. If the salesperson Albert were moved from Adelaide to Beijing with his existing laptop, as described in the last paragraph of this up-thread post, he'd be told to run the utility program to change the suffix The utility would also be used if the possessor needed to acquire or replace his/her remote "client" machine without returning to headquarters; replacement examples—ripped from the headlines 🤣—would be the Shanghai PSB arresting Sally for subversion and then releasing her without her laptop, or Albert taking his laptop on a trip from Adelaide to Kangaroo Island and having it destroyed in the 2020 bushfires. Whether the suffix should be a group number or a multi-character alphanumeric string is a GUI question, although I think a multi-character alphanumeric string (may be empty) is the most administrator-friendly approach. A Proactive script would have to store the suffixes for its Remote Backup sources.
  25. It'll still show as a share (because it is!) but you should see a difference in the "Name" and "Machine" columns of the Shares list -- a share mounted via the server's OS will show the volume name in "Name" and the server's name in "Machine", a share mounted by RS will show "user@IP_or_FQDN/share" and either IP, FQDN or name.local depending on how you addressed it. We're trying to make sure that if you are using SMB you are doing so via OS X's smbd -- I don't know if RS uses that or its own routines, but I do know that OS X's smbd does lots of trickery to encode/decode funky Mac filenames for use on less supportive SMB shares. Have you got any examples of filenames that are failing? I can try and replicate your problem, albeit using RS17 rather than 16, if you think it might help.
  26. Hey Nigel, Fortunately, it was after midnight when the tornado went through and was only property damage. We fared much better than most of our neighbors, though. I did try mounting the share first, but it still showed as such in the Sources pane. I've been using the IP address for these connections, which doesn't seem to improve my situation. I tried using SMB again, and that seemed to get further into the process, but there are still major issues with name mangling and files not being found after the initial scan. I get the impression that SMB is functioning more robustly than AFP, but until I can resolve the mangling issue it's a non-starter.
  27. As excuses go, that's definitely in the top three! I hope all the important things -- the people! -- were undamaged. Have you tried mounting the share on the Mac (still using AFP) and treating it as a local volume, rather than letting RS do it? Also this thread throws up an interesting suggestion -- use the IP address rather than relying on Bonjour resolution (static IP on the server an advantage, obv).
  28. My testing setup was as close as I could get to our proposed "production" use -- no point in doing otherwise in this case. So... No -- I took the laptops into work, wiped them, got hem on the ethernet, installed RS client, registered them with RS Server and created Favourites. I then took them home. From home I VPNed from my desktop into the work RS Server and set up the test scripts and tags. I then turned on the laptops, got them connected to my home wireless network, and let things happen -- the laptops were at no time connected via VPN. Sidenote: If it was created using port forwarding, the client record "Interface" would necessarily be "Direct IP" and it would be my router's public address that was shown. That's because there's no way (at least that I can find, correct me if I'm wrong) to change from "Direct IP" to "Multicast" or "Subnet Broadcast" if you can't actually contact then select the client using the changed method. Sidenote 2: Apologies for any confusion, but the RS Server I'm testing with is the latest update to v17. "RS_16_Test" is the previous v16 test server which now has the engine turned off so is client-only. I was short on time and so grabbed an available machine -- I really should have thought ahead and renamed it! Again no -- I've shown that the list of clients that Proactive is waiting to access is generated on the fly using the script's Source list, without reference to the clients' locations or availability. And that the Source list is updated, without need to start/stop the script, either periodically or in response to tag changes. You can try this yourself by setting up a new Proactive script using a new tag that hasn't been applied to any clients, start it running, then applying that tag to a client -- after a few moments the client will appear in the ProactiveAI list. And if you can't do that yourself -- here's a video: https://youtu.be/LiZ8b6KZ3OY And inB4 "but Remote Backup Client tags are different": https://youtu.be/4Ok_z2Lrn9A And again no -- though I'm much less certain on this one 😉 -- the ProactiveAI list doesn't contain IP addresses, they're held in the Sources record for the client. I'd guess that Proactive signals the Engine which client is to be backed up and Engine refers to the Sources record for the client to determine connection type etc. I don't know how that works with Remote clients. But it isn't really important to the discussion. Agreed. But... The current kludgey perversion binds all so-tagged scripts to all so-tagged clients. I want to limit that binding so that a client can be bound to one, some, or all scripts as I desire. It can't be beyond the wit of man to have multiple Remote Backup Clients tags, each with an unique identifying attribute, so that matching-tagged scripts bind to matching-tagged clients -- after all, that's exactly how all the other tags work, and there's no messing around with the client installation required for those.
  1. Load more activity
×