Jump to content

Nigel Smith

Members
  • Posts

    361
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by Nigel Smith

  1. So it's connecting, but not authenticating... Did you also set minauth=none in /etc/nsmb.conf?
  2. NetBIOS is disabled in Catalina, which is probably what's breaking things. See here for how to re-enable. You may also have to use "cifs://serverAddress" rather than "smb://serverAddress" to force an old-style connection. Or upgrade the NAS, of course 😉
  3. Perhaps you and David could form a club? If there's T-shirts, I'll join!
  4. Not being a Windows user, I wouldn't no if there was useful information missing or not! I'll take your word that it isn't. What I can't see from your screenshot is which is your "Active" partition. Googling that app log entry mainly gives (old) mentions that OEM tools will make the OEM partition "Active" whereas System Backup (based, IIRC, around VSS) needs the System Partition to be active, plus a few more that may or may not be malware related. As well as David's questions, I'd ask: Has this ever worked? If it had but has stopped, what changed?
  5. As I understand it (and, like David, I'm a Mac guy), shadow copies aren't necessarily stored on the volume they are copies of. I thought the default was C:, but maybe that's old info. Veeam has a decent article on troubleshooting this, and you should be able to get more information by looking for VSS errors in the application event log. I also notice you are using BitLocker -- I believe that means you must store shadow copies on their originating volume. My Win 10 test machine does have a "System Reserved" volume -- and way fewer volumes than yours! Could you drag the divider down to show all volumes and repost the screenshot?
  6. It was a suggestion aimed at "home users" having this problem, rather than yourself -- you (we!) need a better solution. The "cool application" for us Mac users is Migration Assistant. Old Mac, new Mac, ethernet cable between the two, fire up Migration Assistant on both, answer a few simple questions and walk away -- and when it's done, there's all your old "stuff" on your new machine, good to go.
  7. According to an old post by Lennart, the closing phase of a Duplicate/Copy script involves setting permissions on all the target files, not just the ones copied over in that run. If still true that could explain what you're seeing -- and be another push towards doing "proper" backups rather than using Copy. But "Closing..." includes a bunch of other stuff too, including catalog updating, and doesn't let you know which "sub-task" is taking the time. You might learn more by turning up the log levels (long, and high variable, "Closing..." times have been a regular feature on the Forum over the years, and I don't think they've ever been satisfactorily explained/resolved). If I ever get my codes for RS17 (grindingly slow procurement process here) I'll try a similar test to David's.
  8. Nah, it was this one. Mis-remembered and not really relevant, I guess.
  9. Sure -- what I'm trying to understand is why you've chosen Copy rather than Backup, where you'd do the first backup in the office then the much smaller incrementals over slow connection. It's faster to record the file metadata in the catalog than it is to recreate it on the server (if that, indeed, is what the bottleneck is). There are reasons to choose Copy -- you want to replicate the user's data on your office server so others can use it, for example. 30% churn still seems awfully high, though (unless your situation is of people not having many files, but changing those they have frequently?). I'd take a good look at what is actually being backed up and check the filters are working as expected. I'd avoid Recycle at the moment. That would mean starting all over again every so often, so all the data would have to be transferred again over the slow, remote, connection. The thing with Grooming is that it saves space on your target disk by throwing away the "unwanted" data (eg previous versions of a file) but keeps what's current, so the next backup is just another incremental, with the much smaller transfer that implies. "Resetting" with a Recycle is great for David, with his high-speed LAN, but will probably hurt you more than it helps. Start with defining what you are trying to achieve. (Backing up user data? Replicating it? Just "Users" or the whole volume? Etc, etc...). You can get similar effects with different methods, but there's usually one way that's more suitable than the others.
  10. It was something about backing up (or to!) a NAS volume and seemed weird at first but obvious in (hah!) retrospect. Using Windows settings because it was an SMB mount? Using Mac settings because, although it was a Windows server, it was mounted on a Mac? Whatever it was, red's posted status message is pretty Windows specific and while I don't hold out much hope changing that client setting will help, it won't hurt either -- so even a tiny chance of success makes it worth a try.
  11. So are you doing a Copy that replaces everything with what's "currently" on the MacBook (and other clients), or just replacing the ~30% of files that have changed and leaving the unchanged files in place? Is it 30% of files, or 30% of data? Are you applying any filters? Are you, perhaps, backing up huge numbers of small cache files that you don't really need to copy, or some big files which actually only change in small ways (databases, VM images) that could be handled better? Could you just add a couple of external USB drives to the server and increase your capacity? If you could get the stage where you can store all the weekday incrementals, groom the set down over the weekend, then start again with incrementals the next Monday, that would probably make your life easier. Lots of very small operations, like one-by-one file metadata updates, can be ridiculously slow over a remote link. The more you can minimise them the happier you'll be.
  12. Give that Windows client setting a go anyway -- IIRC, Lennart found some unexpected "leakage" between client settings a while back. Or it may just be mis-reporting its activity and is actually setting ACLs etc on the copied files. Possibly a dumb question -- but why a copy operation rather than a backup? That would probably be a lot faster, especially since it wouldn't have to reset metadata on each of the thousands of small files in your Library folder (which, I suspect, is the problem).
  13. Weird -- that's an option in the Windows client section. You could try turning it off there and seeing if it makes any difference. Version of RS server, version of client, and OS version of both would be a help here. Also info about the destination -- you're not trying to "copy" to a Windows share, are you?
  14. 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.
  15. 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.
  16. 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.
  17. 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).
  18. 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...
  19. 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.
  20. 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.
  21. 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!
  22. 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?
  23. 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).
  24. 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.
  25. 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.
×
×
  • Create New...