Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by AntonRang

  1. For what it’s worth, I’ve seen this for a couple of years. Favorites on external drives are not seen by Retrospect after a reboot of the client in many cases. I don’t know if this is related to Mac OS changes or Retrospect changes. My workaround has been to use selection criteria instead, which isn’t great. 😞
  2. Maybe I am missing something, but I don’t see any way to configure the Retrospect Client so that proactive backups only happen when on AC power. I’d rather not have my laptops decide to back up when they are not plugged in, particularly since those backups often fail when the laptop goes to sleep. Is this something which could be added in the future, or is it already there and I haven’t discovered it? Thanks!
  3. For what it’s worth, I’m running 14.6.1 (client and see the same issue with /private/var/db/ConfigurationProfiles/Store/, so it’s not addressed there. That directory/file appears to be blocked even from root access under OS X 10.3.3: [Aku:~] root# ls -l /private/var/db/ConfigurationProfiles ls: Store: Operation not permitted -rw-r--r-- 1 root wheel 0 Nov 28 2016 .cloudConfigNoActivationRecord ... The log shows it’s blocked by a sandbox rule; my suspicion is it may hold passwords or other data considered too sensitive for even root to access by default. 2018-03-26 10:38:59.916804-0500 0x31b933b Error 0x0 149 14 sandboxd: [com.apple.sandbox.reporting:violation] Sandbox: tcsh(99190) System Policy: deny file-read-metadata /private/var/db/ConfigurationProfiles/Store Violation: System Policy: deny file-read-metadata /private/var/db/ConfigurationProfiles/Store MetaData: {"build":"Mac OS X 10.13.3 (17D102)","action":"deny","target":["private","var","db","ConfigurationProfiles","Store"],"hardware":"Mac","platform_binary":"yes","profile":"unknown","process":"tcsh","op":"file-read-metadata"} It’d be nice if Retrospect could detect the issue and, as you say, avoid flagging the backup as failed.
  4. One of my systems periodically gets into a state where it won't back up until I kill the retroclient process. Today I looked at it before killing it and found that it was out of file descriptors, because most connections were in CLOSE_WAIT state. This system is set to sleep for power savings, and perhaps this is related, though I believe retroclient can request that sleep be deferred if a backup is in progress. retroclient should be noticing that the server has closed its connection, and closing the local side, to avoid leaking file descriptors and eventually getting into this failing state. The client version, as displayed in System Preferences, is 12.0.2 (116).
  5. This started out as a post about how I was very happy with Retrospect — and actually, I’m still not too unhappy with it, but much less at the moment than I was a few minutes ago, because my restored data isn’t exactly what was backed up. One of my systems died overnight, and after an attempt to restore from a Time Machine backup failed to create a bootable system, I did a bare-metal restore to a second machine, using Retrospect and Target Disk Mode. The restore took a long time (15 hours or so), but I was able to boot the system and everything looked great. Then, as I was reading a post here and wanted to refer to a SCSI PDF document, I discovered that one of my documents wasn’t readable. Checking the time machine backup, it looked fine, but the restored copy was bad. After investigating a bit, it appears that Retrospect (10.5.0) managed to restore my files, but seems to have copied the resource fork on top of the data fork for at least some of them. :-( If the resource fork contained AAA and the data fork contained 123456, then the file now contains AAA456, though it *also* has a good copy of the resource fork. This is, obviously, a problem, though I can likely rsync the affected files from my time machine backup, at least. There may not be very many affected files, either. I don’t know if this would affect a restore through the client; it may be only when restoring to a local disk. I’m also not sure if it affected all files (no, it didn’t; I’ve found that most seem to have a properly restored resource fork, which makes me wonder what’s special about the affected files). So this is a bug report — that there’s some circumstance in which a resource fork is restored both as a resource fork and on top of a data fork — and a request, that there be an option during restore to verify file checksums. (Maybe that’s already there and I missed it; I didn’t see it in the wizard, at least.) And it’s also a thank you — because even with this bug, Retrospect has restored my machine to working order, which Time Machine utterly failed at. (Though I may use the Time Machine backup to address any files affected by this bug; proving that it’s good to have multiple backup strategies.)
  6. I run Retrospect on a Mac Mini server at home, backing up the server and a few other systems. I’d like to have the server sleep most of the time and just wake up when needed. I currently have two proactive scripts and seven scheduled scripts. (I’ve experimented with disabling the proactive scripts via pause and disabling their schedule, but haven’t tried actually deleting them yet.) It looks like RetroEngine always prevents automatic sleep, though (as seen via pmset -g). It doesn’t seem to matter whether scripts are paused or not, or what the schedule for proactive scripts is. I haven’t tried a great deal of combinations yet, and didn’t see any mention of this in the manual, beyond a brief note in the Retrospect 10 release notes that “Mountain Lion's new sleep routines” were supported as of Retrospect 10. Is there any way to configure Retrospect so that sleep is only prevented while a backup is active, or until a scheduled backup? I could easily set a startup time in the Energy Saver control panel if Retrospect itself doesn’t schedule a wake time. It would be ideal if Retrospect could wake the server for a scheduled backup, then let it sleep again, but I’d be fine with just waking the system myself and leaving it up until backups finished and the system goes idle. If I replace my proactive scripts with scheduled scripts, will RetroEngine let my server sleep? I can force a sleep/wake cycle with Energy Saver, if RetroEngine doesn’t override a scheduled sleep, but that’s a bit awkward.
  7. Or at least have a command-line tool which could be used to inspect them …
  8. Ah, OK. I just did a Time Machine restore (before I was just using “cp”), and got back the original files (e.g. non-corrupted PDF format). When I said “one restored properly before”, I meant from Retrospect — when I restored my entire computer, 6 files were damaged after the restore had finished. When I restored the affected folder (a hierarchy containing about 100 PDF files) onto another disk from the same media set, 7 files were damaged. (Since they’re PDF files, it’s really easy to tell when they’re bad.)
  9. They're all fine on the Time Machine disk … And at least one restored properly before, which is interesting too :-)
  10. Restoring that directory from another media set to the server disk results in the same seven files being incorrect.
  11. First finding: It seems to be a bug which affects restore; it’s not (only?) an issue in the media set. Second finding: It’s usually, but not always, the same files. (Very strange.) I restored the most-affected directory (SCSI standards, there’s some irony there) to the Retrospect server’s local disk. With its subdirectories, it contains 108 files, including 58 PDF files, 10 of which have resource forks. Of those, 6 were restored incorrectly on my original system. The same 6 were restored incorrectly on the server — but so was one more, also with the symptom that its data fork had been overwritten with the contents of the resource fork (which had also been saved as a resource). The affected files don't seem to have anything in common which differentiates them from the 40-odd files which are restored properly on both systems; their size varies from 200 KB to 4 MB, the resource forks are all around 48 KB (but so are those for the unaffected files with resource forks), etc.
  12. I was very lucky in that I was reading the forum posts here and ran into the desire to look up an ASC/ASCQ pair in reply to one — and, out of the tens of thousands of technical papers I’d restored, it appears that the 6 affected were all SCSI-related, of which one was the SPC document I was looking for. Perhaps that's because few documents have a resource fork any more, but I found many other files with resource forks that were fine, so there's something odd here. I've been doing a complete comparison with time machine, but diff --recursive doesn't deal well with symbolic links. Some variant of that, though, will be how I verify things in the end. I'll be experimenting with some different restores, but the media set is pretty large (1.5 TB), with 1.5 million files or so on this volume, so the selection process isn’t very fast on my 7-year-old Mac Mini. :-) I’m also curious whether the same problem affected more than one media set (I back up to a rotating set of 3, of which one gets periodically reset so as not to require grooming).
  13. Some more details and thoughts… My Retrospect backup system is running 10.7.5; my client is currently running 10.9.1, though it wasn’t involved in the restore since this was target disk mode. I realized I don’t have good reason to believe that it’s the restore, rather than the backup, which is at fault. Since the affected files I’ve found so far are all quite old, this means that it could be whatever version of Retrospect was available in November 2012 (when the original full backup to this media set was performed) that was at fault, backing up a client on Mac OS X 10.8.x. If I get the time & a spare disk, I may try restoring from a backup set which has been reset more recently to see if it’s good.
  14. !Trouble reading: "XXXXXXX" (8307256), error -206 ( drive reported a failure: dirty heads, bad media, etc.) The -206 generally indicates a low-level I/O error, e.g. a SCSI error, though there may be other causes of it. Additional error information for device "Quantum Ultrium 5 DC" [0:0], Sense > f0 00 03 00 00 00 03 10 00 00 00 00 11 00 00 00 50 84 This encodes the actual error. In this case, $11/00 is the error, which is UNRECOVERED READ ERROR. It might indicate a bad tape, or a drive which needs cleaning, etc. It's not one of the errors which is likely due to the drive itself failing, at least.
  15. After installing the 10.0.1 update, I expected the console would give me the chance to update the server. It did warn me that I had media sets that might be affected by the AES bug (at least on the first run), but there was no update prompt. I thought that perhaps 10.0.1 was only a console update, but I installed it on a test system which had never seen Retrospect, and it installed the 10.0.1 engine. I finally gave up and ran the installer manually using the package found within the Retrospect app. I would have expected (a) A warning that the server I was connecting to was outdated; ( A chance to automatically update it (at least when it was on the local machine); I guess I could have downloaded the whole DMG and installed that way (presumably?), but that seemed like overkill given that the console already has a copy of the engine embedded. Am I missing something obvious? (Or not so obvious?)
  16. AntonRang

    Icon in menu bar won’t stay away

    Yes, sorry — for the client. I could have been more clear (but the engine doesn’t have the option to live in the menu bar, anyway :-).
  17. I try to keep my menu bar uncluttered, so I keep Retrospect’s icon turned off in System Preferences. However, it keeps coming back! The icon reappears in the menu bar frequently (perhaps when a backup is done, perhaps at a login/reboot — I’m not sure). If I go into System Preferences to the Retrospect pane, I can switch the icon preference on and off again, which eliminates the icon until it shows up again. I don’t think this is new in 9.x, I’m pretty sure I saw it in 8.x. It’s purely cosmetic, but annoying and hopefully easy to address.
  18. Gatekeeper only applies to newly downloaded applications (technically, to applications which still have the quarantine attribute). So if you had Retrospect installed before Mountain Lion, and had run it at least once, you don’t need to change Gatekeeper settings. Actually, you probably could just control-click and choose “Open” — that will bypass Gatekeeper (after a confirmation dialog) without having to change the preference.
  19. I am running Retrospect 9.0.1 on MacOS 10.7.3, trying to set up a media set on a remote network share. I go to the Media Sets pane, click Add, choose Share, and enter a path like this: smb://xxx.yyy.com/ifs/home/arang/backups (The same failure occurs with any subset of the path, as far as I can tell; stripping back just to the /ifs point also fails.) I then enter my username and password, and click on Add. I don’t get any errors, and nothing is logged, but the server never appears in the media sets pane. It is mounted (though apparently only accessible to the root user), and it does appear in the Sources pane. (I haven't tried backing up from it, since I really want to use it as a backup destination, not a source.) Any thoughts? Tracing the execution of the engine and application didn't reveal any failing system calls; I see the engine accessing the top-level directory, looking at a '.snapshot' directory within it, and not continuing further.
  20. My Retrospect 8.2 setup was reliably backing up several directories from a Linux client. After upgrading to Retrospect 9, the first directory backs up correctly, but the following ones fail: (directory names changed slightly to protect the innocent) + Normal backup using Backup work areas at 11/14/11 To Backup Set Big Backup... - 11/14/11 10:17:30 PM: Copying work on anton 11/14/11 10:17:30 PM: No files need to be copied 11/14/11 10:24:21 PM: Snapshot stored, 61.1 MB 11/14/11 10:24:36 PM: Execution completed successfully Duration: 00:07:05 (00:06:45 idle/loading/preparing) - 11/14/11 10:24:36 PM: Copying rang on anton !Can't reserve backup client anton, error -515 ( Piton protocol violation). - 11/14/11 10:24:39 PM: Copying mmmmm on anton !Can't reserve backup client anton, error -515 ( Piton protocol violation). - 11/14/11 10:24:42 PM: Copying cccccc on anton !Can't reserve backup client anton, error -515 ( Piton protocol violation). - 11/14/11 10:24:45 PM: Copying aaaaaaa on anton !Can't reserve backup client anton, error -515 ( Piton protocol violation). - 11/14/11 10:24:48 PM: Copying rrrrrrrr on anton !Can't reserve backup client anton, error -515 ( Piton protocol violation). 11/14/11 10:24:52 PM: Execution incomplete Total duration: 00:07:21 (00:07:00 idle/loading/preparing) Whilst I just realized I might be able to work around this by re-directing my script to the top level directory, has anyone run into this? I should probably drop a note to support too.
  21. AntonRang

    Dissapearing USB Drives

    Had you logged in to the machine since restarting it? USB drives don't (always?) mount until a user logs in. You can enable mounting at startup time by typing sudo defaults write /Library/Preferences/SystemConfiguration/autodiskmount AutomountDisksWithoutUserLogin -bool true (all on one line)
  22. AntonRang

    Source unavailable

    Something else that will stop the broadcast mechanism from working is if you are connected to a network with a relatively slow DHCP server. On my original Retrospect test system, on my employer's network, it can take 10+ seconds for the DHCP server to respond, which is long enough for Mac OS to self-assign an IP address (which later gets replaced by the DHCP-provided address). When the Retrospect engine starts up, it appears to enumerate all of the known networks. If the DHCP server hadn't responded by the time the engine launches at system startup, the engine won't find any of the clients (because it only knows about the self-assigned IP). Only stopping and restarting the engine would get it to see clients again.
  23. So after the most recent Retrospect update, and having a chance to move my tape drive from my Retrospect 6 system to Retrospect 8 again, I decided to give disk-to-disk-to-tape another try. Unfortunately it didn't work. I don't know if this may be yet another Snow Leopard issue and hence addressed in the unreleased Retrospect update, but it seemed worth posting/asking. Tapes formatted by R6 show up in the drive as "(Unknown)", as expected; but erasing them, or trying to add them to a media set, results in the drive going to an "(Empty)" state after a small bit of tape access. The operations log shows either "Couldn't erase tape, error -102 ( trouble communicating)" or "stucFinished: incorrect scsiServiceResponse 0x1$ / stucFinished: transaction result 0x6". Enabling device debugging (level 6) seems to indicate a problem with the FW transport rather than the device; at least, I never see anything which looks like an ASC/ASCQ. The problem seems to be: Result -320, status -1, (srb 0x0, ha 0x0) I'll attach a snippet of the log file (poorly formatted, sorry; but the Retrospect console doesn't show all of this, for some reason). (My current test machine is an Intel Mac mini; Mac OS X 10.6.1; Retrospect 8.1.525.1 [console at 8.1.526]. The tape drive is a Sony AIT-1, from LaCie, which reports itself as "LaCie 1394 Tape drive" with software version 0x10483, firmware revision 0x32, product revision level 0x0102 -- the most recent version available from LaCie. It works well with Retrospect 6.)