Jump to content
Richy_Boy

ok - so who has tried 7.7 build 325?

Recommended Posts

I will be trying the build distributed to me, but you need to keep in mind, the builds that are given to each customer are based on that customer's setup. It's not logically correct to judge the success of the build on the problems of one tailored setup.

 

We really shouldn't judge until the Retrospect team releases the patch they are ready to formally support, anwyay. To contract, 7.7 is fair game to criticize, since it is supposed to be a finished working product.

Share this post


Link to post
Share on other sites

Mr White, EMC have formally released a patched build on their download page. This is the build I'm enquiring about, not a customised patch that was sent to a customer.

 

http://www.retrospect.com/supportupdates/updates/

 

7.7 Retrospect 7.7.325 for Windows 64-bit Installer 2010-03-28 79 MB

 

7.7 Retrospect 7.7.325 for Windows 32-bit Installer 2010-03-28 77 MB

 

Build 208 was the last 7.7 version I installed than I had to roll out of for a number of reasons.

 

Rich

Edited by Guest

Share this post


Link to post
Share on other sites

Grooming was 4hrs faster last night! We'll see tonight if it resolves the Exchange 2003 mailbox issues we've had. We haven't backed up individual mailboxes in over 2 months due to 7.7 bugs, only the store itself.

Share this post


Link to post
Share on other sites

I was excited to see the update. I installed it, bumped my execution units back up to 4, and started 4 jobs. I ran for a couple of hours and then....

 

TMemory: heap 120 4,652 K

virtual 20 241.5 M

commit 233.5 M

purgeable 0 zero K

Pool:pools, users 7 17

max allowed mem 614.0 M

max block size 8,192 K

total mem blocks 6 48.0 M

used mem blocks 4 32.0 M

file count, size 0 zero K

requested 140 186.1 M

purgeable 0 zero K

avail vm size 1,170,460,672 B

TMemory::mhalloc: VirtualAlloc(256.0 M, MEM_RESERVE) failed, error 8

TMemory: heap 121 4,654 K

virtual 20 241.5 M

commit 241.5 M

purgeable 0 zero K

Pool:pools, users 7 17

max allowed mem 614.0 M

max block size 8,192 K

total mem blocks 6 48.0 M

used mem blocks 4 32.0 M

file count, size 0 zero K

requested 141 194.1 M

purgeable 0 zero K

avail vm size 1,170,460,672 B

TMemory::mhalloc: VirtualAlloc(256.0 M, MEM_RESERVE) failed, error 8

TMemory::SetSize: priority 2 failed from 128.0 M to 256.0 M

Assert occurred on 3/29/2010 at 3:31:39 PM

 

 

Still seeing the TMemory "assert" crash.

Share this post


Link to post
Share on other sites

It fixes my exchange problems.

 

Doesn't seem to fix the UAC issues and scheduled starts while retrospect application isn't running.

 

One thing at a time!

Share this post


Link to post
Share on other sites

Everything went off without a hitch. Of course, I was biting my nails during the first backup. :-/ Also, I backed up my config files before I started the installation, because I have had corruption problems with upgrades/updates in the past.

 

My issues with crashing were resolved with the last patch, but I still had the slow matching issue. I have not looked closely at the backups, but folks should watch the time it takes to do matching and their over all backup time. On the first run, my matching phase seemed at least a factor of 2 times faster, but the backups took about the same amount of time. This could simply be more data on the client though. I'll report back with something more meaningful after a few days.

 

Jeff

Share this post


Link to post
Share on other sites

Robin

 

Can you tell me why the free space on Drive C is a concern?

 

What is Retrospect doing with drive C when it runs?

Share this post


Link to post
Share on other sites

Retrospect caches data to the C: disk. You must have between 10 and 15 GB of free space on the C: disk for each execution unit you are running.

Share this post


Link to post
Share on other sites
Retrospect caches data to the C: disk. You must have between 10 and 15 GB of free space on the C: disk for each execution unit you are running.

 

Thanks for the info. I missed that. I was able to locate article #9577 in the KB which said as much as early as 2006.

Share this post


Link to post
Share on other sites

I changed the default temp directory from C:\WINDOWS\TEMP to G:\WINDOWS\TEMP and restarted Retrospect. I then started some jobs. I don't see any files populating there. I only see files in C:\Documents and Settings\Administrator.\Local Settings\Temp\1 They are called RetroMapper_XXXX.tmp, there appears to be one for each execution unit and they are all 8,192KB. Are these the cache files? If so why so small and why would you need 10-15GB of free space for each execution unit?

Share this post


Link to post
Share on other sites

Just got in this morning and checked out Retrospect. Even after moving the default Windows temp folder to a different disk I am still getting the TMemory assert crash when I use more than two execution units.

Share this post


Link to post
Share on other sites

Wouldn't you have to bounce the server for this new temp directory to be picked up?

 

So is it fair to say this build is also too unreliable to upgrade too?

 

Mayoff, any news if these 7.7 issues have shown up in testing and when will they be fixed?

 

I would like to use the software I paid you guys for...

 

Rich

Edited by Guest

Share this post


Link to post
Share on other sites
Just got in this morning and checked out Retrospect. Even after moving the default Windows temp folder to a different disk I am still getting the TMemory assert crash when I use more than two execution units.

 

It appears Retrospect is using the User Temp folder for the domain admin account rather than the System Temp folder. Try pointing the user environment variable for the account Retrospect is running under (Administrator. from your above post) to the new disk.

Share this post


Link to post
Share on other sites

Yes, I did reboot the server after changing the variable. I have now tried changing the location of the Temp directory for the logged in domain account. I restarted the jobs and we'll see how it goes.

Share this post


Link to post
Share on other sites

No dice. It just crashed again with the TMemory assertion error. I am now going to try deleting and recreating the config file. Unfortunately I will have to recreate all of my scripts and catalog files. If that doesn't work I guess I'll have to completely rebuild the server with a larger OS partition. I really need to be able to run more than 2 execution units.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×