speleo14

I'm running Retrospect 14.5.0 on a Mac Pro; 2 tape libraries are attached to it via Thunderbolt port - Atto Thunderlink SH2068 - SAS. One is a Quantum Scalar i40 with 2 LTO-4 drives, the other a Quantum Scalar i80 with 2 LTO-6 drives. I have several media sets, all are bound to either the LTO-4 or the LTO-6 drives. It has now happened for the second time that Retrospect mixes up media set members between two media sets: – Media Set "ZM-ServerT-C" is bound to the LTO-4 drives and has 4 members (LTO-4 tapes): 1-ZM-ServerT-C = tape No. 0056 .... 4-ZM-ServerT-C = 0063 – Media Set "IEU-ServerT-E" is bound to the LTO-6 drives and has 16 members (LTO-6 tapes): 1-IEU-ServerT-E = tape No. 1022 ..... 16-IEU-ServerT-E = 1088 (you get the idea). A few days ago, Retrospect suddenly complained that it needs the media set member "18-IEU-ServerT-E" and that this would be tape No. 0063 – but tape No. 0063 belongs to set ZM-ServerT-C! When I checked the media set ZM-ServerT-C, there no longer is a tape number for the member 4-ZM-ServerT-C (which used to be 0063). So, tape number 0063 is now miraculously assigned to another media set (that is bound to a different tape drive), and tape 1088 appears nowhere... See also screenshots. Interestingly, when the backup scripts that use these two media sets are run, they actually want to write to the correct tapes, but they can only do so if these are in a tape drive. If the two tapes 0063 or 1088 are somewhere in their respective libraries, the backup script cannot find them - if I move a tape manually to a drive, the script will pick that up and start writing. How can that happen? And, more important, how can I reverse this? And how can I prevent that from happening again? I have already restarted the computer and both libraries, and tried switching back to an old Config80.dat file (about 1 week old), but to no avail.

I use no selection criteria, just the "All Files" rule. I haven't tried a Copy Media set... I have done a Verify on one of the tape media sets - it completed with no errors. This didn't really surprise me - files that are not there will not be verified, and obviously it didn't miss them, just as it didn't miss them when it failed to copy them. Meanwhile, I "tricked" the disk backup script into backing up the "RAID_GR" volume again by adding a new ACL to the RAID and then selecting "Use attribute modification date when matching" on the script. Then, I did again a "Copy Backup" to tape, and this time, it finished the whole 4.9TB. So I agree, something must have been wrong with the disk media set. Actually, there were indeed errors when backing up to the disk set... however, after these errors, the script finished successfully the copy process and started comparing (which I stopped, thus it says it only completed 171 files, but that was the Compare): - 06/04/17 17:43:26: Copying RAID_GR on ieu-fsgr 06/04/17 17:50:00: Found: 2255083 files, 86865 folders, 4.8 TB 06/04/17 17:50:04: Finished matching 06/04/17 17:50:18: Copying: 2255083 files (4.8 TB) and 0 hard links *File "RAID_GR/.....": can't read, error -1'101 (file/directory not found) [some file not found errors, but only a few files and not the ones missing later. Probably deleted by the user between the matching and the actual copy] [*] xopFlush: flush failed, error -102 (trouble communicating) [*] xopFlush: flush failed, error -102 (trouble communicating) !Trouble writing: "1-IEU-ServerD-EF" (498987008), error -102 (trouble communicating) !Trouble writing media: "1-IEU-ServerD-EF" error -102 (trouble communicating) 07/04/17 15:38:12: Building Snapshot... 07/04/17 15:38:12: Checking 86'865 folders for ACLs or extended attributes 07/04/17 15:40:44: Finished copying 86'860 folders with ACLs or extended attributes 07/04/17 15:40:54: Copying Snapshot: 2 files (705.4 MB) 07/04/17 15:41:01: Snapshot stored, 705.4 MB 07/04/17 15:41:01: Comparing RAID_GR on ieu-fsgr 07/04/17 15:41:20: Execution stopped by operator Remaining: 2'254'895 files, 4.8 TB Completed: 171 files, 447.3 MB Performance: 4'088.4 MB/minute (4'089 copy, 1'490.8 compare) Duration: 21:57:52 (01:20:54 idle/loading/preparing) 07/04/17 15:41:22: Execution stopped by operator Total performance: 4'094.2 MB/minute Total duration: 22:03:33 (01:21:43 idle/loading/preparing) [*] NetConnTop::PreDispose: m_deferredPackets.MaxCount=15944 Still strange that a restore from the disk backup worked OK, but not the Copy Backup script. My problem now is simply - how can I ever again trust the backups copied to tape - and is there anything else missing on the tapes? And if, how do I find out? There were no errors on the Copy Backup script, I just noticed by sheer chance that more than 2TB of data were left out (I analyzed the log because I wanted to find out about performance). Doing a full test restore from tape of all my servers at the moment, but still...

Hi all I am using Retrospect 14 to back up our servers with a disk-to-disk-to-tape strategy: I back up to disk and then use a "Copy Backup" script to copy the disk media set to tape. Recently, I did a full backup of all my servers using new media sets both on disk and on tape. The backups to disk went fine, but when I copied the data to tape, the snapshot transfer of one server was left half-finished, that is, only 2 TB of 4.9 TB on the disk were transferred to tape. No errors. It just stopped, and the remaining 2.9 TB were never copied afterwards Here's the log entry of the snapshot transfer: snapshot transfers: ndex/typeItemCount/srcCount=0/1/9,mdex/snapCount=5/9 RAID_GR (14/04/17 11:56:09) on Client "ieu-fsgr" - 21/04/17 10:17:57: Verifying IEU-ServerT-F - 21/04/17 14:47:16: Transferring from IEU-ServerD-EF 21/04/17 14:59:18: Execution completed successfully Remaining: 1'188'488 files, 2.9 TB Completed: 1'062'673 files, 2 TB Performance: 6'670.8 MB/minute Duration: 06:09:12 (00:50:10 idle/loading/preparing Now, when I try to restore "RAID_GR" from the tape media set "IEU-ServerT-F", Retrospect will throw endless "bad media set header found" errors. Restoring from the disk media set (that I still have) completes successfully without any error. Restoring a different server from the tape media "IEU-ServerT-F" set also works fine. What is more, I always copy my disk backup sets to 2 different tape media sets. And it's the same for both tape media sets, the snapshot of "RAID_GR" is not completely transferred. However, a bit more data is copied to this set (2.3TB compared to 2TB on the other set). Here's the log entry for the other tape media set: snapshot transfers: ndex/typeItemCount/srcCount=0/1/9,mdex/snapCount=5/9 RAID_GR (14/04/17 11:56:09) on Client "ieu-fsgr" - 21/04/17 05:36:17: Verifying IEU-ServerT-E - 21/04/17 11:56:48: Transferring from IEU-ServerD-EF 21/04/17 12:09:18: Execution completed successfully Remaining: 1'188'417 files, 2.6 TB Completed: 1'062'744 files, 2.3 TB Performance: 6'813.7 MB/minute Duration: 07:06:27 (01:09:27 idle/loading/preparing) I went through the whole log file to check if the other half of the data is copied later on, but no. Until today, it only ever copies small amounts of data, like I would expect with an incremental backup, so it actually really just never copied around 2 TB of data to tape! How can that happen? And what can I do? Should I fully back up "RAID_GR" to disk and then to tape again? But how can I do this without backing up all other servers again, too? I have about 30TB of data on my servers and doing a full backup all over again is not really what I want to do... I guess if I just create a new tape media set and copy the whole disk set to it, it will again leave out have the files of that particular snapshot... Or do a verify? Will this copy files that fail verification? If half of the files are simply not there, will "Verify" notice that? Any help is appreciated!

Update: In addition to the 2 tape drives, I had an external HD (LaCie d2, 4TB) attached via Thunderbolt to the Mac Pro, which somehow seemed to have an unstable connection (unmounted itself every few days). I have now connected this HD via USB instead of Thunderbolt, and ever since, the unmounting of the drive stopped and also the tapes seem to be shown & found correctly (keeping my fingers crossed). Note: I used 2 different external HDs, same brand & model as well as several different Thunderbolt cables and 2 different Mac Pros, and I always saw the same behaviour. Thus I don't think that the issue was with a faulty drive, cable or Thunderbolt bus, but rather the Thunderbolt connections to the HD and to the Atto Thunderlink somehow interfering (Thunderlink driver issue or Retrospect or OS??).

I recently moved my backup from an XServe with 10.6.8 (SAS PCI card) to a MacPro running 10.11, and now I'm having problems with Retrospect's connection to my tape libraries. My setup: MacPro Late 2013, Atto Thunderlink SH2068, Quantum Scalar i40 (LTO-4), Quantum Scalar i80 (LTO-6), each equipped with 2 tape drives. Mac OS 10.11.0, Retrospect 12.5.0. It now happens very often that, for example, LTO-4 tapes are shown in the LTO-6 library (I can see that by the barcode, using <1000 for LTO-4 and >1000 for LTO-6), sometimes the tapes are even "mixed", i.e. some tapes in the same library are LTO-4, some are LTO-6 - which of course they are not, it's just Retrospect wrongly showing them this way. Tapes are being shown as "in drive" when they are not, or a drive is shown as empty when it has a tape in it. When I try to initiate a scan, nothing happens, I need to restart retroengine or even the MacPro, often several times, to get Retrospect to pick up the tapes in my libraries correctly. Thus, my backups often stall because Retrospect doesn't find the appropriate tape to continue. I didn't have that problem before when still on the XServe. See attached screenshot: Slot 67 is shown as "in drive", whereas both drives are shown as "no media". As a matter of fact, there definitely IS a tape in slot 67, namely tape No. 1079 (according to the website of the tape library and checked physically). Any ideas? Thank you, Tina

I think I now finally found the culprit, and no, it was not the volume, but Instant Scan. This "backiing up far too much" started on a second client (backed up 700'000 files, 1.5 TB, and there's no way that many files could have changed, especially not duringe the weekend...). I turned off InstantScan on those two clients, and so far, backups are back to normal. Hope it stays this way. Anybody else having / had similar problems with InstantScan?

No, the trick with the attribute modification date didn't help. Still wants to back up everything. I have also checked the media set settings, and they are definitely on "no media action". Changed it to something else and back again to no avail. It seems that this behavior only happens on that one client and with one specific volume of that client. I added another client to that script for a test - works fine. Added another source on the same client, but on a different external drive - works fine. Added a new folder on the volume that shows the weird behavior - works fine... I guess I'll give it another (about the third) try and start a completely new script and completely new media set and do another full backup that will be taking 3 days (slow network). Thanks for trying to help. Edit: Just checked the volume with Disk Utility and it needs to be repaired. Well, that's new (checked that before, and it was fine)... but at least this would make sense.

I'll give this a try - though it doesn't explain why this only happens when a script is run automatically on schedule and not when I start it manually?

Hi there Simply can't find out what is wrong here... Retrospect 10.5.0 on Mac 10.6.8, Quantum Scalar i40 Tape Library; Client 10.0.0 (174) on Mac 10.8.2. I'm backing up an external Hard Drive with about 2TB of data. If I let the backup script run on schedule, it always tries to back up everything even after the initial full backup, i.e. the entire 2 TB (it tries because I then of course stop it). If I start the same script manually, it seems to do an incremental backup, that is, it will only back up some GB (I assume that these are the files that were changed since the last backup, but haven't checked). The same script used to work fine until a few weeks ago when this started happening. I created a new script with the same settings - same. I reinstalled the Retrospect client - same. Any ideas? Thanks, Tina