Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


MrPete last won the day on August 18 2021

MrPete had the most liked content!

Recent Profile Visitors

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

MrPete's Achievements


Newbie (1/14)

  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges



  1. Adding a bit more info: once you've recovered in legacy mode, there are a variety of methods for converting a system from MBR + BIOS to GPT + EUFI. Online search should produce good results.
  2. I've added a link to a new note from Retrospect, about changes they've made to Bare Metal Restore.
  3. I'm updating this guide for RS 18. See any errors/glitches? Please tell me and I'll fix the document. THANKS!
  4. You guys are SO funny! If I had time, I too would share a few stories but time is a bit short right now. I just want to clear up one bit of almost-confusion (didn't see this said in my skim to catch up...) NIGEL Smith -- you suggested just enabling backup/etc on 169.254.*.* -- No Can Do * That is what APIPA is all about * It CAN be used in very limited ways. One cool application: connect two laptops directly with a cable. NO assigned IP (so they both get a 169.254 random IP)... Groove Networks "Groove" would see that and sync the two computers! It was AMAZING at finding ways to sync * However, it's not a useful thing even in LAN context. (Worst case, don't block DHCP inquiries coming from an APIPA address... )
  5. Argh. I spoke MUCH too soon. Only had ONE good backup before the same issue returned. I have spent wayyyy too much time diagnosing this... but may have discovered at least a new "reason"... again not what I expected. This time: * Opened RS Volumes list * The C drive on this (backup) computer is listed TWICE! * One entry is gray, and properties have an extra line that says "Location: Local drive C is offline" * All of my backups of course point to the grayed out drive. * Changed so they point to the new good one, and all is well I CANNOT explain how this happened. Nor do I have any idea how to get rid of the now-spare "Gray" copy???!!!
  6. 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.
  7. 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.
  8. 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
  9. 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!
  10. 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.
  11. 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. 😄
  12. 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. 😄
  13. 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 )
  14. 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.
  15. 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.)
  • Create New...