Jump to content
jhg

Upgrade to 7.5 from 7.0, snapshot problems

Recommended Posts

Yes, the file names are changing, but I do not think it is displaying file names. It looks to be displaying folder names.

 

It is still displaying Remaining: 3 files 6,392KB 00:01:30 sec

Share this post


Link to post
Share on other sites

If the file/folder names are changing then Retrospect is doing a copy of permissions. What happens if you turn off all the options to copy NTFS permissions from files and folders for workstations and servers?

Share this post


Link to post
Share on other sites

So if you can not turn this off while it is running, do you have any idea how long you expect that this will continue? Does it really make sense to turn this feature off? I have not had a successful backup of my system in quite some time and would like to make sure that turning this off will fix my issues. Also since it is a feature, I would prefer to have it on.

 

Not trying to be stubborn just trying to make sure I'm doing the right thing for the company.

 

Thanks again for all of your help.

Share this post


Link to post
Share on other sites

You typically leave it on for folders, but most users don't need file level security.

 

 

 

Share this post


Link to post
Share on other sites

So then should I leave it on for folders or turn them all off?

 

Also any idea on how long the current will last?

 

It is backing up my file server so it is kind of important to have permissions on it.

Share this post


Link to post
Share on other sites

I would leave it on for folders and off for files.

 

No idea how long it will take, the more files you have, the longer it could take.

 

You can always stop the backup and start it again with the new settings.

Share this post


Link to post
Share on other sites

I am going to try and shut off all of the security settings. 3 were on by default, files security for servers, folder security for servers, and folder security for workstations. I also am going to try and no verification on the files. I have been using thorough verification. They are scheduled to run every night at 5:00 PM EST. I have stopped the back up from yesterday. I will post more tomorrow with results.

 

Is there a difference between NT server and W2k3 server? This problem started when we changed our server from an old clunky NT box to a nice speedy rack mount server with W2k3.

Share this post


Link to post
Share on other sites

So the back up ran last night without a hitch. It took 13:56:49 sec to complete. I am going to turn on Media Verification and see if it will complete tonight. I will then step through the other options for NTFS permissions and try and see where it gets hung up.

 

Thanks Mr. Mayoff for all of you time and assistance on this issue.

 

Share this post


Link to post
Share on other sites

With media verification on the back up take 15.5 hours to complete. If I turn only folder permissions on the backup runs for more than 3 days. I did not let it complete. Is this an issue that can be addressed or is this just the nature of the beast?

Share this post


Link to post
Share on other sites

I have backed up really big servers, with millions of files and I have not seen the backup of folder permissions take 3 days. It seems really odd that this is happening.

 

Is this disk heavily fragmented?

 

What happens when you run this as a local backup instead of over the network?

Share this post


Link to post
Share on other sites

No, the disk is not heavily fragmented. I did a defrag before I started posting just in case that was the issue. I'm also now getting errors while copying data.

 

+ Normal backup using Backup at 3/11/2008 5:00 PM (Execution unit 1)

To Backup Set Tuesday-...

 

- 3/11/2008 5:00:01 PM: Copying Data (D:) on SERVER

TMemory: heap 59 1,214 K

virtual 11 156.5 M

commit 156.5 M

purgeable 0 zero K

Pool:pools, users 4 20

max allowed mem 614.0 M

max block size 8,192 K

total mem blocks 2 16.0 M

used mem blocks 1 8,192 K

file count, size 0 zero K

requested 70 77.8 M

purgeable 0 zero K

avail vm size 1,768,685,568 B

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

TMemory: heap 60 1,215 K

virtual 11 156.5 M

commit 156.5 M

purgeable 0 zero K

Pool:pools, users 4 20

max allowed mem 614.0 M

max block size 8,192 K

total mem blocks 2 16.0 M

used mem blocks 1 8,192 K

file count, size 0 zero K

requested 71 77.8 M

purgeable 0 zero K

avail vm size 1,768,685,568 B

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

TMemory: heap 51 742 K

virtual 13 202.5 M

commit 202.5 M

purgeable 0 zero K

Pool:pools, users 3 21

max allowed mem 614.0 M

max block size 8,192 K

total mem blocks 3 24.0 M

used mem blocks 2 16.0 M

file count, size 0 zero K

requested 64 123.3 M

purgeable 0 zero K

avail vm size 1,715,208,192 B

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

TMemory: heap 52 743 K

virtual 13 202.5 M

commit 202.5 M

purgeable 0 zero K

Pool:pools, users 3 21

max allowed mem 614.0 M

max block size 8,192 K

total mem blocks 3 24.0 M

used mem blocks 2 16.0 M

file count, size 0 zero K

requested 65 123.3 M

purgeable 0 zero K

avail vm size 1,715,208,192 B

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

TMemory: heap 39 515 K

virtual 5 205.0 M

commit 205.0 M

purgeable 0 zero K

Pool:pools, users 1 19

max allowed mem 614.0 M

max block size 8,192 K

total mem blocks 1 8,192 K

used mem blocks 1 8,192 K

file count, size 1 8,192 K

requested 44 128.7 M

purgeable 0 zero K

avail vm size 1,780,981,760 B

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

TMemory: heap 40 516 K

virtual 5 205.0 M

commit 205.0 M

purgeable 0 zero K

Pool:pools, users 1 19

max allowed mem 614.0 M

max block size 8,192 K

total mem blocks 1 8,192 K

used mem blocks 1 8,192 K

file count, size 1 8,192 K

requested 45 128.7 M

purgeable 0 zero K

avail vm size 1,780,981,760 B

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

File "D:\Support\RS\RS\Fire Drill Reports NEW\Main house\B Shift\1st Quarter\2008\1.3.08B MH.doc": can't read, error -1101 (file/directory not found)

3/12/2008 7:03:18 AM: Snapshot stored, 330.1 MB

3/12/2008 7:03:53 AM: Execution completed successfully

Remaining: 1 files, 345 KB

Completed: 790015 files, 170.0 GB

Performance: 224.3 MB/minute

Duration: 14:03:53 (01:08:03 idle/loading/preparing)

 

Share this post


Link to post
Share on other sites

224 MB/Minute for 790,000 files is not too strange, considering you probably have a lot of little files. Retrospect spent just over an hour doing scanning/matching/preparing and writing the snapshot. The rest of the time was used to actually copy data.

 

How much free space do you have on the C drive of the backup server?

Share this post


Link to post
Share on other sites

I had the same problem, and I found a workaround by reading another thread here. My workaround is posted here.

 

Basically, tell your ESET virus scanner to exclude scanning of C:\WINDOWS\setupapi.log, and the snapshot should immediately finish building.

 

If you don't have ESET, then perhaps this issue isn't specific to ESET virus scanners, in which case I suggest trying to exclude the aforementioned file from whatever virus solution you do use.

 

 

-Jeff

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

×