Jump to content

MrPete

Members
  • Content count

    109
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by MrPete

  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. (Sep 2020: I've begun updating for RS 17, and for Win10 1809 and beyond...) This document (as of July 31 2018, Retrospect Desktop 15.1.2.100) is intended to augment the information in the official Retrospect 15 User Guide. All errors are my responsibility. I do not guarantee that this applies to any other version of Retrospect; in fact, I don't guarantee anything about this at all! ? YMMV. Buyer Beware. Etc. A few items highlighted below are not certain for me at this time. Insight welcome! Preparing for Disaster A. Crucial Attributes To Record About Each Client/Host System Several crucial attributes must be recorded about any client or host system that you wish to later restore with a DRD (Disaster Recovery Disk): 1) Disk Layout Why: the DRD is currently unable to fully auto-create this info. It's up to you to do so. Get it wrong and Things Can Go Badly Partition Table Type (MBR or GPT) Number and sequence of partitions. (MOST important: is there a "System Reserved" partition, is there a WinRE (Recovery) partition, which partition is Active, and what's the sequence?) (Nice to have: the name of the 'C:' windows partition) 2) Boot method Why: The boot method for recovery must match that of the system that was backed up. The DRD is currently not aware of this when regenerating a system. BIOS or UEFI? (MBR partition tables support both BIOS and UEFI boot. GPT partition tables only support UEFI boot, with a few rare exceptions.) Where is the boot BCD info? (From experience: Retrospect will NOT complain if your boot info is not on the C partition... and it may not be backed up!) For BIOS boot, the BCD info is typically either c:\boot\BCD or on the system reserved partition, at \boot\BCD. For UEFI boot, it's typically in one of those partitions, at \EFI\Microsoft\Boot\BCD or \EFI\boot\BCD. Hint: It's a good idea to save an exported copy of the BCD store while the system is in good shape. From Admin Cmd prompt: bcdedit /export c:\bcd-yymmdd will save it. [7/31/18 update] There is some indication that UEFI but not BIOS boot information is backed up from any appropriate partition. We're in discussion on this. If you have a complex multi-boot (eg using GRUB or even manually-added BCD entries), I would suggest keeping an image of your boot disk. Retrospect uses Microsoft Windows tools for recovery; recovering non-Windows boot information is (quite reasonably) beyond the product's scope. 3) 64 bit drivers required Why: Many environments do not require 64 bit drivers. Some do. If so, you'll need a 64 bit DRD rather than the default 32 bit. I have one: unless extreme measures are taken (see below), access to our Catalog Files is on a RAID 1 internal drive pair, managed by IRST (Intel RAID Storage Tech) which uses 64 bit drivers on 64 bit Windows. 4) Custom drivers required Why: If recovery requires access to devices that need nonstandard drivers, you'll need to prepare ahead. Example: my IRST setup. Typically, custom disk drivers that can be used at boot time are downloadable either in normal "installable" form, or in what is known as "F6 Floppy" form (refers to pre-boot interruptable driver-load... TMI ) The DRD creation instructions tell you to copy these drivers to a particular place on your Retrospect Desktop machine before creating the DRD. Do it. (currently they go in <Retrospect Install Folder>/drsupp/drivers ) 5) Non-hard-drive boot methods fully supported for system recovery Why: Not all machines support USB memory key boot. Windows 7 does not fully support USB for recovery operations. You may need a DVD (even a USB DVD, strangely). B. Crucial Things to Know About the Disaster Recovery Disk This information is not documented elsewhere, AFAIK, other than the first line below 1) The DRD... Why: These attributes determine how many DRD's you may want to create and maintain. AND, you'll want to update the DRD after significant system or Retrospect config changes. Is either 32 or 64 bit, and recovers a certain range of OS versions (eg seven varieties of Win10, etc) Assumes the boot style of the host system (it appears the DRD is intended to boot both UEFI and BIOS. Not yet clear if this works properly. For now I would not make assumptions.) Contains all Retrospect configuration as of when it is created, including Devices, Clients, Backup Sets, Volumes, Selectors, Preferences, Licenses, and Automation Settings Has built-in drivers for network, USB and many other devices Why: These attributes are unknown to the DRD. You'll need to maintain this knowledge separately, available for use in case of disaster Does not know how to auto-restore system Partition Table types (Reserved, Recovery, etc), partition settings (sizes, etc), have access to catalog files on other disks, or login info to access network shares 2) Where do you keep your Catalog File? Why: Be sure you can get to the catalog file while recovering from a disaster! It's easy to move the catalog file off of your boot drive. Do it. (Or, make a copy as part of your backup strategy) In our case, to avoid other hassles, we host DRD recovery using a copy of the catalog files loaded into a USB stick. Easy-peasy. C. Before Creating the DRD Do you need custom drivers? Make sure they are in place already (see above)! For Windows 10, you need to download and install WinPE, which is part of the ADK as described in the DRD documentation. These items are not yet documented: For Windows 7, a different kit is needed, the "AIK" PRE-Win10-1809: You don't need to install the whole kit. When running the ADK setup, uncheck everything other than "Windows Preinstallation Environment (Windows PE)"... which will auto-check "Deployment Tools" Win10 1809 and beyond: You only need the WinPE addon to the ADK. (See here: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/download-winpe--windows-pe) When running the ADK setup, uncheck everything other than "Deployment Tools." Then then install the WinPE addon as described here: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/winpe-create-usb-bootable-drive Highly recommended: just before you create the DRD, do something to disable or pause all auto-run scripts! The DRD recovery environment is a "real" Retrospect environment, and will attempt to run any active scripts! (I introduced an N month delay in all scripts as a workaround, then removed it) Yes, it is possible to cancel all scripts once the DRD is running, but that can take quite a while as Retrospect goes through "preparing for open file backup" on the active scripts...) D. Creating the DRD The DRD tool wants you to locate a file, "copype.cmd" . The Retrospect team intends to auto-find this, but that's not yet implemented. The file is found in <Kit install dir>/Assessment and Deployment Kit/Windows Preinstallation Environment Bare Metal Recovery A. Preparing the System Ensure the system is set up in a similar fashion to the original system that will be restored. In particular: Boot settings so the system boots into the correct boot type (UEFI vs Legacy/BIOS. For one of our machines that supports both, I had to force it to Legacy to get everything working.) The correct Partition Table Type and Partition Layout (The DRD can create partitions, but has no ability to set Partition Types, special partition formats, detail-level partition sizes, etc.) (At first I reloaded Win10 on a system to be reloaded. The partitions were laid out very differently, and in particular a different count and sequence. Result: the recovery process wanted to wipe the contents of other data drives on the machine! Another time, the recovery immediately failed with strange VSS errors. Only when I correctly pre-set all of these elements did recovery go reasonably well. Tech Support has informed me these are known bugs (eg Bug 6109 about an invalid disk erasure warning)... however, if you have any concern for preserving drives, I urge care in restoring to ensure you don't accidentally make things worse than they already are ) B. Doing the Restore The recovery process involves several steps. Remember, I'm just giving additional notes and hints. The primary steps involve: pre-setup, run retrospect, post-restore Pre-setup: if you've predefined the partitions, you'll mostly just want to erase and reformat the 'C:' windows partition. Give it the same name that it had before to make life simple. Pre-setup: If you'll need network access to your backup sets, this is a good time to do a network-use of any needed shares. The DRD process will remember you're logged in from this point on Pre-setup: if you have other disks (eg USB stick) to attach to the system, eg containing Catalog files, now's the time to plug them in. In retrospect: check the needed catalog file(s) / backup sets. Can they be accessed (double click in 'Backup Sets'). If not, click "More..." then "Open..." to open the catalog file. Drag-and-drop of a catalog file does not work at this point to attach it. In retrospect: to do the recovery, go through the "Restore" process. I find it helpful to click on "Switch to Advanced Mode", and go through the steps one by one to be sure everything is as desired. In retrospect: before rebooting, be sure to remove the DRD disk! You don't want to just run the recovery again Post-restore: (if using Dissimilar Hardware Restore, don't leave the DRD script after finishing with Retrospect!) C. After Restore When my main host restore was complete, after reboot I got "no operating system found"... a bit scary. Solution for my situation: Boot with a Windows Recovery CD, get to a command prompt, and use these commands... bcdedit (shows boot information setup, if any. My system had none! bcdedit /store x:\boot\BCD is good to know about...) bootrec /rebuildbcd (finds windows and builds the correct boot environment) bcdboot c:\Windows /s b: /f BIOS /v [where the drive letters are what's valid in your recovery environment; "c:" is your windows volume, and "b:" is your boot volume, which could be the same as the windows volume, or could be the System Reserved partition.) ALSO of note: for bcdboot to work, you need a valid copy of the following file from the bootable normal windows environment: c:\windows\system32\config\BCD-Template If you get further errors, you're beyond the scope of this hints-doc. Lots of material is out there to assist you. All is NOT lost. Building A DRD After The Fact I didn't have a chance to build a DRD before the boot disk on our primary backup system died. Here's what worked to get around that not-so-little problem: Downloaded a Windows 10 Pro installer from Microsoft (yes, it's free... controlled by license codes and activation keys) Used a separate tool set to predefine the partition structure of the replacement drive, to match the old one. MBR disk with System, C:, WinRE in my case. Didn't put any data in the partitions. Installed Win10 Pro into the C partition. Told it "no license key" since it was already activated. It really did auto-activate when the time came. Downloaded and installed Retrospect. used the c:\ProgramData\Retrospect\Config77.dat file from my almost-totally-dead drive. This gave me a very nice working environment Installed the ADK as described above Modified a few Retrospect scripts as described above Installed the IRST drivers. Then (due to other problems I'll not discuss here) switched tactics and recovered the current catalog files from my RAID to a USB key With the USB key catalogs in place, and all other drives disconnected, created the DRD Bottom Line This all sounds so neat and tidy... I have done this writeup because my actual recovery process involved discovering the hard way that there are many undocumented aspects to the DRD process! I suspect with these notes, a Retrospect Desktop system could be easily recovered in a matter of hours. Mine... well let's just say I began recovery Sunday evening and finished Wednesday morning... (One of those times when I wish I could get paid by vendors who benefit from my bug-sleuthing skills?
  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. 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.
  5. 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!
  6. 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.
  7. 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. 😄
  8. 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. 😄
  9. 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 )
  10. 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.
  11. 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.)
  12. MrPete

    Yet another -530 client not found error

    That's pretty complex compared to restarting the client ... but sure it could be scripted.
  13. 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?
  14. 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.)
  15. 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!
  16. 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!
  17. I am surprised this is not an obvious functionality. Scenario: - Existing drive, good backups - For !@#$% reasons, a chunk of an NTFS partition was literally zero'd out at a low level - Result: files are all in place but I guarantee their contents have changed. Consider it bit rot on a massive scale What I need: - Restore essentially all backed-up files, ignoring the fact that the metadata matches perfectly - In other words, I want to do a restore-with-overwrite. - Important note: I do NOT want to simply restore the volume if at all possible, because there are many new/changed files not in the backup. I can't find a way to do this. What am I doing wrong? Mostly, it auto-deselects all the files that appear to already be there (matching in size and date stamps). Any ideas much appreciated. I'm about ready to do the obvious/pain-in-the-neck workaround... - Find all new files and copy elsewhere and/or - Delete all files that aren't new THANKS! Pete
  18. MrPete

    How to restore files on top of what's there?

    Well, there's a lot of overlap I guess (Sorry for delays... Real Life kicks in for me a lot... I'm now the proud owner of a big boot on my right foot, after some extensive ankle surgery. Looking forward to long walks for the first time in many years ) David H is correct: what I played with was the GE 635... later renamed Honeywell 635. As for the SA1004... OK, I peeked in my 1970-90 archive box. Yep, I worked on those as well as the SA 1002 (5MB version) ... I no longer remember all of the names, but vaguely recall strong long-term friendship relationships among Shugart founders (possibly Al himself) and others I worked with/for back then: Dr David H Chung (also formerly w/ Fairchild, inventor of F8 micro, and of the first retail microcomputer...); And other names -- Dash Chang and more... I was a firmware dev/performance/test/consultant for Qubex, which made one of the first HDD testers - the QA2000, with both ST506 and SA100x interfaces. I can't find info on who led Qubex. (The only hint I see is about a guy I vaguely remember, Mike Juliff, formerly of Memorex... oh well. The mists of time do tend to fade things out!)
  19. No argument on "more reliable" ... I'm "old school" as well. However, something is seriously wrong if your new system, with several times the "disk" throughput (m.2 NVMe does multiple GB/sec) is not seriously quicker. If your SW builds didn't radically improve, something is simply wrong. The most common performance killer I've seen, by far, is to have a crazy number of temp files. Or a crazy number of files in ANY important folder. Get more than 1-2,000 files in the temp folder and you will seriously feel it. (Free version of CCleaner handles this and more quite nicely. Yes, there's a built in tool that kinda-sorta gets there but not as comprehensively...) Next thing: check Windows Disk Write Caching (assuming you have a UPS attached)... that makes a huge difference, particularly for SSD (seek time is zero, but you want directory info updates cached...) I would suggest SysInternals Process Explorer to examine what's eating up your performance... possibly combined with SMARTmonTools / smartctl (or HDD Sentinel Pro) if a drive isn't giving you what it should. I'm sitting at two computers right now: My 2012 "mainframe", (i7-3930k, 32GB, gobs of SSD including a RAID0 pair used for high speed video capture) 2019 Surface Pro 6 (i5-8350U, 8GB RAM, PCIe SSD 0.9-1.4GB/sec) Except for certain functions (video processing), the newer computer is noticably quicker. Just for example: My Surface Pro can cold boot to login prompt in about ten seconds. Not even close on the older computer. In general, nothing takes a long time. All software starts more or less immediately unless it has a TON of preprocessing to do. YES, lots of processes. But a few things about modern architecture make the overhead pretty much negligible these days. Multicore+incredibly fast context switching means those extra processes use VERY little CPU. As in: I have 193 processes "running" on my Surface right now. CPU usage: 2-3 percent. And I've done literally zip to make it more efficient... in fact, I've got several security and convenience apps running.
  20. I don't have exactly the same experience... however, I do have a caution to share: Microsoft OneDrive has a similar feature. Last I checked, it's not exactly compatible with ANY backup software, in the following sense: Backups work fine However, when you go to restore, it restores the EMPTY local folder(s) Which causes the cloud copies to get cleared out Which means you lose all of your cloud files Unfortunately, I can't place the details on this with a quick google search ...
  21. A very late response What did you end up doing? Assuming you have everything properly defined for your bare metal DRD restores, then yes it "ought" to be ok. If you followed my Admin Guide for DRD, you would have saved a copy of the BCD Store separately... but then what's the fun in that? 😄
  22. Windows 10 doesn't reliably pay attention to the startup folder anymore. Instead: use task scheduler to open apps when you log in. Works like a charm.
  23. AFAIK, R16 is essentially the same with respect to disaster recovery... although I admit I have not dug in as intensely yet...
  24. MrPete

    Yet another -530 client not found error

    Interesting. I just finished discovering a specific set of bugs in Retrospect, and challenges in our router(s) and local network apps, that directly lead to the above anomalies in finding and/or connecting to clients. (Yes, all of the following has been submitted as a bug report.) I'm running a more Windows-centric network, with a little OSx tossed in, so my tools are a bit different. Tools: WireShark: shows packets actually traveling. Most useful is a filter of udp.port==497 || tcp.port==497 tcpdump (command line in linux and/or osx) - monitoring port 497 TCPview (from SysInternals, now owned by Microsoft) - sort on port. Look at what is listening to 497 and on what IP address(es) (command line) ipconfig and also "route print" In Retrospect: go into Clients -> choose a client-> access tab -> Interface -> Configure Interfaces ... and see what default interface IP address is. Things to watch for: Are UDP broadcast packets being received by clients? (eg 192.168.x.255, port 497) For multicast, are packets getting to clients? (eg 224.0.0.0/4 -- Retrospect uses 224.1.0.38 UDP port 497) Are clients responding to those packets (UDP broadcast or multicast) (initially to UDP port 497 on the backup system) If crossing subnets, is TTL set high enough to reach the client? What could possibly go wrong? Heh. Here are anomalies I've seen: Often, some app will create virtual interfaces. This includes npcap (for Wireshark etc), VMware, TAP-Windows (comes with Windows?), etc... This has led to: On some of my clients, some virtual interfaces have APIPA addresses (169.254.*) -- which makes it obvious when retrospect chooses the wrong interface to listen on! (Workaround: I uninstalled the TAP-Windows adapter as I don't need it. And I temporarily disabled npcap on the one workstation where that got in the way.) On my retrospect backup desktop, retrospect chose one of the VMware virtual adapters as the default adapter! This even though the real gig adapter has higher priority etc etc. (Workaround: create another adapter in Retrospect) The result in either case: I can't see the clients, even though ping works. I have a network security system. It regularly scans all ports on all subnets. Some (but not all) clients get confused by this, with the retroclient app hung up on an IP connection in CLOSE_WAIT status. The result: the client is never available for backups. Yet it is visible to subnet or multicast. We switched to a pfSense firewall/router. I just discovered that multicast forwarding is badly broken.(Workaround: manually installed pimd.) Similarly, UDP broadcast is often blocked by firewalls. Make sure the packets are getting through! Having fixed and/or worked around ALL of the above, and rebooted everything... I can now reliably use either multicast or subnet broadcast to connect with clients.
×