Jump to content

Nigel Smith

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Nigel Smith

  1. Can't say I'd noticed that -- but then, I can't remember the last time I used the "overwrite older" option outside of a testing scenario. If you can describe the situation you're finding yourself in I'll see if I can replicate it, and what the results are.
  2. Hell yea -- if it goes wrong at work I may get fired, if it goes wrong at home I'm in in real trouble! The point is that I'd rather it go wrong now, and I know about it, so I can fix it, rather than after a few months of a "self-healing" client trying (and failing) to continue on as normal... Of course, in an ideal world we'd have both! I'm just a bit hot on unintended consequences at the moment since we've just found out that a problem (concurrent-use software licences not being released if a client crashed rather than was quit) that we mitigated (scheduled daily scripted restart of the licensing daemon to free the zombie licences) has come back to bite us (external dept with 2 licences on our server advising their users to launch the software on 2 different machines every day and not quit, so they were running up to 15 concurrent instances rather than 2). While we could have justified a slight over-use if ever audited, such a deliberate breach of the Ts&Cs could have had repercussions -- and indeed it has, since the external dept is now firewalled out to only allow 2 client IPs and their users have to fight for time on those machines rather than use their own.
  3. While I applaud your idea of "self-healing" Retrospect client, David, I can't help but feel it's like slapping a fresh bandage on a suppurating wound every morning -- far better to clean up the infection instead. Otherwise I fear that a relatively minor problem -- "I'm not getting backed up. Hmmm... Better fix that." -- could turn into a major one -- "I've had no alerts -- what do you mean my data hasn't been backed up for a month? My disk just failed!". Restarting a service manually may be a pain, though certainly less painful than a full reboot, but there are often unintended consequences -- and so, IMO, a choice the user should make.
  4. There are two separate issues in this thread -- this "client running but bound to the wrong IP" (turn it off and on again, etc) vs x509's "client off and can't be started" (restart service).
  5. OK so, life in my hands (and knowing a workmate had just arrived at the office, so could press buttons if needed), I connected to the remote VM and logged into Windows. RS Client was running, and I could turn it off and on again. Ctrl-Alt-Del, Task Manager, found "retroclient.exe", "end process". Launched Retrospect Client, which showed Status as "Off", and the "Protected by..." checkbox greyed out. Spinning wheel every time I tried to interact with it. File C:\ProgramData\Retrospect Client\retroclient still present from before. After 5 minutes of "Program not responding", clicked the "Close program" option. Launched Client again, this time "Run as admin", same results. Ended process. Messed around with the retroclient file, still not launching. In Task Manager's "Services" tab, found "Retrospect Client", right-clicked, "Restart service". (Interestingly, that rotated the retroclient[.logn] files and created a new retroclient file.) Launched Client, everything A-OK! So I think that's your alternative to a reboot -- Task Manager->Services and "Restart" the "Retrospect Client". You don't even have to kill the Retrospect processes (Sys Tray, Inst Scan). Would love to hear how you get on next time your wife's machine has this problem...
  6. Not so sure. Windows uninstall may be deleting it for them, and is generally a good cure-all, so they just may not mention it. I say this because there is a C:\ProgramData\Retrospect Client\retroclient file, which appears to get re-created on a reboot (or archived to a different name as part of the client properly exiting, since the last line on historical versions is "Retrospect Client Terminated"), and includes IP and client state data. It may just be the current client log file, or it may be that the client checks for it's presence at launch and doesn't start if it's there. I'm looking at this on a remote VM and killing RS client might cause problems (and/or I might fat-finger and kill the wrong thing!), so I daren't dig further.
  7. Obviously not. I doubt you've got a "Library" directory either... But you should be able to work out what to do from that one-liner -- with Administrator privileges (sudo) delete (rm -f) the retroclient.state file from the machine's (rather than user's) preferences folder. You know Windows better than me, it won't be too hard to find out where that file is and what it is called. Ways to go after that include: Write a Windows script that looks to see if Retroclient.exe is running -- if not delete the state file and start the client. Make it your wife's problem 🙂 Set the client's "Notify if no backup after" to 1 or 2 days, tell her she should restart (or manually run a batch file that does the above process) whenever the notification appears Rather than "History", set RS to send you a daily backup report -- you're probably in your email client pretty regularly! You might be able to just "Send e-mail for failure and media requests" -- I think "failure" includes client not present for a scheduled script, but you should check. If you are using Proactive, no luck Similarly, Script Hooks will work easily with scheduled scripts, but you'll have to be more creative with Proactive because you'll be looking for an event not happening Regularly run a network scan from your machine -- if your wife's is present but port 497 isn't open, do something (send her an email/SMS, use a hardware board that sets off a klaxon, sigh loudly and give her meaningful look...) Edit to add... I always forget about these, but there are client-side script hooks too. The client only responds to two events -- StartSource and EndSource -- but you could use those to eg send you an email every time a backup happens. You'd then know there was a problem because you didn't get an email after a certain time period. Client-side script hooks would work brilliantly with Proactive backups. With Script Hooks, your imagination's the limit. Emails are one way but you could also POST data to a local or remote web server, to store in a database or simply re-write an HTML file to display the last backup time on a web page. Update a single-pane management interface like Nagios, send yourself a Slack message, etc, etc. Up to you, your preferred methods, and how your current RS setup runs things. ...end edit These are just band-aids -- you should really find out why this is happening. David may be right and it's PEBCAK, or your wife may be having to force a reboot (outside of an active backup) because of other problems, RS Client might be crashing for some reason... Sort out the underlying problem and much of the above becomes unnecessary.
  8. Two different cases. For the IP address thing, the Client is running and you can check it to see state, client IP address, etc (though I can't remember if it reports the primary IP and "Multicast unavailable" when bound to the "wrong" address, or the "wrong" IP). In your latest case, the client isn't running. And every time you try to start it, it launches, sees the lock file, decides it is already running because there is a lock file, and quits. If it was my Mac I'd be straight in with sudo rm -f /Library/Preferences/retroclient.state ...which will usually clear the problem. But when it's a user's Mac I have no idea how they got into that state (forced a reboot? Got creative killing processes in Activity Monitor? Simply have so long an uptime that things are going flakey?) so it's usually better to tell them to restart properly so their machine carries on in a known "good" state. But what you don't want to do is delete the file when there isn't a problem! Let RS do that for you. Use the "No backup in n days" report, set to whatever number of days is appropriate (1?). Use script hooks to send yourself an email when the backup fails (if a scheduled script). Set the client "Notifications" pane to "Notify if no backup in n days". Plenty of ways for you to be told, rather than you waste your time looking! Laziness, FTW!
  9. That's usually a temporary "lock" file that isn't being cleared. Killing processes won't do it, but you can manually delete it or reboot (which generally clears temp files). My Windows troubleshooting can be summed up as "turn it off and on again", so I reckon you did the right thing 🙂 -- but maybe MrPete will chip in at this point?
  10. Is this the same setup as your other post? If so, I suggest you work on one problem at a time -- who knows, fixing one may magically fix the other, too. Otherwise, start by looking for patterns -- does this script fail when run at certain times but not at others (eg it'll sometimes fail when the script starts at 4.30am, but never if started at 9.30).
  11. CHKDSK with what flags? And you may get better results using a less... rudimentary tool. Most drive manufacturers offer better eg SeaTools for Seagate disks. I'd also try using the same filter as you use for the cloud backups, then slowly expanding it to include other files -- if you can find the problem file(s) you can get as good a backup as you can before things become terminal.
  12. I assume it's the "!"s that are the problem? If you click on one and check the "Status" in the "Summary" tab, what does it tell you? Might help to see the "Source" and "Destination" columns too, if that isn't too secret-squirrel to post.
  13. I don't think that's what is being said. If I set up a bunch of scheduled scripts at the same time, the first kicks off and the others go into the waiting queue. If I set up a bunch of Proactive scripts (note: scripts) they don't go in the queue. The note doesn't make it clear, but observed behaviour is that P-AI uses the source lists in all the scripts to generate the P-AI source list -- I don't know what happens if you are already running on all available units and another script starts (do the sources get added straight away, do you have to wait for a unit to finish before the P-AI list is regenerated [and, if so, does that take priority over skipping to the next client?]). There's obviously something hinky in what Jan's seeing, but I think we're second-guessing at this point.
  14. Jan's running a script to back up Macs and another to back up PCs, so he can separate the different rules for each. With his setup, we'd expect RS to start backing up the first 8-10 clients and, when the first of those is finished, it to go looking for the next available and start on that. It should maintain 8-10 parallel executions for as long as there are clients in need and available. He appears to be seeing RS start to back up the first (say) 8 clients and, when the first of those is finished, it carries on with the remaining 7. Then 6, 5...1, and when that last finishes it goes looking for the next batch of available clients. That sounds like a bug, and it would be a useful data point to know if that is happening across the whole Engine (Mac script is waiting because PC script is still backing up a client) or is per script (Mac script reloads next 6 when it finishes the last Mac, even while PC script is still backing up its last scheduled client). I suspect it's the former, both from Jan's description and my own vague sense of how things work, but if it's the latter that does suggest an easy workaround until the problem is fixed.
  15. My v17 tests wouldn't have been severe enough to bring about this situation (testing a work server and simultaneous multiple Remote clients all at your house is a sure way to cripple your home broadband, so I had to limit the time it ran!). Previous versions did what you want, but that was using multiple scripts/sets rather than a Storage Group. In your setup -- if, say, the Mac script is backing up a Mac, does the PC script continue after it's finished a client? IE, is the Engine waiting until all execution threads have completed, or all execution threads for a script? And you may get some clues by setting the Engine Log Level to 5 (see p49 of the manual and this KB article). Agreed that it's annoying if it isn't behaving optimally. OTOH, with the resources you've got, non-optimal performance shouldn't be an issue once you're doing incrementals (unless you've Remote Clients with significant amounts of churn). AFAIK that was used in the context of backups long before the word gained its current "social" connotation. And it's a good word -- "pruning" is chopping off the oldest data, while "grooming" is cleverer and can use complex rules to remove unwanted data from any place in the set.
  16. Thanks David -- I hadn't kept up with the changes, and have edited my post accordingly. Feel free to laugh -- "That Nigel, he's so version 16..." 🙂
  17. I think I've actually mis-represented things, although it's the behaviour most people will observe most of the time. Really it's that "a catalog or media set can only written to by one process at a time". So if you had a single Proactive script targeting two or more media sets (sometimes done so you can rotate sets by alternating which is online) or multiple scripts using the same catalog, only one client could be backed up at a time. Again, Storage Group catalogs behave like one catalog per client/volume (which is why there's no file level de-dup across clients [or volumes on the same client? I've not checked that]) which are presented as a single catalog for search, UI interaction, etc. Even if the catalog is just one file, internally it's probably a database with a table per client/volume. The observed behaviour... Edit: Oh dear, that'll teach me to keep up with the latest changes! See David's posts and links for the correct description of how ProactiveAI now works. But I'll leave this here, both as a monument to my own stupidity and because of the bit about single script/media set blocking. ...is that the ProactiveAI builds a list of clients to back up, based on the sources in currently active Proactive scripts, ordered by "least recently backed up". It works its way down that list, and starts to back up the first available client. If you only have one Proactive script and that doesn't use a Storage Group, it'll wait for the backup to finish before trying the next client in the list. But if you have multiple Proactive scripts using different media sets or your single script targets a Storage Group, a second process will start and try the next client in the list, and so on. Clients "bubble down" the list after they are backed up so, with each iteration, the list remains ordered by "least recently backed up". So it does what you want, if you have multiple (and correctly set up) Proactive scripts or use a single script and Storage Groups. Perhaps the only thing that is missing (at least, I've never observed it) is that if ProactiveAI is half-way down the list it doesn't jump back up to a higher-listed client if it becomes available -- the client will have to wait for the next loop round to get to it. Complete backups should be a pretty rare event (and, ideally, done over the local network) -- Retrospect is very good at restoring from even a long series of incrementals in one go (unlike some other software where you do a restore, then overlay incremental 1, then incrementals 2, 3, 4...100). If you want to do it as part of "set management", have a look at the various transfer options -- instead of doing a (slow) complete backup you can copy the latest snapshot and data from old set to new, then start doing incrementals to that new media set. But, in these days of remote working, getting a first complete backup can be a problem. You could use a separate script/media set for that and then transfer that backup to your "working" media set, so you didn't block other clients for the duration. Or you could use the same media set but a different script with an "only backup data newer than..." filter which you steadily roll back over a couple of weeks -- so you always back up the latest data and, after a few days, you'll have the rest too, with much-reduced impact on your other clients. Retrospect is very flexible, with plenty of options from which you can chose what will work best for your situation.
  18. To expand on David's comment, because I think he's hit the nail on the head... You can only run one backup at a time to a Media Set. If you want to parallelise you must have multiple Media Sets and distribute your clients across them. I do this, putting each "departments'" computers into their own Group, making a Disk Media Set for each "department", then making a Proactive script for each with the appropriate Group as Source and Media Set as target. A Storage Group is, in essence, multiple Media Sets (one per client/volume) in a wrapper -- similar to above but with Retrospect doing the hard work and presenting you with a single UI element to use in your operations. So a single Proactive script can back up up to 16 clients in parallel to a Storage Group. There are pros and cons to both approaches -- which you should use depends on your situation. You can even use both, for example multiple sets/scripts for local desktops and Storage Groups for Remote clients.
  19. The confounding issue is that Macs behave "properly" -- when a "new" primary interface becomes "live" the client will, eventually, switch to it. On Windows the client often gets stuck -- I most commonly see it when users have started/woken their laptop up (client binds to wireless) then connect to the ethernet (which takes precedence for network traffic, but the client is still on wireless), but I've also seen what MrPete describes (client binding to internal IP during network change, and not releasing). That you are using Macs, plus the relatively simple nature of your home network, means that your suggested automated work-rounds will (probably) work. In more complicated situations, with Windows clients, that's far less likely. While I'm sure it could be made to work, the real solution is to fix the problem (which, hopefully, that in-progress-but-delayed bug fix will do).
  20. Go to your Applications folder. Control-click the "Retrospect" app and select "Open Package Contents". Open the "Contents" directory, then "Resources". Scroll down to "Uninstall Retrospect". If that sounds like too much trouble then launch the "Retrospect" app, select "Preferences..." from the "Retrospect" menu, select the "Console" pane (far right) and then "Export server installer and uninstaller" to the destination of your choice.
  21. Manual ipsave has been working for years, well before Remote Clients were even thought of. Particularly useful for dual-NIC machines where eg the primary interface (which RS Client will generally try to bind to) is the general network or "outside world" while the secondary (which you want RS Client to bind to) is connected to a backup or "internal" network. It's most useful for machines with static IPs since you just do it the once. As said before, it's also a good work-round for the "confused client" issue for those who don't allow their users to turn the Client off-and-on-again. But it is more involved since the user (or a script) has to determine the IP address to be used. Note that pretty much anything done server-side will not help because the "confused client" is rarely bound to an address that the server can reach.
  22. His contention is that it's a lot easier for his users to simply turn RS off and on than it is to find the new IP address and use that (somehow!) in an ipsave command -- and I have total sympathy with his view! That would be my default fix too -- as long as (as you've also said) admins haven't disallowed turning off RS.
  23. I'm a bit lost as to how far you have (or haven't!) got. Do you know the version of Retrospect used to create these backups? If it's *really* old you may be in trouble -- I don't think current versions can handle pre-v6 backup sets. Anyway, try Rebuild, select "Disk", "Add Member", navigate to and choose the folder containing your RDB files and you should get a list -- that'll also tell you if the files are encrypted. Pick the "earliest" RDB file -- and hope the files are undamaged after all this time. Choosing the correct directory in "Add Member" isn't always obvious, maybe post a screenshot of the directory structure of the external drive if you are getting stuck.
  24. The problem isn't with the network being joined. When you switch between networks on Windows there can be a "temporary bind" to the self-assigned IP because there's a period when no external network is available. Think of an old-fashioned A/B rotary switch -- as you turn it from A to B there's a moment when neither A nor B are connected. The problem is that when the new network is joined, either Windows doesn't tell RS Client or RS Client refuses to listen (or both! Or something else -- this is Windows, after all 😉). We can nudge things with stop/start, ipsave, or your suggested automation, but these are just workarounds until the engineers (from whichever company) fix the problem.
  25. Neither of which will work, because it is an RS client/OS problem. You can see how it should work with your Mac. Have the Client Preferences open while you are on your ethernet network, then unplug the ethernet and join a wireless network. RS Prefs will read "Client_name Multicast unavailable" in the "Client name:" section for a while (still bound to the unplugged ethernet) and then switch to the new IP address and read "Client_name (wirelessIPAddress)". (Going from memory, exact messages may be different, but you can see a delay then a re-bind to the new primary IP.) But in the same situation, Windows RS Client will go from the ethernet-bind to self-assigned-IP-bind but not then switch to the new wireless primary IP -- it gets stuck on the self-assigned address. Whether that's RS Client or Windows "doing it wrong" is something they can argue about amongst themselves... It does suggest another solution, though. That self-assigned IP is always in the 169.254.*.* subnet. If you are in a single-subnet situation and can configure your DHCP server appropriately you could have your network only use addresses in 169.254.*.* range, and both DHCP- and self-assigned addresses will be in the same subnet and the client will always be available.
  • Create New...