Jump to content


Popular Content

Showing content with the highest reputation since 08/28/2020 in all areas

  1. 2 points
    pjreagan, How about the comparative number of files backed up, vs. the total bytes? Lots of smaller files means a slower backup and compare than fewer larger files. If there's a significant difference in the processor speeds between "AG-04" and "DD-13", that will also affect the Retrospect "client" backup speeds. This post in a 2017 thread, especially the first two paragraphs (the P.S. mostly rules out speed of the "backup server" for "client" files), covers the first part of experiments I ended up doing that have a bearing on this. This post in that same thread, and the one following, covers the rest. This post near the end of the same thread discusses my hypothesis on slowness of "client" backups. P.S.: This ArsTechnica Mac forum post says "My 2012 Era iMac with 1Tb Fusion Drive is starting to really slow down. It seems like when the drive is nearly full, the physical drive doesn't like to spin up anymore. ugh."
  2. 1 point
    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).
  3. 1 point
    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.
  4. 1 point
    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.