ArcServe 2000 - backing up only folder tree?

I agree about your test, it does look like the backup is containing folder only.

Test
1) Modify the backup and then under Options / Job Log (I don't remember version 2000 so it might be called something a little different) / check Log All Activity.

Now the job log will contain a list of all files and directories backed up.

2) create a test directory, create several directories under it and more directories under those. Now copy the ARCserve log directory into each of these. At this point we have a clean directory tree with no special permissions and containing all plain files. Now setup a test job to back that up and lets see if it fails to backup files there as well.

By the way here is the location for the latest ARCserve 2000 updates.
http://supportconnectw.ca.com/premium/storage/downloads/nt/2000/arc_eng_menu.asp

OK - I'll try when I have the opportunity.

I'm gonna try the database initialize too I think.  I don't know if it made 100% sense above.  
In case I didn't explain this right:  I took the nightly backup tape onto another [2nd] ArcServe server, merged it and restored.  It was folders/directory tree only when restored on the 2nd server.

You know, I noticed that the SQL databases backed up!  Everything else that was just an NTFS file/folder had the problem I described above.  But, the SQL stuff [via sql agent] worked properly [backup/restore]....hmmm.....

-z-

If the restore worked fine on the other server then yes that would point to a database problem.

To test it.
Copy the database directory except for the r*.* files to a different directory.
Initialize the database
or
Install ARCserve to a new system and then copy over this new database directory over the old one.

If it works then you have a DB problem and can either merge in any tapes you want to restore from or repair the old one by just copying it back.

Make sure the ARCserve Manager is closed and all the ARCserve services are stoped prior to copying the database.
The "R" files or the files that begin with the letter "R" in the database will be recreated when the Database Engine starts.

No, the restore to the 2nd ArcServe server did not work fine - it only found folders and no files too.
The backup actually occurs on the same server that ArcServe 2000 runs on.....just FYI. So it's not a network drive, its local.

I was going to run a "database initialize" on just "astpsdat" (holds all the session info) - - - - According to ArcServe it contains a majority of the database information and you'll still keep your media pool info when the initialize is done.

Hey - What are the r*.* files in the database directory? Why not them too?

FYI : I've been working with Veritas BackupExec for the past 18 months, so I'm a little "ArcServe rusty" - - - but prior to that I worked with ArcServe quite a bit. And now of course!

-thanks!
Z

* See my above post first *

The JOB LOG for my "simple test backup" of 1 folder I just made and stuck 3 tiny text files in it:
You'll see it doesn't report the 3 files to be copied below.

Report:

Total Directories........1
Total Files.................0
Total Skips................0

It reports "Backup Operation Successful" when done too.

Weird.

Run that job again and this time expand the view on the directory so that the files are listed and selected.
Lets see if it then backs them up or produces errors.

Reset the ARCserve System Account (ARCserve Server Admin), permissions on it might have changed.

Here's what I did:

0. Stop all engines
1. Copied [not moved] all \DATABASES files from the ArcServe directory to a temp area, except those beginning with r*.*

(Following your directions above - please double-check and make sure you wanted me to copy and not move any files out.
On second thought, if I moved the files out I likely couldn't restart the database engine)

2. Start engines.
3. Initialize database - do the default which is all databases.
4. Made a new job to backup 1 folder containing 3 text files.
5. Ran it.

It still only backed up the test folder only [no files]. During backup file selection, it does all my files in the tree structure.
When I go to do the restore by session, I only see the c:\test folder and there's no + sign to navigate underneath it.

The NTFS perms are "EVERYONE" has FULL ACCESS to this c:\test folder.

* I don't know what you mean by reset the system account *

The ARCserve System Account is set via the ARCserve Server Admin.

Try a backup of another system. This is to see if it is something in the system or ARCserve.

Run a Count or a Copy job to see if it has the same problem. If they do then you can install ARCserve on another system and do a copy or count of that one to see if it has the same problem.

If it is ARCserve I'd say uninstall and then do a clean re-install with the updates.

OK, next attempt is a COPY job.

I just tried backing up from a source drive that is on my network.  It worked.  I backed up 1 folder and 1 dozen files from a network share.

So why would it not work locally?  NTFS perms do not seem to be a problem.  I'll check the ArcServe system account too.

Copy did not work.....from C:\ to D:\  (just 1 small folder w/ 12 files in it)

I think the ArcServe Sys Acct is OK otherwise my backup from a network drive would not have worked.

I don't remember for sure if this worked in ARCserve 2000, but see if you can select the ARCserve server via network as if it was another system on the network. Another option on that would be to use the client agent.

Another way to test this is run a Copy job from another system.

Login to the ARCserve server under a different account and try it.

All this is to see if the problem is related to the current desktop environment.

Speaking of which if you have not tried it already restart the system and try it again.

I'm going to reboot tonight - the system can be taken down off hours.

Hopefully, all that I've done plus a reboot will work!

BTW: I tried a backup but selected my local C:\ from the network like you suggested but no go.

I can also try backing up some data from the flaky system.....but FROM my other arcserve instance that works.

I'll update you.  Thanks for all your help!!!!!

Over the weekend I rebooted the ArcServe 2000 server that is problematic.
It did not fix my problem. I'm surprised by that [and angry as a moose too].

I did have this ArcServe-server backup files from my desktop then restore them and it worked.  So I think ArcServe works.

ALSO : I had a remote machine with NT backuo try to backup/restore to the problematic machine and that worked.

So, it's like the precise combo of ArcServe 2000 and this specific machine blend to cause the problem.  

I did even re-install ArcServe SP4 before rebooting.  I know SP5 exists but I haven't been cleared to run that.

Unfortunately, since ArcServe and the tape drive are on the actual server I'm trying to backup, it's limiting.  If this was just a "backup server" then I'd have the freedom of reboots and just about anything I wanted to do.  But the server itself is frequently accessed by all employees.

Right now I'm going to run a few tests and weigh my options.  If there are any diagnostics you know that could pinpoint the problem, fire away!  I'm taking all suggestions.   Thanks!

--z--

As a further test you could try NT Backup locally to disk so it would not be necessary to restart the system to test it.

I wonder if you use just plain windows to copy a directory does it include the files?

Its just that ARCserve does not do direct disk access, it uses a windows API request to read the data. So it just comes back with what is being provided.

I can do a plain copy & paste of a folder from my C:\ to my D:\ on the server.  The files inside do copy over too.

NT backup does not find a tape device (I believe). I "inherited" this machine.  I see in device manager that the tape drive has a red x on it.  I think that was intentionally done.

Here's a list of what I've tried / found out:

SQL databases do backup with the job.
Registry backs up.
No files on C: or D: back up. (folders only)

From the problematic server, I can backup a network share on another machine and it works fine.
I can use NT backup on a remote machine and backup a share on the problematic server.

I can't find anything good on google.com or CA..............

Here's my LOG copied&pasted......I tried to back up 3 individual files from the root of C:\
It says it worked but it didn't.
-----------------------------------------

20050516 123900     23 Run Backup Job Now.
20050516 123900        BAOF: Allowed backup of open file C:\WINNT\system32\comsvcs.dll
20050516 123900     23 Start Backup Operation. (QUEUE=1, JOB=2)
20050516 123900     23 Description: Backup [EOS] to [GROUP0].
20050516 123900     23 Use media 09/12/02 11:30 PM, ID 68BB, sequence #1
20050516 123901     23 Source Directory: C:
20050516 123901     23 Back up Session 82 on Media 09/12/02 11:30 PM
20050516 123907        BAOF: Allowed backup of open file C:\Program Files\ComputerAssociates\ARCserve\TEMP\C7C.tmp
20050516 123908     23 Catalog File Backed Up
20050516 123908     23 1 Directories  0 Files (1 KB) Backed Up to Media.
20050516 123908     23 64 KB Written to Media.
20050516 123908     23 Elapsed Time: 6s
20050516 123908     23 Average Throughput: 640 KB/min
20050516 123908        [CAT] 09/12/02 11:30 PM [ID:68BB,SESSION:82] is merged.(files=0)
20050516 123920     23 ** Summary for Job **
20050516 123920     23 1 Sessions.
20050516 123920     23 1 Directories  0 Files (1 KB) Backed Up to Media.
20050516 123920     23 64 KB Written to Media.
20050516 123920     23 Elapsed Time: 6s
20050516 123920     23 Average Throughput: 640 KB/min
20050516 123920     23 Backup Operation Successful.

By the way : Running Utility -> Count actually works.  It calculates and shows the files.

OK, I don't have a good reason for this but I can not help but wonder why OFA sync'd a file if no files where backed up.

Disable OFA and try it again.

Perhaps some how OFA is the culprit. I never saw OFA do this so like I said above a don't have a good reason for it, but I also don't have anything else to recommend.

I'll try it.

Is this the line you mean?

BAOF: Allowed backup of open file C:\WINNT\system32\comsvcs.dll

I had no idea why is was bothering that particular .dll

No go.  I disabled BAOF but theh result was the same.

Yes it makes little sense that a dll would need to be sync'd.

Well I'm out of ideas, at least for now.

Then again, perhaps some kind of logging or monitoring utility will help to show what is happening.

From within ARCserve the Job Engine can be put in debug and the job log configured to log all activity.

From within Windows file auditing can be enabled so that the Event Viewer security log will get updated with events.

SysInternals.com has a few different utilties that might work for you.

ARCserve uses an OS API for the reading of the files, so it only has whatever is returned to it. There must be some kind of logging or utility that will catch what is going on.

* * SUCCESS * *

After too many hours of spinning my wheels, I've arrived with a solution!

This solution is definitely a keeper.  As it turns out, ArcServe 2000 uses BITS (the Background Intelligent Transfer Service).
There are also other applications that use the BITS service (SMS Advanced client for instance).

I don't have SMS client but when I looked at my "installed programs" on the server, I see that BITS 1.5 has been installed.  BINGO.

Microsoft KB Article 833180 tells me which REGISTRY KEY to look for and what to change it to.

This is 1 way to do the fix.  I believe ArcServe 2000 SP5 would do the same thing.  Also, I think a full removal and re-install of ArcServe would reset the registry key back to the preferred BITS settings.

DovidMichel, because you suggested both of those alternate solutions and worjed with me quite a bit, I am very thankful!....and pass the point to you.  Thanks.

-z-

Thanks for the points, but more important thanks for the solution.