Jump to content

Leaderboard


Popular Content

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

  1. 1 point
    And the bad news is -- it does... "But Nige," I hear you say, "surely that's a good thing, allowing us to onboard Remote clients without making them come to the office?" I don't think so, because Remote Clients are automatically added: ...without the "Automatically Added Clients" tag, so there's no easy way to find them ...with the "Remote Backup Clients" tag, which means they will be automatically added to all Remote-enabled Proactive scripts ...with the client's backup "Options" defaulting to "All Volumes", so external drives etc will also be included I let things run and, without any intervention on my part, the new client started backing up via the first available Remotely-enabled script. Edit to add: I didn't notice this last night, but it appears that the client was added with the interface "Default/Direct IP", in contrast to the clients automatically added from the server's network which were "Default/Subnet". I don't know what this means if my home router's IP changes or I take the laptop to a different location (will the server consider it to now be on the "wrong" IP and refuse to back it up?) or if I know take it into work and plug in to the network (will the server not subnet-scan for the client, since it is "DirectIP"?). End edit Given the above I'd suggest everyone think really carefully before enabling both "Automatically add.." and "Remote Client Backups" unless they retain control of client installation (eg over a remote-control Zoom session) -- especially since I've yet to find out what happens if you have a duplicate client name (the next test, which I'm struggling to work out how to do).
  2. 1 point
    Finally got around to having a play with this. While RS17 still treats tags as "OR" when choosing which clients to back up in script and you can't use tags within a rule, you can use "Source Host" as part of a rule to determine whether or not a client's data is backed up by a particular Remote-enabled script. It involves more management, since you'd have to build and update the "Source Host" rules for each script, but there's a bigger problem: Omitting by Rule is not the same as not backing up the client. That's worth shouting -- the client is still scanned, every directory and file on the client's volume(s) or Favourite Folder(s) will be matched, a snapshot will be stored, and the event will be recorded as a successful backup. It's just that no data will be copied from client to server. (TBH that's the behaviour I should have expected from my own answers in other threads about how path/directory matching is applied in Rules.) So if you have 6 Proactive scripts, each backing up 1 of 6 groups of clients daily to 1 of 6 backup sets, every client will be "backed up" 6 times with just 1 resulting in data being copied. That's a lot of overhead, and may not be worth it for the resulting reduced (individual) catalog size. Also note: a failed media set or script will not be as obvious since it won't result in clients going into the "No backup in 7 days" report, since the "no data" backups from the other scripts are considered to be successful. For me, at least, Remote Backups is functionality that promises much but delivers little. Which is a shame -- if Remote Backup was a script or client option rather than a tag/group attribute, or if tag/group attributes could be evaluated with AND as well as OR logic, I think it would work really well.
  3. 1 point
    prophoto, Your OP is one of the least "pro" of any lately posted. 🙄 You don't say what version of Retrospect Windows you are using, or what version of Windows your "backup server" is running, or what version of what OS your "remote machine" is running. You probably should get someone who knows more about IT to help you with future posts to these Forums. Nevertheless, although I'm a Retrospect Mac administrator, I'll try to give you an answer based on no provided information. When you say "create a new backup set on a remote machine connected via a site to site VPN", you must mean the destination is a NAS share on your VPN. Watch this video 3 times before you go any further. Don't create a Storage Group unless you really want to. As the video implies, you shouldn't put the Catalog for the backup set on the NAS; instead the Catalog should be in the default location on your "backup server"'s C:\ drive. Be especially sure you are following the procedure from video minute 0:36 to 0:48, and also from minute 2:04 to the end; maybe your problem is that you didn't configure automatic login per minute 2:04. If that doesn't solve your problem, and you are using a Retrospect version earlier than 17, consider doing at least a trial upgrade—AFAIK free for 45 days. The cumulative Release Notes for Retrospect Windows lists a fix, under 17.0.0.180, that may also apply to creating a backup set on a NAS share:
  4. 1 point
    Malcolm McLeary, When Nigel Smith says "define the ones you want as volumes", he probably means Retrospect-specified Subvolumes. Described on pages 349–351 of the Retrospect Windows 17 User's Guide, they were renamed Favorite Folders in Retrospect Mac 8. I use a Favorite Folder in a Backup script; it works. However Retrospect Windows also has defined-only-in-Retrospect Folders, which are described on pages 348–349 of the UG as a facility for grouping source volumes. The description doesn't say so, but you can possibly move defined Subvolumes—even on different volumes—into a Folder. Since the Folders facility was removed in Retrospect Mac 8, I didn't know it even existed until I read about it 5 minutes ago. That's to say Your Mileage May Vary (YMMV), as we say in the States (in a phrase originally used in auto ads). If they work as groups of Subvolumes, they may simplify your backup scripts.
  5. 1 point
    Retrospect doesn't do a UNIXy tree-walk, not bothering to look at anything "/backup/FileMaker/Progressive/" or lower. Instead it scans *every* file of a volume and applies its selectors to decide what to do. I'd assume from the errors that it is getting partway through scanning those directories' contents when, suddenly, they vanish. Whilst annoying in a simple case like you describe, it's also part of what makes the selectors so powerful -- for example, being able to exclude files on a path *unless* they were modified in the last 2 hours -- and why all the metadata needs to be collected via the scan before a decision can be made. Two ways round this. If you want to exclude most paths, define the ones you want as volumes and only back those up -- we only back up "/Users" so that's what we do, which also greatly reduces scan time. If you want to back up most but not all, which I guess is what you're after, use the "Privacy" pane in the client to designate those paths to exclude.
  6. 0 points
    Can someone give me an idea whats going on here? All local machines have no trouble logging into the share and reading/writing files. I am able to create a new backup set on a remote machine connected via a site to site VPN. When I run the backup script it asks for media. I've tried dozens of times but I just can't get it to work. Thanks.
×