Jump to content

AntonRang

Members
  • Content count

    101
  • Joined

  • Last visited

  • Days Won

    3

AntonRang last won the day on February 9 2014

AntonRang had the most liked content!

Community Reputation

3 Neutral

About AntonRang

  • Rank
    Occasional Forum Poster

Profile Information

  • Gender
    Male
  • Location
    Minnesota, USA
  • Interests
    High-performance storage.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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 14.6.0.127) 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. 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.
  6. Or at least have a command-line tool which could be used to inspect them …
  7. 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.)
  8. They're all fine on the Time Machine disk … And at least one restored properly before, which is interesting too :-)
  9. Restoring that directory from another media set to the server disk results in the same seven files being incorrect.
  10. 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.
  11. 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).
  12. 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.
  13. 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.)
  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.
×