Jump to content

Nigel Smith

  • Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About Nigel Smith

  • Rank
    Advanced Member

Recent Profile Visitors

105 profile views
  1. Nigel Smith

    can't link to

    I'm guessing this is Filemaker Server machine running under OS X... "Content" files uploaded to your database server and linked rather than embedded -- in this case a PDF -- are backed up once by Filemaker's internal scripts and then, subsequently, linked to so that you don't waste disk space. I *think* the latest backup has the real file and the previous backups contain links, but that should be easy enough for you to check. Check the timestamps in the paths above and you'll see that the older "instance" of the file can't be linked to the newer. So either you haven't duplicated that later "instance" or, for some reason, RS can't recreate the link in the older FMS backup directory. I'd worry about the first and honestly not care about the second since if I had to roll back to an earlier version of my database it wouldn't be that much extra work to manually copy "content" files into the right place. Which is it, and what are you duplicating to? Nige
  2. It's more likely that Retrospect doesn't get direct-enough access to the drive hardware for this to work. Worth a try to save some money, but I hope I didn't encourage you to waste too much time on it. Options: Get a compatible external drive Replace the internal drive in the Mini (sample iFixit teardown here) Do the restores on another Mac on which you can install or migrate Retrospect But I'm not sure any of that will help. If I'm getting the above right: Retrospect on the Mini works fine creating then restoring from a new DVD It doesn't work for 2001 (Sets 1 and 2) (CD-Rs) It does work for 2003 (Set 3) (CD-Rs) It doesn't work for anything more recent than 2003 (CD-Rs?) ...which implies it is a problem with the media rather than the drive -- I'm not sure that e.g. an alignment problem would cause failure on some but not all CDs. CD-Rs can degrade surprisingly quickly in the real world, unless you've used expensive "archival grade" media, and retrieving data from 10-15+ years-old disks will always be a dodgy proposition. I never used RS much with optical media, so hopefully the David and Lennart will chime in here: Could you use Disk Utility to image the CD-R, then burn that image off to another disk that could be read by RS? I guess there's a slim chance that the OS's disk access routines are more robust/forgiving than RS's, allowing you to recreate a CD that's readable by RS. Nige
  3. To add to the above -- is this test using lots of smaller files or fewer larger ones? I'd benchmark using something like: Current data set using disk-to-disk backup Current data set using disk-to-tape backup (which you've already done) 1TB tarball, disk-to-disk 1TB tarball, disk-to-tape ...and I wouldn't be surprised if you end up using some form of disk-to-disk-to-tape if you want to maximise tape-write speed -- at least until the API changes David mentioned come down the pipe. But -- do you want to, if it's at the expense of added complexity? While it's nice to go as fast as you can go, if you're completing during your backup window and not wasting too much tape (i.e. the drive's variable-speed operation copes well enough to reduce "shoe-shining" either completely or to an acceptable amount), then having another step to manage may not be worth the hassle. Nige
  4. Doug, Have you got access to another Mac with a CD/DVD drive and a Firewire connection? Doesn't matter what it is -- you may even be able to use that old G4 laptop, depending on what died. What you might be able to do is: Start the other Mac up in Target Disk mode (hold down the T key at startup) Connect it to your Mac Mini with Firewire Both the HD *and* the optical drive will then be available to the Mac Mini as external drives Then put the disks into the other Mac's optical drive when prompted by RS on the Mini. Might get you round any drive problems without requiring a trip to Ebay. Nige
  5. RS reporting on the Mac's Console knocks spots off the Windows version. Particularly useful, I find, is the pre-rolled "No Backup in 7 Days". It would be even more useful if I could take that report and use it to generate emails to those affected users, including standard advice to restart their machine, plug in to the Ethernet rather use wireless, etc. Anyone know of a way to extract that data from the report, ideally scriptable? I can kluge something together by printing it to PDF, using Acrobat to save as text, then parsing the resulting file for client names and matching them against our user database -- but that amount of interaction means it won't get done very often... Would it be worth investigating Data Hooks to achieve this? Can I access the Retrospect API from outside the Console/Dashboard? We used to use the equivalent of today's script-hooks to send the summary of each backup directly into a database, and generate the emails from searching that, which could be another option. Anybody doing something similar, before I reinvent this particular wheel?
  6. On my MacBook Mojave test machine, screen sleeping/CPU working works just the same as always -- tick the box to "Prevent computer from sleeping..." in Energy Saver's "Power Adapter" tab, leave "Wake for network access" and "Enable Power Nap..." untucked (since we don't need them), screen will eventually go black but computer is still available over ssh, sharing, etc. What machine(s) are you using? I might have something around I can try and duplicate on.
  7. Nigel Smith

    Can't access volume Error -1102

    Earlier you said the backup machine was mounting the volume read-only, now you say it's the only one that's write-exclusive. It probably doesn't matter, may be just a slip of the keyboard, but you might want to check in case it's that that has changed and has started causing problems (I don't see how it would, but I always worry when there's an inconsistency...). Re: Permissions -- you've got the SANmp volume access permissions as you mention, but you also have the usual file/folder permissions. I was just trying to make sure that the backup machine can both mount the disk in a way that allows it both uninterrupted (i.e. no other machine has SANmp exclusive-write) and unhindered (i.e. the user account Retrospect is running as has at least read access to all the data on the volume, including metadata). I'm assuming that SANmp log-in controls how the volume is mounted while the OS separately manages file permissions but, never having used SANmp, that's a big assumption! But I think you are right. It's erase/restore time, if only because that's the first thing SNS will tell you to do if you contact their support. Nige
  8. Nigel Smith

    Can't access volume Error -1102

    So do you do regular erase/restore maintenance, as SANmp recommend? If not, that would be my first fix. If you do, and have done so in the last 6 months, I'd be inclined to not bother until the next scheduled erase -- it sounds like you are backing up the actual data even if you aren't getting the state data, and that should be easy enough to rebuild. But do some test backups first! Speaking of which, further up you mentioned a restore test and "So, I went to restore files and folders I was able to select the disk but it had a 'yellow exclamation sign' on the disk". Possibly a silly question, but were you trying to restore to the SAN volume? The one that's mounted read-only, so you can't write the restore to? ? Other random thoughts, based on no knowledge of SANmp at all... Have you got a client on your network that intermittently mounts the problem volume in "write-exclusive" mode? That might cause a similar problem -- schedule your backups for when that client is not in use. I believe you "sign in" with SANmp -- does this also grant permissions? Does the backup server's sign-in ID have full read-only access to that volume, including all metadata? the problem may have started when someone set special access permissions on a project directory or similar... Nige
  9. Nigel Smith

    Can't access volume Error -1102

    It sounds like you are using SANmp to mount the volume on the server OS, so it shows up as a "Local" volume to Retrospect Server. As such, it will be available whenever mounted and can't be removed/re-added like you can a client. It appears you have a problem with that particular volume on your SAN. Can you use Retrospect's catalog/logs to narrow that down to a specific file or folder if you try a new backup? If not, it's time for a binary search -- back up the first half of the folders at the top level of the volume, and if that fails the problem is there while if it succeeds the problem is in the second half of the list. Do the same with the first half of the "problem" section, repeat until you find what's missing. Is the problem file/directory important? If not, I'd simply make sure my backup (apart from that file/directory) was good, then erase the volume via SANmp Admin then restore to it. Apparently you should be doing this every 6-12 months anyway (!) as preventative maintenance -- more details here. If it is important then I suggest you contact SANmp support for suggestions -- whilst I normally have faith in Disk Warrior, the extra layer of abstraction/mis-direction introduced by SANmp may be confusing things... Nige
  10. Nigel Smith

    printing the content of a media set

    There's a way... but you won't want to use it. Start a Restore job and select the "Search for files..." option, "Continue" Leave the search as the default "Any" and a blank filename field, select the set your want to print, "Continue" Select a restore destination (don't worry about disk space, you won't be restoring), "Continue" After Retrospect has finished searching the sessions, click the little "Preview" button alongside the set details Go through the preview list and click on every disclosure triangle which might have contents you want to print out Select "Print..." from the File menu <recommended>Cancel the job once you grok the number of pages... Even for a subset of files (I've done it for someone who thought "the name might include 'December' or something") it's a horrible job. What are you trying to achieve, and why? There may be another way. For example, if you want a hard copy of the files backed up from a client you can: Go to "Past Backups" Find the client's most recent backup and click the "Browse" button associated with that Make sure the "Only show files..." box is not checked Click "Save..." ...and you'll get a CSV file that you can further process and/or print. You could do that for each client in the backup set, which may be both quicker than the above and closer to what you actually require. Nige
  11. Nigel Smith

    Full Access Mojave

    Should be this screenshot -- they've simply linked "engine" twice rather than "engine" then "client". Henry, have you tried backing up the updated client yet? I still get a -519 error ("Can't track volumes"), but I'm assuming that's because I've only updated the client to 15.6, not the server. Nige
  12. Nigel Smith

    Full Access Mojave

    There's clearly been an change in Mojave's behaviour since Retrospect published their instructions. I've had a google in case there's a way of adding non-apps via the command line, but no luck -- Apple's included tccutil allows you to reset privacy settings for apps, but not add or remove apps (or control panels etc). As it stands, we're waiting on updates -- either from Apple, to re-enable the old "add a control panel" behaviour, or from Retrospect with an "app-ified" client. We've already told our users to not update to Mojave without checking with us first so we can make sure they have other backup options in place (luckily they all will because we haven't started our RS rollout yet, but it's a good chance to check they are actually using those options!). Nige
  13. Nigel Smith

    Full Access Mojave

    "Security & Privacy" isn't accepting .prefPanes (Retrospect Client) or bundles (InstantScan) as valid file types, so you can't add them to the exception list. I guess "apps" really does mean apps -- at least for now. I don't know if this is a GUI bug -- the pref pane doesn't think it can add a bundle but the underlying system would accept it if only it could be added -- or something more fundamental. Even if it does work, as things stand you'd still have to forget and then re-add each and every client. So you might want to wait for the "upcoming (Retrospect Client) release (which) will eliminate the uninstallation step and preserve your client settings." Nige
  14. Nigel Smith

    Subnet Broadcasting

    No, this is what doesn't work for our situation. I had hopes, a few weeks ago, but it wasn't to be... RS Server knows which interface a client was added via, and only ever looks for the client on that interface. So a client registered when on the 183 address would only be backed up when it is the 183 subnet, never when on the 45. Brilliant in many situations, like departmentally-segregated subnets/VLANs where clients don't move around, but no good for us. Nige
  15. Nigel Smith

    Subnet Broadcasting

    Almost. Static IP is applied in client's Network pane of System Prefs (or equivalent for Windows) and, after registering, it is reset to "Using DHCP" after which it might appear on either subnet via the magic of DHCP offers and acks. So just a brief, temporary, static allocation while sitting at the client machine and installing the RS client. Again, this isn't a security issue. Our core switches have aggregated connections to the Fortigate, which is our router and gateway to the outside. This gives us huge bandwidth along with redundancy and automatic fail-over if one of the core switches fails. The "unforeseen consequence" is that, like most routers, the Fortigate will not send a subnet broadcast out of the same interface it arrived in on (broadcast storm prevention) -- and since all our subnets are on that same aggregated interface, a shout from the 45-server can be routed to every interface except the aggregated one containing it and the 183-client. Direct IP is fine, Bonjour etc works (apparently the "network control" portion of the multicast subnet is treated differently to RS's multicast address, which threw us for a while) -- it's only this one use-case that has caused problems. There are ways round it, but they create more complication and/or other problems. For example, we could put each of the subnets onto their own VLAN because each of the subnets would then be a virtual interface on the aggregated interface and the RS packets could be routed because the incoming and outgoing virtual interfaces would be different. But that could screw up building-wide printer and share discovery without introducing another layer of fixes, etc, etc. But understand that I am not a formal network guy ? The above is gleaned from my testing and discussion with the central networking team (which usually includes them saying "Of course, if this was a Cisco...") and a hasty read of the Fortigate manual and Cookbook, so some of my terminology may be off although I hope the principles are understandable. Time for a proper course, I guess. So the TL;DR for the thread appears to be: "If you are ever in a situation where you have multiple subnets on a network and RS Server isn't seeing new clients outside of its own subnet, try registering the clients while they are on the server's subnet. They may then be available for backing up whichever subnet they subsequently find themselves on -- but monitor things closely!" Nige