Jump to content

jcapslock

Members
  • Content count

    40
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jcapslock

  • Rank
    Occasional Forum Poster
  1. Hi, we're working on testing our Exchange 2010 server restores. I've built an identical Exchange Server in a test network and created a mailbox database with the same name as the production database. I followed the instructions at this URL http://kb.roxio.com/...S=set-locale=en for preparation. When I look at its volumes on the backup server I can see the databases and the mailboxes. I added it to the appropriate AD groups. The restore warns that I will overwrite the database if a recovery database does not exist. I confirm. It starts restoring but does not go into the destination database. Instead it gets written into an identically named database file with edb extension under c:\programdata\retrospect client\rtrexec.dir\Exchange_Restore\ which is the wrong location and on the operating system drive which is not big enough to restore it so I can't even test mounting it after the fact. Is there something I'm missing here? Thanks, JC
  2. Anyone tried this yet? http://support.microsoft.com/kb/935634 I'm going to try it soon as this error is popping up more and more frequently. Same experience a full always works but differentials seem to fail every other week.
  3. Ok, make that three backup sets. But still not good.
  4. I cannot figure out what is going on here. I've been running 7.7 for a few months now and I get this problem even with the newest update. It will be running fine for several weeks and then out of the blue it will corrupt several catalogs. I get the error Can't access Backup Set , error -1101 ( file/directory not found). When I try to open the backup set it tells me the file cannot be found and I have to rebuild it. It happened again last night. Five corrupt backup sets out of 15. A record! I checked the logs for the night before. No problems. The backup server has not blue screened, or rebooted. In fact one thing 7.7 has been good for, for me anyway, is not crashing every few weeks. But it seems to have replaced that with corrupting catalogs. Catalogs are stored on a partition on a raid 5 configuration.
  5. BUMP Any plans for another bug fix soon? This is getting irritating. Also I believe I'm starting to have another issue that I read about, long match times. I came into work today and the backups that started Saturday night were still running with, supposedly, days remaining.
  6. Anyone heard any new news? I didn't notice this until today. Basically instead of marking all of the clients in the same script as busy it just says retry when it hits a client in the same script as one that is already executing and then short circuits the polling to start over from the top. I've tried manually deferring the client that causes it to short circuit and that doesn't help. It just ignores my deferral and does the same thing. We're running 64 bit Retrospect on 64-bit windows XP.
  7. Thanks to tomoy. He had the answer in our case. I noticed that the error was always occurring during the day before lunch and there were two scripts that are running during the day. I jotted down their settings, deleted them and recreated them. It was a pain but better than nuking the config and rebuilding. It has been running without fault for two weeks now, so I feel pretty safe in saying it saved the day. I don't understand why store the whole config in one binary file if it is so easily corruptible? I mean sure, blowing away the config would have solved my problems after creating a lot of headaches but its like solving a leaky roof by bulldozing your house and rebuilding.
  8. We currently have retrospect server on an XP machine but I had to configure two backup volumes because one volume would be larger than 2 terabytes which is not supported by XP. I'd like to reclaim one of the wasted drives by configuring one volume and I'm told Vista supports volumes larger than 2 terabyes. I'm assuming retrospect supports whatever volume size that Vista does but wanted to make sure before we go through the bother of upgrading OS. Thanks, JC
  9. Mayoff, Let me clarify. First I am not manually deleting MDB files, I am trying to groom them through the backup sets groom policy. I also am aware of the balance between full and differential backups. I have our system set up to do full backups of the Exchange server once a week on Friday and take differentials for the rest of the week. My intention is to only have 2-3 weeks of Exchange backups online. So after 2 weeks I have 1 full and 6 differentials for each of the 2 weeks. Now on the 3rd Friday I take another full. So now I have 3 full backups. On Saturday grooming does nothing, as I would expect since the oldest full cannot yet be deleted because of the differentials that depend on it. The next week though, I would expect that the grooming operation would eliminate all the differentials from the oldest week (Now 3 weeks old) and the full from that week since all of the differentials that depend on it have been groomed out and it is no longer necessary. Instead the differentials do get groomed out, but the fulls just keep stacking up and never go away unless I manually do the operation you mention above. I had 5 full backups stacked up but only the latest 2 had differentials as I would expect. Are my expectations just not matching up with the way Retrospect treats database grooming? I can do as you say, but it requires 3 times as many scripts and I just like to keep things as simple as possible. Thanks, Mark
  10. I am doing a full backup of the Exchange server once per week with differentials through the remainder of the week. I have the set configured to keep 14 backups. The differentials get groomed out properly, but the Fulls never go away, even after the last differential of the week that full was done in is groomed out. As a result I run out of space if I do not keep on top of it. Let me know if this is by design so I can write a batch file to delete full backups older than 2 weeks. Mark
  11. It seems to be running better now that I forgot and re-added the backup set. This did not work for one of the sets which seemed to be fixed by repairing its catalog. I would have restored the config from several weeks ago, except that I was pretty sure it was made before the last retrospect upgrade and I didn't know if it would be compatible or not. But that would have been my next move before rebuilding the config which would have been last resort for sure.
  12. Called phone support. They had me start a new configuration file with just one of the backup sets that is having trouble. I was able to groom it using a new config. They told me the solution will have to be to use a new config file, that the old file must be corrupt. I've been through that once before and it was not fun. So not wanting to spend the day doing that I instead put the old config back. I tried grooming the same set just for troubleshooting purposes and once again it got stuck in the waiting queue waiting for its backup set. I forgot the backup set. I then Reopened the backup set using the more option in the backup sets window. I then added it back to all the scripts that use it. I ran groom on it and now it is grooming. I ran groom on several of the other backup sets that also were stuck and they are running for some reason without going through any of that. Whatever. I'll update this if I have to do a full config file rebuild.
  13. Retrospect 7.5.387 Windows XP Backups are done to disk sets on a 2 terrabyte raid volume. This is the second weekend I have come in to find Retrospect showing all the groom jobs that are supposed to run Friday night waiting for their backup set, but the sets are not in use and there are no operations running on the executing tab. When I try to exit retrospect it says exiting and hangs there indefinately. When I shutdown and restart the server and open Retrospect it starts some sort of operation on the first backup set in the queue immediately. It says restoring snapshot for each snapshot like it is rebuilding the backup set. Once it has restored all snapshots it immediately starts the groom job for that set that was stuck. The rest of the groom jobs remain stuck in the queue still indicating that they are waiting for the backup set that they operate on. When I delete all of the remianing groom scripts from the queue the backup scripts that usually run Saturday night all start firing off. Why are all my groom operations thinking that the backup sets they operate on are in use? The only thing I can think of that may have changed is that I probably installed the latest Retrospect update a couple weeks ago. 7.5.387. Any help is appreciated.
  14. I have a large raid array. I want to move an online disk backup set at the end of the week to a new disk backup set on the same volume. Is there a time saving way to do this that does not involve hours of backup set transfers? The idea here is that I want two weeks of backups stored online. There seems to be no automatic way to redirect a proactive backups destination to a different set at the end of the week. So I thought instead I could always have proactives pointing at the same set and just move the data in the set to a new online at the end of the week. I've tried manually moving the files in command prompt thinking I could automate this in a batch file. But, of course, when I try to recatalog it will only allow me to recatalog using the original name of the set. Any other suggestions would be appreciated. Perhaps I am thinking of this in the wrong way. I was originally thinking to alternate the destination of the proactive scripts each week, but there seems to be no automatic way to do this, and I don't want to trust manually changing the destination. Thanks for any help you can provide. Mark
  15. I have an online disk backup set on a SATA raid drive called online. I would like to move that backup set to a backup set called last week at the end of the week, which resides on the same drive. The only way I can see to do this is to laborously transfer the backup set which seems takes hours and seens silly since the end result I want is an empty online backup set for the next week and a last week set on the same partition that looks like the online set. Is there an easier way to do this than to to use transfer backup sets? I am hoping for a method that I can perform from a batch file, maybe, that would simply move the files between directories as that is pretty much instantaneous when moving on the same partition. Then rename the backup set inside of the data files so that it can be recataloged using the correct set name. Anyone ever done anything like this? Is it possible? Thanks, JC
×