Ramon88 Posted November 11, 2009 Report Share Posted November 11, 2009 I have a script that uses three Disk Backup Sets as a source. It transfers the most recent snapshot of each source to LTO4-tape. After the transfer of each source the tape rewinds and verification starts. So far so good... However after the process of verification of a single source is finished Retrospect ejects the tape followed by a request for (re)inserting the tape it just ejected... It continues the script after reinserting the tape. The script has been set up to eject after executing the (whole ?) script, but instead it ejects after processing each source. This is strange behaviour which prevents us from using auto eject after running this script. What logical purpose is served by ejecting after each source, while ergonomically one sets the script to eject after running the whole script!? Imho this is not correctly implemented in Retrospect's user interface. Is there a known workaround and can this illogical behaviour be fixed in a future update of Retrospect? Thanks. Retrospect used: Multi Server 7.6.123 Drive update and Hot Fix 7.6.2.101 OS: Windows Server 2008 R2 standard (x64) Tape drive: HP StorageWorks LTO-4 Ultrium 1760 SAS Internal Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 11, 2009 Report Share Posted November 11, 2009 Is there a known workaround and can this illogical behaviour be fixed in a future update of Retrospect? Workaround #1: uncheck the preference to eject tapes. Workaround #2 (the "real" way): get an autoloader. It will change your life. Really, it will. Russ Quote Link to comment Share on other sites More sharing options...
Ramon88 Posted November 11, 2009 Author Report Share Posted November 11, 2009 Hi Russ, Workaround #1 we already thought of *L* as we already switched back to that procedure right after this problem occurred. An autoloader isn't really in the stars for this application. And we only need to rotate six tapes. However, the main reason is security. Tapes for this application must be kept offsite as much as possible, and tapes may only be inserted in a drive* for the shortest feasible time needed. If it were up to me we would have bypassed tape altogether and use iSCSI based RAID HDD storage. We already do that, with the same data stored on geographically different locations, encrypted and all. But we are obliged to use tape as well. So far we had it nailed down completely, to find another small thing we need to work around. I actually feel Retrospect ejecting between sources to be a bug. It's not the end of the world, but it's annoying. Anyway thanks for your input. It's always appreciated. *) We are not allowed to use an autoloader, because the client deems this as an -online- storage device, which is in a way correct. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 11, 2009 Report Share Posted November 11, 2009 (edited) I actually feel Retrospect ejecting between sources to be a bug. It's not the end of the world, but it's annoying. I agree with you. Doubt that it will ever be fixed or changed. However, I think that most people with tape have moved to an autoloader. Really, it's the only way to do tape. For our firm's special needs (never reuse tapes, never delete files on purpose, need to be able to go back to any snapshot on any day back to the epoch to see what files were on any day), tape is the only way because the backup set history grows unbounded. I agree with you about the better way if you were starting over. A thought - what if you schedule a dummy script at the end, just to do one file or something, and have THAT script, and that script only, do the eject on completion? Russ Edited November 11, 2009 by Guest Quote Link to comment Share on other sites More sharing options...
Ramon88 Posted November 12, 2009 Author Report Share Posted November 12, 2009 A thought - what if you schedule a dummy script at the end, just to do one file or something, and have THAT script, and that script only, do the eject on completion? Well, we thought about that, but actually didn't try it yet. On first thought it seemed a bit problematic to trigger the right time for the eject procedure script as there is no good way to know when exactly the transfer script ended. However your tip made me rethink it and I believe one could trigger the script 'danger close' and it will be put in a waiting state by Retrospect because the target will still be in use. Would be great if one could trigger a script from within a script. Maybe that's already on their list as well. Anyway, let's hope EMC will correct this bug as well for the next update/major release... Unrelated question Russ, but do you use WORM tapes for your application? Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted November 12, 2009 Report Share Posted November 12, 2009 On first thought it seemed a bit problematic to trigger the right time for the eject procedure script as there is no good way to know when exactly the transfer script ended. However your tip made me rethink it and I believe one could trigger the script 'danger close' and it will be put in a waiting state by Retrospect because the target will still be in use. You are correct: The "eject" script can be scheduled one minute after the "real" script if you like, since it will wait for the tape drive to be available before actually running. But it would probably be better to schedule the "eject" script at the time the "real" script finishes at the earliest. If the "real" script is delayed, the "eject" script simply waits. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 12, 2009 Report Share Posted November 12, 2009 Unrelated question Russ, but do you use WORM tapes for your application? No. Ours isn't a HIPPA issue or anything like that. We are a law firm, and may get litigation discovery requests that might require us to know exactly what documents existed, in what form, on any given date. That's the reason for our requirement. It's not that we are prohibited from deleting anything, we just need to keep it around. In our particular field (patents and trademarks), patent cases last for a bit over 20 years, and trademark cases can last forever. However, there is not continual activity in each case, and it may be revisited only every five or ten years. So, if something accidentally gets deleted, you might not know for many years until the document is needed and, when it is needed, it is needed right away. That's another reason for our special requirements - nothing can ever be "archived". Hope that helps explain our needs. Russ Quote Link to comment Share on other sites More sharing options...
Ramon88 Posted November 13, 2009 Author Report Share Posted November 13, 2009 Well, we evaluated our options and figured we would need six of those eject scripts (because we run a script ever working day and one for the weekend (runs twice)). That would be a bit of a hassle. So we now run those scripts during working hours and insert and eject manually. At least that's what the systems engineer needs to do, but I figured he gets payed for doing that. *L* I guess we can't have it all. We'll keep our fingers crossed for the next update/incarnation of Retrospect. @ Russ > I understand. But would WORM not something desirable for your application? Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 13, 2009 Report Share Posted November 13, 2009 No, because, from what I have seen, the WORM tapes are not made as well - not designed for as many passes over the head. Something about differences in polishing, lubricants, etc. russ Quote Link to comment Share on other sites More sharing options...
jgowing Posted November 26, 2009 Report Share Posted November 26, 2009 I am having exactly the same issue, and support the idea that this must be bug. It just does not seem logical to eject a tape for each section of the script when the option is to eject at the END of the script. My issue is one of operator convenience. I want the Tape to Eject ONLY once the script is Finished, so the operator has a visual clue to remove the tape and insert the next one, without having to check Retrospect status screens etc. I suspect that Retrospect thinks that once it runs the verify the job is over. I am a great fan of separate verify scripts, they are very intelligent, and setting up ONE to runn once a day verifies all outstanding backup sets. I was thinking of turning off verify on my Transfer Job, and then run a separate verify job, with the Eject option enabled. Quote Link to comment Share on other sites More sharing options...
Ramon88 Posted November 26, 2009 Author Report Share Posted November 26, 2009 It's a conspiracy I tell you! EMC has been bribed by the autoloader-industry! ;-) Kidding aside, I'm hopeful Robin has already picked this one up for the development team. It is a really obvious error in logic and I deem EMC's team capable enough to get this right. Quote Link to comment Share on other sites More sharing options...
jgowing Posted December 9, 2009 Report Share Posted December 9, 2009 Well Here is my Workaround Turn off Verify in the BackupSet Transfer Script Set the script to run in a specific Execution Unit Create a Verify Script (With Eject) for the TapeSet Set it to run in the SAME Execution Unit, and schedule it to start say 20 mins after the Transfer job. The Verify will queue for as long as the transfer takes. As soon as it finishes, the Execution unit becomes available, the verify runs, the tape ejects. Voila!! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.