Jump to content

MrPete

Members
  • Content count

    109
  • Joined

  • Last visited

  • Days Won

    7

MrPete last won the day on September 6

MrPete had the most liked content!

Community Reputation

9 Neutral

About MrPete

  • Rank
    frequent Poster

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've begun to update the Admin Guide for Retrospect 17, and for Windows 10 1809 and beyond. Key new info added: As of Win10 1809, installing the needed WinPE files (in the ADK) has significantly changed.
  2. Nope. However, I just solved it, with the help of this freeware: http://backupchain.com/en/vssdiag/ Not at ALL what I expected: I was getting VSS errors indicating slowness while doing backup. Duuuh. That should not be a surprise. The actual issue: A separate partition (D:) is NOT part of the VSS shadowing at all. On this computer, that partition is used for a lot of active data storage, including continual security cam file saving There was a latent filesystem error (in Windows: chkdsk /f solves it) Fixing that (on D:) made VSS work properly on the C drive and all other drives.
  3. I have a very painful issue. Since June, some key backups always fail due to windows VSS errors. It's impossible to tell if the "real" problem is RS or Win10. NO error ever if RS is not running. 100% dead with RS, yet the error doesn't point to RS. I discovered VSS has Debug and Trace capabilities, but * I find no documentation beyond a few registry settings * I can't actually get it to trace or log Does anyone have experience with this, success OR failure? Thanks Pete
  4. MrPete

    Bitlocker and Retrospect 17

    Here is a mini-version of my own personal real nightmare: - Had no idea my Surface Pro was bitlocker'd - For simplicity, particularly while RS bare-metal restore was less-than-reliable, I often create simple full-partition-copies for any necessary hardware swaps 1) My Surface Pro built-in charge port died. Thus: had a few hours of battery left to do the needed copies. MS nicely would do a direct hardware swap at their service location an hour from me. By the time I got it to them late on a Sat evening, there were only a few minutes of battery life left. I asked about security policy w/ respect to wiping the embedded SSD. "We'll do that first thing tomorrow morning, before it gets sent in." 2) Drove home, ready to load up new Surface from my partition copies. Copied them in... and it would not boot. "Encrypted drive. Please provide bitlocker key." 3) A very late night, learned: - My key for Surface A was in my online MS acct - By restoring the entire partition, including the laptop name, they not-so-helpfully OVERWROTE the stored key online. NOT stored by MAC or any unique ID. - I pulled literally EVERY string I have (I do have some good ones) and got "Sorry, NO there is no backup. No way to recover old versions of these files from our cloud" - Much prayer for inspiration 4) Early Sun called relatives in the city up north, who woke up my nephew, who drove to the MS service site and was there before they opened. I had learned, and gave him, the exact command sequence to pull the key from the Surface, IF it was not yet wiped, and IF he could power it up and login. 5) He succeeded. It died a few seconds later. What an exciting adventure!
  5. MrPete

    Yet another -530 client not found error

    Hiya, I am back from travels (and now have alligators to fight off ) 1) Bug #8512 is Windows ONLY. I have no comment on MacOS with respect to this. 2) I have no comment on ipsave. Have not played with it as I have no reason to do so. (Yes, my perspective, even scripted: if I'm gonna write an effective script that waits around for a proper and stable dynamic IP, it is much easier in my context for the last two steps to be: (stop service // start service) than (discover the correct ip among possibly 4 or more available ip's // format correctly // issue a proper ipsave) ) I did hear back from RS support, who spoke with engineering. YES, a fix for #8512 was delayed, but it IS being worked on. A Big Picture comment: for many reasons, dynamic networking is becoming more complex, not simpler. I easily remember when laptop vendors had a simple monitor service that would auto-switch between wired and wifi ethernet. Now... not so easy in all contexts.
  6. MrPete

    Yet another -530 client not found error

    I would call your experience "simple" but not "simple-minded." 😄 We have a multi-site LAN permanently connected via (OpenVPN) VPN. Plus, for clarity and security purposes, we have multiple subnets, separating server backbone, internal endpoint, IoT, and guest nets. As the guy responsible for all of that, my MS Surface Pro 6 may be connected anywhere at any time. Sure, not all of those are available for backup... but at the least my laptop may want to be backed up from any site. In practical terms, that means my one laptop may show up with any of at least four different IP's. Oh, and up to four MAC addresses (2 different WiFi MACs, and two docking station ethernet MACs.) The hard part: even if it were only one IP per site (ie both Wifi and wired sharing an IP -- NOT supported by all systems!), I have watched as Windows brings devices up and the RS client attaches. As Nigel says, the client can easily bind to an unusable ip (169.254.*.*) even though the ethernet/wifi adapter ends up on a valid IP. The mayyybe good news: I've pinged tech support to go back and see what is going on. * The bug report for this (8512) was supposedly being worked on months ago. * It is NOT listed in release notes. * I DO see some evidence that something has changed. Until I hear back, I'm not willing to invest the time and energy to completely redo my extensive testing. * I suspect they slipstreamed some kind of solution, even if incomplete or still having a bug or ten. 😄
  7. MrPete

    Bitlocker and Retrospect 17

    I'll add a bit more here about Bitlocker. In my experience, MOST Windows users literally have no idea if Bitlocker is enabled or not. That's actually a very serious problem, not unique to MS: * In the interests of a combination of (ease of use) + ('good security'), the very fact of Bitlocker encryption and keys is 100% invisible to the average user. * The key is stored (ONLY!) in their online Microsoft account. Which they may have no idea even exists. * If/when their Windows 10 boot fails, the ONLY way to get into the recovery system on their computer, is using that key * If their drive is partially failing, the ONLY way to access it with various low level tools, is using that key * And if their drive is an embedded Nvme SSD, they are hardware-locked to it. I had exactly this scenario a few days ago. The ONLY way to recover the key, was find a way to discern the user's MS account and password. Once we had that, I could go in and retrieve their key. Once past everything, my first action (at their request) was to disable Bitlocker. They much prefer simplicity and reliable recovery, to the complexity of an encrypted drive they know nothing about. 😄
  8. MrPete

    Yet another -530 client not found error

    David, **yes** . I've used Subnet search properly. Used multicast. Used Piton. And here is the key: * When an endpoint changes its IP address, * And does not fully (manually) restarting the Retrospect service, * THEN: the endpoint will NOT (ever) properly listen for the server's "calls". Period. (This COULD be specific to certain general configurations, but I have seen it on various setups.) This is easily proven using SysInternals TCPview. To repeat what I wrote earlier this year: when the Windows client deals with an IP address change, it starts listening to 169.254.*.* -- ie NOT a real IP address. The only workaround is to restart the client service. (NOTE: I can believe under some circumstances this may not happen. I've just not seen it )
  9. MrPete

    Yet another -530 client not found error

    The problem with belt-and-braces: for some of us, the same computer can show up with different IP addresses in the same overall network (ie connecting to different subnets.) This requires a dynamic solution for both server and client. AFAIK, at the server end, all methods work just fine. The only serious problem with dynamic IP's is on the client end, as has been discussed.
  10. MrPete

    Yet another -530 client not found error

    Hi all! Sorry for the long delay. The Real World is intense for me right now The following simple sequence has been a 100% reliable workaround for me: 1) AFTER an endpoint is stably connected to a LAN via any mechanism (wired, wifi, etc)... 2) Restart the Retrospect Client service (stop / start as described earlier) The client NEVER gets confused under such conditions, at least in my way-too-extensive testing. Confusion arises when the client initializes at the same time as the computer is initializing various things, including a variety of network-connected startup services etc. And/or if the network connection changes (eg wired to wifi, or to a different wifi.)
  11. MrPete

    Yet another -530 client not found error

    That's pretty complex compared to restarting the client ... but sure it could be scripted.
  12. MrPete

    Yet another -530 client not found error

    Hi all, I don't have time to go into detail on this... but in sum: * I found several MORE related issues. * Turns out, some of the problems cannot be repaired by use of a fixed IP on the server side * WORKAROUND: Restart the Retrospect Client service At admin cmd prompt, you can do two commands: net stop "retrospect client" followed by net start "retrospect client" * (Alt workaround for static clients: https://www.retrospect.com/en/support/kb/client_ip_binding ) * Retrospect engineers are grinding through it all. Based on my background, I am guessing they are needing to re-architect some pretty deep stuff. It's bug #8512. Last I heard it is being worked on and hopefully in a "soon" update of retrospect 17 In brief: * Particularly for clients (laptops etc) that can shift between wifi and wired etc... * The **client** can easily latch onto a wrong or invalid (169.254.*) IP address. That's NOT what the UI says (necessarily) * Once listening there (particularly on UDP for multicast), it will NEVER update until the client service restarts. TCP client also has similar failure modes. * There's more but that's the essential bit * (To see for yourself, have fun with SysInternals TCPview, sort by port, watch port 497. Retrospect already has all they need to fix it.)
  13. MrPete

    How to FORCE a file backup on each run?

    Nigel, I am cautious about mucking with original-file metadata. (Example: every file has more than one timestamp. Do we really want to be writing scripts that somehow are maintained to understand all metadata? I would rather not be in that line of work anymore ) I don't want a comprehensive copy every time. If this "don't add duplicate" switch still takes advantage of block-scanning etc... that WOULD be interesting! I'll check it out THANKS!
  14. MrPete

    How to FORCE a file backup on each run?

    Excluding is not an issue. Using Recycle Backup would essentially remove the value of Retrospect: no versions, no block-level-change efficiency. OUCH! Might as well just do a file-copy. Hmmm... that would be interesting: - Script a file copy of the file(s) of interest, ensuring the copy has a new timestamp. - Since they ARE big, Retrospect would take advantage of block-level efficiency to only back up the blocks that have changed! - Script deleting the copy (for security) after the RS run is complete. I'll try it!
  15. Due to security requirements, certain files may NOT get a timestamp update when they change. (Consider files that contain encrypted filesystems.) Right now, by default Retrospect ignores all files with an "old" timestamp. QUESTION: is there a way to get Retrospect to back up a file even if the timestamp has not changed?
×