Jump to content
The search index is currently processing. Activity stream results may not be complete.

All Activity

This stream auto-updates

  1. Last week
  2. Yes, it does. https://www.retrospect.com/uk/support/kb/script_hooks
  3. I'm looking for a reliable way to launch an external script when a scheduled backup has completed. Does Retrospect offer such a facility?
  4. Earlier
  5. Nope! Nothing, I figure the installer is crashing but can't find any evidence of that either. I am running the installer from a standard account. Sorry if I'm being a bit harsh and I know this stuff with the current Apple is a real pain. I wanted you to know about my experience so you can avoid loosing other customers over this issue.
  6. Did the Retrospect engine get installed? You can look under System Preferences. You can also check library/application support/Retrospect. You are also welcome to email support@retrospect.com and we can help directly.
  7. I thought I would give Retrospect another try, I used it years ago on an early PPC machine using a tape drive. It was wonderful for years. Saved my data several times. Then sometime after version 6 thing got very unreliable and I moved on. I like a lot of what the current version should be able to do for me and thought I would give it another try. On my Mac Pro (2013) running macOS 10.14.6, the installer, installs a single file /Library/Application Support/Retropect/configs.xml and quits. No app. No login items. No launchd .plists. No console messages. Nothing. I don't have time to debug what should be a VERY reliable app, it is for backups after all. At least failing quick saves me time and I appreciate that at least. I'm sorry to be moving on for good.
  8. Hey David— Thanks for the reply and thoughts. Yes, my connection will handle the transfers just fine. It is a Gigabit fiber connection, and the fastest upload of any of these clients is 100Mbps, with some being more like 10-20Mbps. The way I've set up my installations is just like your home setup— multiple USB disks being rotated offsite weekly. Unfortunately, since I can't be everywhere each week, and since that method relies too much on human interaction and the disk sets behaving themselves, that's why I'm wanting to do a sort of "disk-to-disk-to-cloud" arrangement, but really to my own server, not exactly the overused-word "cloud". As for monitoring, I am monitoring and constantly coordinating w/ customer sites, but I'd rather do it better and less vulnerable to human error. Perhaps the Copy Backup function would work here... How would that compare to the Cloud set, which would back up to local media and upload to the Amazon or other service (which I would like to emulate and be my own "cloud")? Would I just set up a share and make it a File set that the local one gets copied into? I'll do a little experimenting to see if it might be similar enough to what I'm wanting to work. Does kinda suck that in 4.5 years you haven't gotten a seemingly basic lock functionality that you bug-reported. Not terribly surprising tho... Thx, Fred...in the US 🙂
  9. I don't think dropping of a network connection would be a factor, but if the network device is on DHCP instead of a fixed address, that might cause some confusion.
  10. I'm pretty sure all the settings are correct, for the most part everything runs fine. It acts like no prior setting had been entered. Although it seems to remember the username its just the password that will be missing? I also have the same version of retrospect running on a server at another site and I get the same issue with that too. Would any sort of loss in network connectivity cause it to ask for credentials again?
  11. First thing is to make sure you have the security settings in Retrospect configured correctly. Retrospect has 3 or 4 different places to set the security. https://www.retrospect.com/en/support/kb/configuring_retrospect_7_x_for_use_with_a_nas_device In general, it isn't normal for the NAS settings to be lost for automatic login. When you click the button to update the login info, does it ask you to change existing settings or does it act like no prior setting had been entered?
  12. I have had an issue for a while where the backup scripts in retrospect keep forgetting the automatic login credentials used to get to the network share. Has any one else encountered this, or know how to stop it? It is very frustrating when a backup script fails halfway through because retrospect has decided to forget the credentials. The error in the log is: can't read, error -1116 (can't access network volume). As soon as I put the credentials back the script continues to run. Running retrospect single server. Version This is installed on a Windows 2016 server.
  13. I have upgraded the forum software to the latest version. We will be fixing the SSL certificate also. If you run into any issues, let me know.
  14. fredturner, If your answer to either of the two questions I posed in my immediately-preceding post is "no", you might instead want to consider a couple of suggestions for improving "my usual M.O." described in the first paragraph of your OP. The first suggestion is precisely what I have done for at least the past 5 years (probably 6 years) for my own little home installation. That is to rotate portable HDD destination drives once a week, and to take the previous week's portable HDD to my safe deposit box in my bank branch 2 short blocks away. The bank charges US$95/year for a small safe deposit box. The bank branch is not open 24/7/365, so I have three portable G-DRIVE HDD destination drives instead of two (they're named "G-DRIVE Red", "G-DRIVE White", and "G-DRIVE Blue"; the color part of the names are the ritually-named colors of the American flag I learned as a little kid); the drive I bring home from the bank branch sits just inside my apartment door for a week before being used as a destination again. If you live in Great Britain (which I suspect you do because of the time-of-day you post—but maybe you're a U.S. night-owl), your bank branch may have safe deposit boxes that are accessible 24/7/365 using 2FA. I long-ago decided that having the latest off-site backup of my data lag my on-site daily backup by up to a week is acceptable for my little business, but your customers may feel that's too-lengthy a lag. In any case, the drive swapping that I do at the bank branch could be done by any responsible employee of your customers' businesses—and those businesses probably have an employee go to a bank branch at least once a week for other purposes. The second suggestion is that you monitor your customers' destination drive rotation using the Retrospect Management Console, which is a free feature of every Edition of Retrospect starting with version 18.0. I don't need to do this, because I'm the only employee of my little business and I still remember "three cheers for the Red, White, and Blue". However I should caution you to carefully guard the password (meaning don't store it online) for your Management Console; as Malcolm McLeary pointed out over a year ago in this post in another thread, the Management Console's use of Heroku and its lack of 2FA pose a threat of data theft from your customers.
  15. fredturner, First, can your "beefy internet connection" handle several customers simultaneously copying backups—that were made via Retrospect on your customer's "backup servers"—to your offsite destination? Copying backups would likely be simultaneous because you'd want to schedule the copying when it didn't coincide with the backups being run on those "backup servers"? Unless you can keep both those "backup servers" and your offsite destination available 24/7, that copying period would probably be in the early morning or late afternoon—and I'll assume your customers are in the same time zone as you. Second, are you willing to adapt your OP's "adjusting my usual M.O." to avoid subjecting your customers' backed-up data to ransomware or data theft? Fortunately on 18 August mbennett started a Forums thread about his "way to harden a S******y [my elision—parenthetically explained below—of the well-known brand name] NAS so it can be used with Retrospect to make it ransomware-proof." (Unfortunately that thread's later posts were marred by an argument, begun by me with a gentle expression of concern that higher-ups at StorCentric—which has owned Retrospect "Inc." since 25 June 2019—might delete the thread because S******y NASes are the leading competitor to the Drobo NASes manufactured by another subsidiary of StorCentric.) You should read at least the "Introduction - Why?" section and the first two paragraphs of the "Overall Scheme" section of the .PDF he attached to his OP. If you followed that .PDF, you'd buy a S******y NAS for a few hundred $US and insert at least some members of your "disk shelf array" into it. You'd then follow mbennett's numbered instructions after the second paragraph in "Overall Scheme" to setup that NAS "with one administrative way in, protected by a strong password and two-factor authentication. The NAS will provide a single service, that of an S3 cloud, and will provide no other file storage services." You'd also ensure that each customer's Retrospect "backup server" application be "be password protected with a complex password ...." The .PDF continues "... and locked after 15 minutes of inactivity. You should use File | Lock application if you walk away and leave Retrospect running", but that's a Windows facility—used in the .PDF because mbennett wrote it for Retrospect Windows—that AFAIK has no equivalent on macOS. If your answer to both of those questions is "yes", then IMHO you should "make this less error-prone and more robust" using Copy Backup scripts. Designate the same Activity Thread for each customer's Copy Backup Script that is designated for his Backup script, because (despite my Feature Request in in the April 2017 Support Case #54601) Retrospect doesn't yet have a Copy Lock feature that would pause a Copy Backup run that is overlapped with a Backup run—pausing needed because only the files that are already entered in the Catalog File are copied.
  16. Hey Everybody— Looking for suggestions on adjusting my usual M.O. of how I set up my customers'' Retrospect environments. I have several of these configured at different sites, and I usually use 2 or 3 USB3 hard drives as independent, rotating-offsite sets. This works okay, but I've had some difficulty w/ filling and failing disks and making sure the customers are rotating as they should be. So I'm wanting to make this less error-prone and more robust. The Cloud functionality is kind of what I want to do, but I'd rather use my beefy fiber connection and Mac Pro/EMC disk shelves at my disposal to sort of "roll my own" offsite destination. Is this doable? I've seen reference to such things as Minio, but I'm not versed in that yet. What about a simple AFP volume that can be reached via Internet connection? Or even something using Carbon Copy Cloner? What I'd like to do is implement a larger, faster local backup destination on the existing Retrospect servers that I don't have to make sure is rotated, then mirror those local sets to my server/disk shelf array. Thoughts? Thanks, Fred
  17. iodigitale, If this setup—which wasn't clear to me from your preceding posts—worked with your previous version of Retrospect, then there's a bug in Retrospect Mac 18. What I don't understand is why other installations haven't reported the same problem. Maybe you're among the first to upgrade to Retrospect Mac 18.1.1? Did any of your backup executions work using 18.1.1? P.S.: Further questions about your customers' setups that need to be answered regardless of whether or not you submit a Support Case for a bug: So you're saying each customer has a "backup server" at his/her location? Do you check at the customer sites whether the scripts have run? Do you personally make all hardware and software changes to these "backup servers" and to the "client" machines they back up? Have the OSes running on the "client" and/or "backup server" machines been upgraded? Have network switches at the customer locations been upgraded? What OSes do these machines run?
  18. We have different customers (we are resellers) each one with in different office so different lans. So we have different server installations in different lans. Yesterday we tried to set each client of a single little customer (10 clients) in direct mode (each one has a stati ip on the lan) but we got 519 error in 4 backup executions.
  19. iodigitale, Before following the suggestion in my immediately-preceding post, you should consider another possibility I thought of yesterday. It is possible that there isn't any Retrospect Mac 18 bug, but instead that—in upgrading your installation in which "we have a large amount of clients and a lot of them set in dhcp"—your provisions for Subnet Broadcast access per page 82 of the Retrospect Mac 18 User's Guide were messed up. The reason I think you use that access method is, because "we have a multitenant service with about 10 servers and 200 clients", you have no way of ensuring that names of "client" machines are unique except within a particular "tenant". Therefore you must be distinguishing between "tenants" by putting them in separate subnets based on designated ranges of IP addresses. Subnets are designated in Retrospect Mac by defining them per "Configuring Network Interfaces and Subnets" on page 83 of the User's Guide. You give each subnet an Interface Name, and then define its range via the Subnet Address and Subnet Mask. I don't have any subnets defined on my small home network, but I gather that—per "Adding Retrospect Clients to Sources" on page 69 in the User's Guide—you specify the "client"'s subnet in theleft-hand Sources from Interface pop-up menu and specify Use subnet broadcast in the right-hand pop-up menu (not mentioned in the UG—another example of deficient Retrospect documentation). The way to test whether this is the problem is For each of the "client" machines that gets a -519 error, if you select it in the Sources panel of the Retrospect Console and click the Refresh button at the top of the panel, does the dialog show that machine? If not, then your subnet designations must have gotten messed up. Talk to your IT people and fix them, instead of submitting a Support Case. If the dialog does show that machine, OTOH, there's another possibility that doesn't involve a Retrospect Mac 18 bug. That's if you have more than one Retrospect "backup server" running scripts. Your Console may now be be running scripts on a "backup server" for which some sources in the script are not defined.
  20. iodigitale, I intended to add one more suggestion (before the disclaimer) to my preceding post in this thread, but my Web cache for these Forums became corrupted and—by the time I cleared it (following the direction of a Filipino 😲 Retrospect Support person) —I needed to get to the bank and then to the post office before they closed. The suggestion is that you create a Support Case for a bug; here's how to do that (since I wrote that linked-to post, Retrospect 18 was released with mandatory ASM, so you've paid for personal assistance). Here are some facts: Retrospect 18 was released on 25 May, 2.5 months behind the customary first-week-in-March schedule. Another thread of mine—which was locked by the head of R.T.S. because of my "insulting members of the staff with these kinds of comments"—described 18.0-related errors on the Retrospect website that were not fixed until 14 July (nearly 3 weeks after 18.0 was released) following my Support Case #79825. Fully-updated versions of the version 18 User's Guides were also not put on the Retrospect website until 14 July. Here's a post by another administrator reporting a bug in a previously-working feature when he upgraded Retrospect Mac 17.5 to 18.0. Here's a post by you reporting a bug in Retrospect Mac, which is a bug-fix release to the bug-fix release a week earlier. My inescapable conclusion from these facts is that there has been a distinct lack of coordination and thorough alpha-testing in Release 18.x so far. I think your "We have different customers in different offices" and "we have a large amount of clients and a lot of them set in dhcp" means many of your "client" machines are in fact defined with the the Subnet Broadcast access method (per page 82 of the Retrospect Mac 18 User's Guide), and that release has messed that up. Here's are questions you need to explicitly answer in your Support Case—and to any R.T.S. person you phone: What major version of Retrospect Mac was your installation using before you upgraded to Retrospect Mac 18? Are the -519 errors exclusively for "client" machines defined with Subnet Broadcast access? If so, can you redefine one of these "client" machines with Add Source Directly and see if you still get a -519 error backing up that "client"? For one of the "client" machines that gets a -519 error, if you select it in the Sources panel of the Retrospect Console and click the Refresh button at the top of the panel, does the dialog show that machine? Are any of your scripts using features that are new or improved in Retrospect 18.0 through 18.1.1 (blue or green tabs in the cumulative Release Notes for those releases)? If not, would you be willing to demand a downgrade to your preceding release—with a consequent refund (the prospect of having to give a refund tends to concentrate a salesperson's mind wonderfully—encouraging rapid action on the part of R.T.S.)? And please post your answers to those same questions in this thread.
  21. Thanks David. Nothing changed when I upgraded to Retrospect Mac 18. We have different customers in different offices (we are resellers and manage our clients backup). I'll try to downgrade because the problem is huge... too many clients with no backup. I tryed to remove and add again 2 clients directly... but it’s not acceptable for us reconfigure all clients and scripts… we have a large amount of clients and a lot of them set in dhcp... at this time we have 3 working days spent and cannot charge our customers 😞
  22. Thanks David. Nothing changed when I upgraded to Retrospect Mac 18. We have different customers in different offices (we are resellers and manage our clients backup). I'll try to downgrade because the problem is huge... too many clients with no backup. I tryed to remove and add again 2 clients directly... but it’s not acceptable for us reconfigure all clients and scripts… we have a large amount of clients and a lot of them set in dhcp... at this time we have 3 working days spent and cannot charge our customers 😞
  23. iodigitale, First I must ask, in the immortal words of Nigel Smith, "what else changed?" when you upgraded your installation to Retrospect Mac 18. Did you also upgrade to any "improved" networking hardware—because a forced upgrade in early 2017 to an "improved" Ethernet switch gave me -530 errors for a "client" ? I must also ask if your "clients in different locations" are defined with the Subnet Broadcast access method (per page 82 of the Retrospect Mac 18 User's Guide)—because the permanent fix for my -530 errors was re-defining my "clients" with Add Source Directly (also per page 82)—which unfortunately might be a pain in the a*s for your "multitenant service"? Second, I suggest that you consider downgrading your "backup servers" to, based on my guess that the hurried (1 week after) release of might not have been thoroughly tested for network communications other than for the one ProactiveAI bug it fixed. If that doesn't solve your problem, consider downgrading your "backup servers" to—for which you'll have to get a license from Retrospect Sales. (Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here. Any apparent aspersions I cast are meant to apply to the widest applicable group of Retrospect "Inc." employees, not to an individual employee.)
  24. After the upgrade to Retrospect 18 for the Mac I get a lot of error -519 (network communication failed) not only in proactive backups but also normal backups. We get this error from a lot of clients in different locations (we have a multitenant service with about 10 servers and 200 clients). The version we have installed is
  25. Would the Retrospect Product Manager be J.G.Heithcock or Brian Dunagan? Or somebody higher up in StorCentric? Whoever he/she is, I'm glad this thread is still un-deleted and un-locked. Sorry if my pessimism about that disturbed mbennett. On 8/20/2021 at 1:00 AM, mbennett said: I just went through my Contents since 1/1/2021, and here's a tally of my "non-responsive" responses—one category for each thread in which I posted: Procedural suggestions derived from Retrospect documentation: 7 Spammer confrontations (I also reported the spam posts—which were deleted by R.T.S.): 2 Retrospect documentation citations that didn't require procedural suggestions: 7 Retrospect version upgrade suggestions: 6 Retrospect feature request suggestions: 2 Hardware suitability guesses: 1 Procedural suggestions going beyond Retrospect documentation: 8 Retrospect bug identifications with suggestions to file a Support Case : 7 macOS bug identifications (in old version, for administrator information): 1 To answer mbennett's question I quoted, I'm here because—for at least the last 4 years—nobody from Retrospect Tech Support has been routinely posting such responses to Forums threads (presumably because of R. T. S. being short of staff). For most of the threads, the responses I've posted have been sufficient. For the remainder—ones where my OS knowledge or Retrospect experience weren't sufficient—my responses have been supplemented primarily by responses from two British administrators and a Swedish administrator. But—unlike me—those people aren't retired, so their time is limited and they're happy to let me handle the easier responses. mbennett used to do some Forums responding, but—excepting this thread—he has to handle Retrospect-related problems when he can charge his customers for assistance time (from 1964–69 I used to do that for defense and NASA contractors running project scheduling and costing apps at the "IBM mainframe" computer service bureaus where I worked). 😎
  26. xavierbt, Sorry, but if I'm correct this may cost you some money. The cumulative Retrospect Mac Release Notes show, for both 😮 17.5.2 and 18.0, "Console: Fixed issue where Full Disk Access alert was incorrectly displayed when certain custom options were set (#9169)". I'd check with Retrospect (European?) Tech Support before upgrading to version 18, because from the cumulative Release Notes that still seems IMHO to be "a work in progress". The "when certain custom options are set" part of the release note raises questions because, as you say in the OP, "All clients have basically the same software because are cloned and don't have significant differences between them." So that's a puzzler.
  27. Hi, I'm running Retrospect server with 12 Retrospect clients All, server and clients, are running MacOS 10.14.6 All clients have Full Disk Access set in preferences for "Retrospect Client.app" and for "RetrospectInstantScan.app" Instant San is disable for all clients. Usually I can backup firs time all clients, but the next incremental back can fail with an error message regarding Full Disk Access problems in some clients. "Retrospect has detected it is not listed under "Full Disk Access" on the backup source system and cannot access all user data to create a complete backup. Please follow our step-by-step guide: https://www.retrospect.com/kb/macos_full_disk_access." The curious thing is that Retrospect was able to backup the client one day before but next day it can't and perhaps the next one it can backup all client data, so you don't get consistent backups. This happens with some clients. Other clients backups consistently without errors all days. With error prone clients, I have uninstalled Retrospect client, installed again and add "Retrospect Client.app", "RetrospectInstantScan.app" to Full Disk Access again, but with the same result: Retrospect can't backup this client consistently. All clients have AFPS formatted disk, all are verified with Disk Utility and are reported as OK. All clients have basically the same software because are cloned and don't have significant differences between them. Not sure if the problem is with Retrospect or with MacOS 10.14.6 Any advice will be wellcome.
  1. Load more activity
  • Create New...