Jump to content

twickland

Members
  • Posts

    1,685
  • Joined

  • Last visited

  • Days Won

    39

Posts posted by twickland

  1. I note that all four volumes are on the same client. I'm wondering whether the client reserved messages for "admin" and "conf" are being caused because Retrospect is already in process of backing up "share." Note that according to the log, the script launched at 5:00:00 and the backup of "share" also began at 5:00:00.

     

    If that's the case, this would seem to be a bug.

  2. Only after I changed the script setting to "Allow early backup" did the script immediately start running.

    That would indicate that the "Back up every X hours/days" interval is either set too long or is not being properly recognized. If the repeat interval is indeed set to what you want (we use 20 hours as the interval for daily backups), that would suggest that the script has somehow gotten corrupted.

     

    We have a schedule of allowed operation for all of our proactive scripts, and they all run just fine within the set time windows.

  3. I recently discovered that there is nothing to prevent Retrospect from backing up a media set to itself!

     

    I was creating a test backup script and inadvertently selected as a source the volume that contained the destination media set. When the script ran, it dutifully began copying the various .rdb files belonging to the media set into new .rdb files in the same media set. It seems pretty obvious that this process would continue until manually stopped or until all available blank media was filled.

     

    It would seem to be a good idea to have Retrospect perform a check to ensure that this kind of loop cannot occur. 

  4. You will need to create four schedulers, each one repeating at 4 week intervals, which is the full length of the cycle you are proposing.

     

    As an example, scheduler 1 could back up to media set A beginning on August 9; scheduler 2 would then back up to media set A beginning on August 16; scheduler 3 would back up to media set B beginning on August 23; and scheduler 4 would back up to media set B beginning on August 30.

     

    With a four week repeat interval, scheduler 1 would then back up for the week beginning September 6, and so on.

  5. I would suspect a problem with Retrospect's Config80.dat file, located at /Library/Application Support/Retrospect. If you have a backup of this file from before the time that the problem arose, I would try using that version and see if it makes any difference. Before doing so, you should stop the engine and quit the console, trash the current Config80.bak file, and then manually move the current Config80.dat file to the desktop (in case you need to reinstall it later). When restarting Retrospect, you will want to click immediately on "Pause All" so you can delete any activities that have already run, since the restored version of Config80.dat will have an out-of-date activities calendar.

     

    While less likely to be the source of the problem, you might want to try simply reinstalling the Retrospect engine first, without replacing Config80.dat, since performing that test will be simpler.

  6. It would likely be easiest to first perform a clean reinstallation of Mavericks.

     

    I'm wondering how exactly you performed the failed Restore? I've never had Retrospect fail to create a new destination folder when requested, and we restore preference files all the time. Did the Summary page, before you performed the restore, indicate that the files would be restored to a new folder?

     

    For extra safety, I would define a subfolder on the destination volume (such as your Desktop) in Sources, and use that as your restore destination, in case something further goes awry.

  7. We recently encountered several problems with Retrospect Engine 12.0.2. At one point, the engine couldn't communicate properly with our tape drive, a problem that was only resolved when we reinstalled the engine; this was described here. Last weekend, the engine got stuck in the middle of initiating a backup to one media set. "Stuck" means that the little activity wheel icon was spinning but no progress was being made. 

     

    While in this stuck state, the engine was successfully able to run another backup using a different script and destination media set, but was then unable to carry out any other copy or backup scripts, all of which ended up on the list of waiting activities. What was peculiar about this waiting list was that the reason that was listed for having to wait differed among the various activities, with the reason for some of the waits seemingly being unrelated to the stuck activity. For example, one backup activity said it was waiting for a particular client that was not the client that the stuck backup was connecting to.

     

    When I went to Activity Monitor, I noted that I was unable to sample the Retrospect Engine process, even after waiting 20+ minutes for the sample to be taken. I was unable to stop the engine in the Retrospect preference pane, and so I force-quit the process. The engine process did quit, but then immediately respawned, something I had never observed before. This respawned engine process was essentially idle, and I was able to stop and start it from the preference pane. However, even though it was idle, I was still unable to sample the process.

     

    All of the above issues, with the possible exception of not being able to sample the engine process, appeared after the OS was updated to 10.10.4.

     

    I would appreciate any observations or thoughts people might have on any of the above behaviors. Thanks.

    • Like 2
  8. There is a problem with the directory hierarchy on that hard drive volume. The media set member that's in its proper directory location is member 8. The folder for member 7 is not properly enclosed in a "Retrospect" folder. It also seems odd that the volume itself seems to be named for an earlier media set member (member 5). Did you by chance make any changes or copy files to that volume in Finder?

     

    Once Retrospect writes a media set member to a particular hard drive volume, it expects always to find that member on the same volume. You can't move it or copy it without incurring problems that will likely require a catalog rebuild.

     

    Retrospect also may behave oddly if, when choosing a media set member, you try to select the folder with the actual member's name. Try selecting the folder with just the media set's name, or even (because the SBBACKUP folder is in the root directory) the volume itself.

  9. I rebooted my computer for a reason unrelated to Retrospect. When the system was back up, Retrospect had lost communication with our tape drive, something I did not discover until the next day because the previous evening's backups had not run. Examining the operations log revealed the following:

     

     +  Retrospect version 12.0.2.116

      Launched at 7/6/15 10:21:19 AM 

     

      stucFinished: [HP|Ultrium 5-SCSI|Z5AD] incorrect scsiServiceResponse 0x1, scsiStatus 0x2

      stucFinished: [0|0|0] transaction result 0x6

      StucStartTrans: ExecuteTaskAsync (error -536870174) 

      StucStartTrans: errval 0xe00002e2, doneServResp 0x0 (error -536870174) 

      StucStartTrans: ExecuteTaskAsync (error -536870174) 

      StucStartTrans: errval 0xe00002e2, doneServResp 0x0 (error -536870174) ..... [error message repeated several dozen times]

     

    At this point, Retrospect could see the tape drive, but reported it as "running;" the tape present icon was displayed, but the name of the tape member was not.

     

    I assumed that the problem was probably related to the tape drive or our Thunderbolt SAS adapter. Several tests with power cycling the tape drive and SAS adapter, stopping and restarting Retrospect engine, and rebooting did not improve things. In fact, after the last reboot, Retrospect was unable to see the tape drive at all; clicking on Scan All did not make the drive visible.

     

    I then checked and found that the drive was visible in both the ATTO configuration tool and in System Profiler. It seemed odd that Retrospect was unable to see it. At this point, I tried simply reinstalling the 12.0.2 engine, not expecting a whole lot. However, when the newly-installed engine came up, Retrospect appropriately accessed the tape drive, displayed the correct tape member name, and, later that evening, successfully ran two backup scripts to the tape.

     

    It's not obvious whether the tape drive reported a true problem to Retrospect, which then somehow damaged the engine file, or whether the engine file was damaged first, which caused it to incorrectly report a drive error. Either of these would seem strange.

     

    Relevant system information: Mac Pro 3.7 GHz Quad-Core Xeon E5 with16 GB RAM, running OS 10.10.4. The tape drive is an HP StorageWorks 3000 LTO-5 drive connected via an ATTO ThunderLink SH 2068 SAS HBA.

     

     

     

    • Like 3
  10. Tried to restore files from an earlier member (hard drive) and it was blank-NO FILES! 

    Is there a folder named "Retrospect" at the root level of the volume? If not, something other than Retrospect must have wiped the drive.

     

    If the Retrospect folder is present, it should contain a file named "Backup Media" and a folder with the name of your media set; inside the latter will be a folder with the name of a media set member. If all these are present, but there are no .rdb files in the member folder, that would indicate that the media set had been reset by performing a Recycle operation within Retrospect.

     

    In either case, if you are to have any hope of recovering the data, you should stop using the drive and contact a drive recovery firm.

    • Like 1
  11. We have  a system that includes two tape media sets and one disk media set. The disk media set remains on site for quick restores, and the two tape media sets are rotated on- and off-site. The largest user files are backed up only to tape, and all other files are backed up to both disk and tape. We use two Copy Backup scripts—one for each destination media set—that are configured to copy the most recent backups from the disk set to whatever tape is scheduled to be in the drive on the day that the copy script runs (we have only a standalone tape drive, not a tape library).

     

    We perform our rotations and copying weekly, but there is no reason it couldn't be done more frequently, as needed.

     

    "Copy most recent backups" means that, if the media set contains multiple backups for a given source in its backup listing, that option will only copy over the most recent point-in-time snapshot's worth of files. In practice, I don't think this option makes much difference, since Retrospect by default keeps only the most recent backup snapshot active and a Copy Backups script only copies active backups (the only way an earlier backup remains active is if you have retrieved its snapshot).

     

    If a source could be backed up more than once between your copying events, and if you wanted to copy over all such backups, you would need to use a Copy Media Set script and not a Copy Backups script.

  12. Sanity check time - after two installs of 12.0.2(116), the Client Updaters folder is rather empty. Is there a seperate download for the insides of this folder, and or is just an Easter egg? Anyone get the good stuff in the intial install? 

    In my experience, when updating through the Retrospect app, the client installers and updaters aren't typically installed. In our case, that may be because we have modified the installer or installer folder to include our public key (making the failure to overwrite the folders a good thing).

     

    Go to Preferences/Console and click on "Export client installer." That will get you what you need.

  13. Prior to Retrospect 12, I believe that the idle/loading/preparing time logged for a particular source always applied just to the time spent on that source, which of course is exactly what one would hope to see. However, in Retrospect 12, the idle/loading/preparing time logged for a source also includes whatever time has been spent attempting to access prior client sources in the backup script that were offline at the time of backup.

     

    I can confirm that this anomaly occurs with clients that were added by direct IP addressing, which generate a -519 network communication failed error when they are offline. I don't know whether it also occurs with clients that were added via multicast or subnet broadcast, as we do not use those methods.

     

     

    • Like 3
  14. Our  idle/loading/preparing time seems to have gone down, if anything, in v12.0.0. However, the way the performance stats are reported in the log is often clearly wrong.

     

    For example, the log entry for one of our volumes shows that a backup of 75341 files and 7.9 GB began at 2:46:52, actual copying began at 2:50:52, snapshot building began at 2:56:12, comparing began at 2:56:38, and everything was done at 3:00:09. The performance stats, though, are shown as Performance: 0.1 MB/minute (0.1 copy, 2,715.2 compare), Duration: 00:13:17 (00:14:18 idle/loading/preparing). 

     

    The only number that seems completely unassailable is the total duration.

×
×
  • Create New...