02-05-2014 01:18 PM
I am playing with Accelerator on a 7.6.0.1 Master Server. I am backing up one server at this time with accelerator and I am going to a DataDomain. When I enabled Accelerator I noticed a difference in backup times, but still not seeing the complete benifit of Accelerator with the following information and errors.
not using change journal data for <F:\>: hard link or reparse point change detected
not using change journal data for enumeration for <F:\> but will use it for change detection
I enabled "Use Change Journal" under the client settings and recieved the same messages. Each time though I did get a successful backup. It was when I enabled the Accelerator Force Re-Scan I started having problems.
I began at that point to getting "Media Write Error (84)"
Removed the "Accelerator Force Re-Scan" and the 84 error went away, but backups are still not looking at the Change Journal on the Client.
Any help would be greatful.
Solved! Go to Solution.
02-06-2014 01:49 PM
Something sounds really wrong - if all you did was to add the diff schedule it makes no sense why your earlier backups with a retention of 1 month have dissapeared
You wont get rid of the Journal message as accelerator always checks to see if it can use it - but in view of what has gone on i would be inclined to create a new policy from scratch (do not copy the existing one) with all of the streams defined and you daily / weekly/ monthly schedules and run that one (disabling the other one)
The first time it runs it will create a new track log (as it is based on policy name) and run a "real" full backup.
The next full runs will use accelerator and incrementals will refer to the track log to assist them
See if that sorts it out for you as it sounds like something is really wrong somewhere
The only other thing i can think is that someone has expired some of the backups so removing the missing streams and causing accelerator not to work - but if you only actually see 2 jobs that that could not be the case either
Try the new policy and see how that goes over a week or two
02-05-2014 01:42 PM
The backup will not use the change journal if you do have hard links or reparse points on the client - the journal itself cannot track them and notes it - so when NetBackup queries it it is informed of that and declines to use it.
So it sounds like you cannot use the journal on that client (at least not always) : http://www.symantec.com/business/support/index?page=content&pmv=print&viewlocale=&id=HOWTO68492
As for the 84 error i doubt that is connected - just an issue when it does the full backup.
We would need more info about the job, when and where it fails and some logs - at least bkkar / bpbmr to start with
02-05-2014 01:54 PM
Some useful bits in this tech note too http://www.symantec.com/docs/TECH202796
Might be worth working through it as bpstsinfo -pi will return quite a bit of information
02-05-2014 02:36 PM
Greets OnRappell,
I would second the 84 errors as being a coincedence, however with 7.6 being released recently I would also recommend having a look at logs on the Data Domain (determine your DDOS version and see compatibility matrix) and replicate errors again then dive into the ddfs.info file on the data domain:
http://www.symantec.com/business/support/index?page=content&id=HOWTO59308
General 'consultancy' thing:
Accelerator is a great tool, however you need to understand the rate of change of your data on the client and determine whether its going to be useful for you; have a good look in the admin guide to ensure you're comfortable with using and understanding it, and how you're deploying your DD too. I never saw the need to use it and accelerator.
Errors:
Any errors in the Windows event manager?
I'm assuming (although I'm not really assuming) no other 84 errors are being seen writing to the DD from other hosts? Have you used it in anger with/without accelerator and multiple-hosts?
Lastly, http://www.symantec.com/business/support/index?page=content&id=TECH43243 - a good troubleshooting guide for 84's if you like good bedtime reading.
Good luck,
Billy.
02-06-2014 01:06 PM
It is weird that it happened only with the Re-scan option turned on. I did turn it off and was able to get successful backups.
Now when it comes to using Accelerator how is it affected by Multiple Streams? The server I am using for test has a parent job and then 4 child jobs: C:\, D:\, F:\, and Shadow Copy Components. First backup using Accelerator had all five jobs running. Now that it has been running a few days, all I see is Shadow Copy Components and D:\. When I go into the Backup, Restore application I only have those two drives available for restore. Does this mean that there was nothing changed for the NBU to backup and the only changes took place on those two entries?
02-06-2014 01:23 PM
Very strange that you only see two jobs running - it really should have all of the streams submitted as jobs and run, even if they back nothing up
But if you only see 2 directories in the BAR GUI it implies that you have no backups for the others!
What are you retention periods set to - just wondering if something has gone amiss somewhere
Otherwise the policy or track log may have become corrupted in some way
Let us know your retentions first just in case that is the issue.
Hve you changed the policy at all since you created it?
02-06-2014 01:34 PM
Retention Period is for 1month on Diffs and Full. 1 Year for monthly.
I added Diffs after I had created the policy.
02-06-2014 01:49 PM
Something sounds really wrong - if all you did was to add the diff schedule it makes no sense why your earlier backups with a retention of 1 month have dissapeared
You wont get rid of the Journal message as accelerator always checks to see if it can use it - but in view of what has gone on i would be inclined to create a new policy from scratch (do not copy the existing one) with all of the streams defined and you daily / weekly/ monthly schedules and run that one (disabling the other one)
The first time it runs it will create a new track log (as it is based on policy name) and run a "real" full backup.
The next full runs will use accelerator and incrementals will refer to the track log to assist them
See if that sorts it out for you as it sounds like something is really wrong somewhere
The only other thing i can think is that someone has expired some of the backups so removing the missing streams and causing accelerator not to work - but if you only actually see 2 jobs that that could not be the case either
Try the new policy and see how that goes over a week or two
02-06-2014 02:53 PM
"First backup using Accelerator had all five jobs running. Now that it has been running a few days, all I see is Shadow Copy Components and D:\."
--> If they data was backed up it would be there for recovery unless it has expired :) Did you verify you could see/restore the data in BAR for the 1st backup?
Back to basics: Ensure that this client is able to backup all the drives + Shadow Components without Accelerator in a standard policy with suitable retention levels to storage. Verify you can browse from BAR.
My next thought is how you've got your DD configured and what DDOS you're using? Is OST configured here? If so, revisit support for plugins and versions with Accelerator support. Verify with HCL and let us know how storage is configured.
Mappings files: not a bad idea verifying even though you're running 7.6.0.1 so arguably you have the latest: https://sort.symantec.com/checklist/install/nbu_device_mapping
Are the track logs created on the client? No space issues? *giggle* Check out (carefully) installationdir/NetBackup/Track/ and determine what directories are created (should reveal the volumes backed-up according to policy)
The original 84 errors: Please review ddfs.info log on the DD and as Mark asked: bpbrm (media) bpbkar (client) logs.
- Billy
02-07-2014 07:37 AM
I will be working through the suggestions today guys. Thanks a lot for all the help.
03-17-2014 06:45 AM
Hi,
I encounter the same problems. It seems the track_journal is corrupt. After deleting backup works fine. But I don't know what caused this.
- ruud
04-14-2014 04:27 AM
I solved my problem. We have an EMC DataDomain DD860.
One of the logs bptm or bpbrm on the master server showed errors for the dd860.
13:48:21.942 [22227] <16> 4037533:bptm:22227:fs-lin-bu01: [56D3:BE4A40] ddp_synthesize_file() failed, dst_offset[30148658688], flags[0], src_offset[0][30148658688], src_length[0][1024], checksum_type[0], done_len[0] Err: 5048-met the limit on t0 refs in an t1 segment
13:48:21.942 [22227] <16> 4037533:bptm:22227:fs-lin-bu01: /usr/openv/lib/ost-plugins/libstspiDataDomain.so:stspi_include_in_image_do STS_EPLUGIN [DDErrNo = 5048 (met the limit on t0 refs in an t1 segment)]
This is a known bug at EMC and is resolved by installing the latest DDOS 5.4.2.1
04-14-2014 04:33 AM
For backup with Accelerator on Windows failover cluster
https://www-secure.symantec.com/connect/articles/accelerator-backup-windows-cluster-systems