Jump to content

Nigel Smith

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Nigel Smith

  1. Actually public space -- the IPs given above are just examples. While it wouldn't take too much work to find what the ranges really are, a little obfuscation on a public forum isn't a bad thing. But I apologise for not making that clear and so wasting your time. However, moving to completely private behind our NATing Fortigate is certainly an option. As is moving to IPv6, for which we are getting increasing pressure from central Networking. Both would be long-term projects and neither comes under the heading of "fun" for me, so I'll do what I can with what we've currently got. Thanks anyway, Nige
  2. ff.ff.ff.ff.ff.ff.ff is a MAC address, the Layer 2 analog of Layer 3's -- it's an "ethernet broadcast" while the second is an IPv4 broadcast. That's the crux of the question -- will RS client respond to that in the same way as the normal IPv4 broadcast? Wireshark shows that the forwarded packets retain their IPv4 headers, originating from the server ( and using UDP port 497 -- however their destination is, which may mess with the client (i.e. it's receiving a broadcast but not from the expected IPv4 broadcast address. Server to Fortigate looks good, Fortigate to subnet looks OK, I now need to Wireshark a client to see what it is getting. I'd do this at home. But here we have 450+ non-static devices and ~350 addresses in the IP pool. So, quite aside from the work involved, we simply won't fit. As I understand it, P/PKA merely obviates the need to provide a backup password during client install. It still requires the server to poll for the new client as usual (though that process can be automatic) and so will have the same problem. But I'll have another look in case the server address can be included so the client can notify it of its presence. This is Plan B (or probably F or G by now ? ). Install the client normally, temporarily re-bind to a 45 address if necessary, add client to server. It appears that our sticking point is the initial add -- once the client is registered the server can detect it on either subnet. But I can't see why the mechanisms are different, I may be seeing an IP-caching artefact rather than a true detection, and this will need a lot of testing before I'm happy with it. From your follow-up: This might work. I had a quick look at Remote Backup for another problem, but it didn't help (no control over the other [private] network's settings) so didn't delve too deep. If I can create sub-folders in the Remote Backup Clients folder and assign those to different Proactive scripts -- to maintain concurrent operations and allow different clients to use different backup sets -- it might be a work-round if we can't get things working "properly". Thanks for the idea! And finally... I'm kinda hoping Mayoff will stumble across this thread. Having been helped by Robin before when trying (and succeeding!) to subvert Internet Backups to do things they weren't meant to, I know he's The Man and isn't averse to handling weird situations like this. Thanks David, this has been a great help. I'm desperately trying to solve this without a complete network re-do because, at that stage, we'd also be looking at things like client network login -- and that would make Retrospect's USP of Proactive backups redundant and almost certainly push us to changing to Netvault or similar. And we don't want to do that! Nige
  3. My bad -- we're actually using Multi Server Premium v15.1.2.100 on Windows Server 2016 for this. Clients are Mac and Windows of various vintages. But, as I far as I know, that shouldn't matter. The underlying mechanism for RS's subnet broadcasts has been the same for years (though it is handled differently at the OS level by Macs and PCs) and it is that which I am trying to get more info on. Server interface doesn't need adjusting, just "Default" with the 45 and 183 subnets defined -- and it has to be that way since each client can get either a 45- or 183-based DHCP provided address when they connect to our network (using different interfaces for each subnet works for client discovery, but clients are then only backed up when they are on the same subnet they were discovered on ? ). If it sounds a horrible mess -- it is! But it is like that for historic reasons, which we had no control over. We used to be OK because our network ran under a net mask and so RS broadcasts from a 45 covered that and the 183 (we have a third, unrelated, subnet but any client there is static IPed and so reachable directly), but a gateway "upgrade" last year resulted in both physical and logical topology changes which included tightening the mask -- a good thing in general, but not for this specific... Central Network's guys are suggesting Layer 2 broadcast forwarding (rather than Layer 3 as described in that Wikipedia article), but I'll be chasing my tail if RS client doesn't respond to Layer 2 ? (Oh, and thanks David -- nice to recognise a name from the past!) Nige
  4. All, Trying to get subnet broadcasting working. We have 2 subnets, both on the same interface of a Fortigate IPS -- for sake of argument, and Unicast is fine in both directions. Server sits on the 45-subnet and can broadcast-detect all clients on that subnet but no clients on the 183. We've set the second subnet definition on the server's default interface to be, giving a broadcast address of We've set up a static ARP entry and policy on the Fortigate so that anything from the server to goes to FF:FF:FF:FF:FF:FF, and the policy is showing traffic so it looks like the server's "shout" is at least getting that far. But I know nothing about the client's response. Does the server's "shout" include its IP address (if so, will the above hide that?) and is the client's response unicast? Does the client even respond to Layer 2 broadcast traffic, or does it require Layer 3? TIA to anyone with any answers, Nige
  5. Does your version of RS Server give access to the *Unix* Path condition? If so, try that with "begins with" and "/System/Library/Caches".
  6. Remember that each Snapshot is a "point in time". A file that was created once and never altered will "exist" in every snapshot from then on, but if you restore "every file" it will only be restored once in its original, never-changed form. Restore 10 snapshots and you get 10 identical copies of the 1 file in the backup :-) Your 4800:14,000 ratio isn't unreasonable, and it will depend on how often your clients create, edit and delete files. But, IMO, your "Find" approach is the correct one, assuming that's "Restore" and then "Search for files in selected media sets" -- it's the one I always used in previous versions of Retrospect. Try it for a sub-folder that you know contains changing files and you should find that edited versions are restored with incrementing numbers in the filename.
  7. All, Another variant on the "-1,124 ( invalid NTFS data)" error. Anyone seen this before? Setup: Xserve running OS X 10.7.5 and Retrospect Server 11.5.3 (103) backing up a variety of Mac and Windows clients to a Disk Media Set stored on an attached Xsan volume. Using both Scheduled and Proactive scripts, all to the same media set. Everything ran fine for the first week, but now the Mac clients are all throwing "!Trouble matching <client> to <catalog>, error -1,124 ( invalid NTFS data)". Windows clients are backing up as before. The Xserve and Xsan both pass volume consistancy checks, as do all the clients I've checked. Failing Mac clients can also be backed up to a new Disk Media Set on the same SAN without problem and without re-registering with Retrospect or even a restart. The only thing I can think of that changed over the weekend was that Retrospect bumped into what I assume is an 8TB volume limit for its Disk Media Set function -- despite more than 50TB of free space, there was a "New Media" request which was satisfied by simply pointing it to the SAN and letting it create a second directory. I can't believe that Mac clients can't cope with multi-disk Disk Media Sets -- that would be all over the Forum! And also something that, surely, the server and not the client mediates. So what *is* going on here? Even as I type: + Normal backup using Daytime at 07/04/2015 13:39:11 (Activity Thread 1) To Backup Set 2015... - 07/04/2015 13:39:11: Copying Users on <Mac-Computer1> Using Instant Scan !Trouble matching Users on <Mac-Computer1> to 2015, error -1,124 ( invalid NTFS data) + Normal backup using Daytime at 07/04/2015 13:51:29 (Activity Thread 2) To Backup Set 2015... - 07/04/2015 13:51:29: Copying Users on <Windows-Computer1> 07/04/2015 14:17:33: Snapshot stored, 33.9 MB 07/04/2015 14:17:38: Comparing Users on <Windows-Computer1> 07/04/2015 14:17:56: Execution completed successfully Completed: 495 files, 350.7 MB Performance: 637.6 MB/minute (429.4 copy, 1,315.1 compare) Duration: 00:26:27 (00:25:20 idle/loading/preparing) 07/04/2015 14:17:59: Script "Daytime" completed successfully + Normal backup using Daytime at 07/04/2015 14:19:09 (Activity Thread 2) To Backup Set 2015... - 07/04/2015 14:19:09: Copying Users on <Mac-Computer2> !Trouble matching Users on <Mac-Computer2> to 2015, error -1,124 ( invalid NTFS data) (Change in Activity Thread number is me triggering a schedule manually to instantly test another previously-failed machine with a fresh set).
  8. And tried. And -- wow! Same tests as above: Local restore -- 5.5GB/min AFP restore -- 2.6GB/min Client restore -- 3GB/min Nice one!
  9. Applied for. Further data points in the meantime -- again, all machines running, OS X 10.7.5, client version 6.3.029. Same 14GB restore every time, always to a new folder. Restore to a local disk -- 5.3GB/min Restore to client as a network AFP share -- 1.1GB/min Restore to client as a Retrospect client -- 20MB/min
  10. Adding a "me too". Retrospect version, client either 10.5.0 (145) or 6.3.029, all machines running OS X 10.7.5 Backup whizzed along at 748.8 MB/min but a test restore to new folder (so no match decisions) of a selected folder of 14 items/14GB is only hitting 20 MB/min Let me know what other test you want, Robin. This is a test setup, so anything up to and including reinitialising both server and client is yours for the asking. But hardware limits the server OS. I'm afraid.
  11. Thanks guys. And Robin -- good to know you're still around. Your help via the old RS mailing list was invaluable, so I'm already feeling better about upgrading.
  12. Still evaluating, but starting to plan ahead. Are there any coded limits to RS 10 that a new user should be aware of? I'm thinking back to the "old RS 6 days" and of hitting the suprise 32k file Internet backup set limit... So, aside from obvious licensing issues, anything else to watch out for? Is there a maximum catalog size, a cap on the number of client tags, rule length or nesting issues? Is a Disk Media Set truly limited only by the mount of storage available, and there's no max component-file count? Sources in a script?
  13. Starting off with an easy one for the assembled great'n'good before I start asking about things like subnet scanning for clients... So: A client gets backed up. That client can then request a restore. How does the client find the server?
  • Create New...