Jump to content

137491BFCBC98DE1E040000A2A666149

Members
  • Posts

    14
  • Joined

  • Last visited

  • Days Won

    1

137491BFCBC98DE1E040000A2A666149 last won the day on June 21 2014

137491BFCBC98DE1E040000A2A666149 had the most liked content!

Profile Information

  • Gender
    Male

137491BFCBC98DE1E040000A2A666149's Achievements

Newbie

Newbie (1/14)

4

Reputation

  1. One of my Retrospect 12.5.0 (111) clients has an external USB drive connected to his/her brand new Yosemite equipped Mac. When any user account is logged in and the external USB drive is mounted, Retrospect faithfully backs up both the internal and external volumes. When at the login screen, only the internal volume is backed up, with the external USB volume erring with (file/directory not found). I don't recall an external volume of any connectivity type being an issue before and I'm not sure it's Retrospect's fault. There is no external device management in place for this user (Profile or MCX restrictions on external media). For the record, the external USB device is a 1.5TB WD Passport formatted HFS Extended (Journaled). The Retrospect server is also v12.5.0 and I've tried restarting the client Mac, fully un- and re-installing the Retro client and even rolling back to a previous client version for testing. Same result every time. This leads to another vexing issue of the never-ending 'Client is Reserved' errors but that's a new topic all its own. I'm going to test with a different brand external device to see if that's the issue. Beyond that I'm wondering if Apple's latest 27" iMac hardware has somehow changed connected USB device behavior when at the login screen. Thanks for any assistance provided. Steven
  2. Upon initiating the catalog rebuild and pointing Retrospect to the corresponding Disk Backup Set, the system indicated there was only one 'missing' .rdb file and asked if I wanted to proceed, knowing no files from this missing .rdb file would be referenced in the backup. I proceeded and the catalog rebuild is progressing at about 1,800MBs/minute. Once complete I'll run the Verification and see how it goes.
  3. Addendum: The last comment from Swish in this thread suggests the catalog rebuild fixes this verification problem. He/She also suggests Retrospect should handle this, apparently, grooming-related issue more gracefully. To which I must agree: http://forums.retrospect.com/index.php?/topic/147354-cant-verify-browse-or-restore-from-backup/
  4. Thanks for the reply, Lennart. Wondering then why the verification is having a problem with the missing .rdb files? Or again, perhaps a problem with the media. I'll do a catalog rebuild, then another verification. Perhaps that's where the 'Synchronization' is coming from.
  5. Hi, All, One of my clients has been using Retrospect 8 to backup their Server 2008 R2 box and seven Win 7 Pro 32 clients for a couple years now. Everything has been going well and previous file/folder recoveries (very few of them) were successful. Since I hadn't performed a Backup Set Verification in about a year, I initiated one and waited the estimated 4.5 hours for it to complete. Came back to have a look and noticed the Verification status showed as "Resynchronizing (this may take a while)." Indeed it is taking a while…now over 9 hours. A peek at the Verification session log shows 533,248 (and counting) entries as follows: Trouble reading: "1-Backup Set A" (74742972), error -102 ( trouble communicating) Additional error information for Disk Backup Set member "1-Backup Set A", Can't read to file F:\RetrospectDailyA\Retrospect\Backup Set A\1-Backup Set A\AA000417.rdb, error -1101 ( file/directory not found) I should note the above error repeats thousands of times for the same .rdb file (AA000417). There is also an error for AA000525 repeated thousands of times. Up to now, no other .rdb files are referenced in the Resynchronizing errors. Retrospect writes .rdb files sequentially, each being 614,408 KB in size. That said, the latest .rdb file is AA002527.rdb. So counting the rdb_del file also in this directory, there should be 2528 total files. There are 1576 .rdb files. Some 950 .rdb files are gone. Looking at the directory where these Backup Set files are stored indeed shows AA000417.rdb is missing. A further look shows various time periods within the disk Backup Set. This Backup Set is configured to auto-groom to 10 copies. I do see the effects of grooming on some of the .rdb files as their size varies from a few KBs to something close to the 614,408 KB max size of the other .rdb files. But the missing .rdb files??? I've never seen Retrospect completely groom-out/remove/delete .rdb files from a disk Backup Set. Not on Retrospect for Windows or for Mac. Never. So is it a media problem? Someone deleting .rdb files manually? There are a couple people tasked with rotating the backup media every week. And one of the Backup Sets is offsite when not in rotation. Both disk backup destinations are LaCie 2TB RAID Mirrors connected via USB 2.0 to an HP server, all new as of October 2012. The 'B' set is next to Verify. I'll update this entry after determining how the 'B' set looks. Thanks for your time. Steve
  6. Thanks for that, Lennart. I'd forgotten about the new LTO5 barcode labels. I'll order them today. We archive periodically to external hard drives and keep them offsite. Agreed on the cost of media. We've been buying LTO 5 tapes a few at a time until we had enough to completely replace one backup set + a few spares. Have you checked out LTO 6 tape prices yet?…currently about $70.00USD per tape. I expect this will come down as adoption increases but YIKES that's expensive.
  7. So we've sourced and installed our new LTO5 tape drives, which are working fine with the existing LTO4 tape media in our 80-slot tape library. I've now sourced sufficient LTO5 media to replace the existing LTO4 tapes in one of two backup sets in this library. My questions are: - Is it best to re-use the existing barcode labels on the LTO5 tapes? - Is it best to use new, un-used/referenced barcode labels on the LTO5 tapes? -OR- - Pull all of the LTO4 tapes from the backup set being upgraded to LTO5 and keep offsite as an archive - Create a new tape Media Set and Script, replace all of the LTO4 tapes with LTO5 and with new barcode labels I'm just trying to avoid freaking-out Retrospect's existing config and consume the least amount of time getting the new LTO5 tapes in place. Thanks for any suggestions. Steven
  8. That's exactly what I've done in one of my environments, Rod Lord. We have our 'legacy' Retrospect 6 tape archives and our 'new' Retrospect 10 disk-based backup and archives. We even have a second PowerPC Mac Mini already pre-configured should the Mac Mini running Retrospect 6 do a face-plant. Crazy as it may seem, of the 15+ years of DDS tape archives, about 4 times every year we pull something from the late 90s or early 2000s. It makes everyone SO happy, especially management and bean-counters.
  9. Unhappy to report the "Media Set 1 Verify" backup session did not continue to automatically pick an erased tape. It's sitting at 'Needs Media' right now with 20 pieces of erased media in the Library from which it can choose. Bummer.
  10. Thanks for the input, twickland. Happy to report after the rebuild of "Media Set 1 Verify," the estimated capacity for each LTO 4 tape is now 1.6TBs (the compressed theoretical maximum). I also loaded the last tape member in the set and started a backup session. The catalog was properly read and updated and, once the tape was filled, it automatically picked an erased LTO 4 tape and continued the backup. I'll know if automatic erased media selection will continue in about 5 hours. Fingers crossed. I'll report again if anything of note occurs with this or the "Media Set 2 Backup" media set. As you note, I expect some more drama when I gradually introduce LTO 5 tapes as we will soon install LTO 5 SAS tape drives in this Library.
  11. Thankful for Continued Improvement with each Retrospect Update

  12. For clarity, I'll name the two following media set references "Media Set 1 Verify" and "Media Set 2 Backup": I ran a routine Verify session on my LTO 4 tape media set "Media Set 1 Verify." Prior to this verification, each of the 8 tapes in the media set reported an estimated compressed capacity of 1.6TBs and had used between 850GBs and 990GBs per tape. All good for this LTO 4 media…so far. After the verification, which automatically picked and read each tape in the set during the process, the reported estimated compressed capacity now shows as 12.8TBs per tape. YIKES! I know Retrospect will always use each tape until full or to failure but I'm REALLY missing the ancient Retrospect 6 feature of being able to assign/override estimated capacity. Anybody got any ideas on how to get the estimated capacity back to 'normal?' I'm going to rebuild this catalog as 'Fast Catalog Rebuild' is selected for all my tape media sets. I'll report back once complete. A second issue which presented itself during this media verification: While "Media Set 1 Verify" was running, so was "Media Set 2 Backup," a different LTO 4 media set in this same T80 Library. Since upgrading to Retrospect 10.5.0, I've had to manually move an erased tape into an available drive when Retrospect showed the "Media Needed" icon and "Waiting for Media" message for both media sets on this Library. However, all of a sudden "Media Set 2 Backup" started properly picking the next erased media as each tape filled. It continued to do so until "Media Set 1 Verify" was complete. Then it reverted to it's previous 'manual tape insertion' requirement when the current tape was filled. Note that all tapes in this Library are LTO 4, are either already assigned/named for a given media set or are 'erased' and ready for use by any media set. I'm checking for drive and library firmware updates now to ensure they are current. The fun continues. -Steven
  13. Agreed, iCompute. I've noticed this as well. The saving grace for me is that instant Scan is disabled in the Retrospect Engine System Preference. In the Retrospect environments I manage, Instant Scan appears to remain set to Disabled in the Engine after incremental updates. Still the client update should honor existing settings.
×
×
  • Create New...