05-13-2013 11:25 AM
I've been asking around and haven't found and answer yet so I want to ask the NBU community....If I have a policy setup on a master to write to an appliance and the fulls are not getting kicked off after the first time (unless I run a manual backup), and the diffs are running fine, is this a policy issue or is this the way de-duplication works. (Diffs acting as fulls.) The reason I ask is because I do see a diff starting the time a full backup is suppose to and didn't know if this was the way it was suppose to be.
I think not because the retention on the fulls are set to 34 days and if I do not get a new full before then, I would not be able to restore a server to its full state correct?
Please let me know.
Thank you,
05-13-2013 12:41 PM
Scheduling problems is normally caused by difference in our own interpretation of the schedules and NBU's interpretation of the schedules.
Please show us the policy config. On master server, run:
bppllist <policy-name> -U
Tell us when you have kicked off manual full backups.
05-13-2013 01:23 PM
I kicked off Full Manuals last week. 5th and 6th. They were suppose to run this weekend on the schedule. Diffs ran and Fulls didn't. Does this have anything to do with the accelerator and appliances. Will new fulls be ran with the diff schedules?
Policy: AIX_PROD_00_SUN
Policy: Appl_Dedup_8963
For security purposes I'm showing all just a snip of that output. The Appl_Dedup_8963 is a policy writing to an appliance.
Thank you,
05-13-2013 01:37 PM
We need to see the schedules section of bppllist output.
I cannot imagine any kind of security info contained in that part of the policy.
For the rest of policy output, it is perfectly fine if you want to replace hostnames with some generic names (e.g. Client1, ServerX, etc....)
05-13-2013 01:44 PM
What version of the appliance are you running?
If it is 2.5.1 there is a known performance issue that causes this and the fix is included in 2.5.2. At 2.5.2 there are a few other patches you will want to apply however to address other issues with that release.
http://www.symantec.com/docs/TECH203521
to resolve activity monitor issues.
http://www.symantec.com/docs/TECH205407
to resolve an issue with getting to many alerts.
http://www.symantec.com/docs/TECH204164
to resolve an issue with the webgui collecting and reporting hardware status.
Since applying 2.5.2 all my jobs kick off and run at the correct time.
05-13-2013 03:38 PM
We are running 2.5.1...
05-13-2013 03:42 PM
I confirmed. It is ok.
CLASS Appl_Dedup_8963 *NULL* 0 750000 0 *NULL*
NAMES
INFO 13 0 0 50000 *NULL* 0 0 2147483647 0 0 0 0 0 0 0 1 0 0 1360091654 3A749EE66FC811E28E370901BB4C5857 1 1 15 0 0 0 0 0 -1 0 0 0 0 0 0 3 0 184 0 0 1
KEY *NULL*
BCMD *NULL*
RCMD *NULL*
RES stu_disk_de08u8963 *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL*
POOL NetBackup NetBackup NetBackup NetBackup NetBackup NetBackup NetBackup NetBackup NetBackup NetBackup
FOE 0 0 0 0 0 0 0 0 0 0
SHAREGROUP *ANY*
DATACLASSIFICATION *NULL*
CLIENT de08wxxx0 Windows-x64 Windows2008 0 0 0 0 *NULL*
CLIENT de08wxxxx Windows-x64 Windows2008 0 0 0 0 *NULL*
CLIENT de08w9xxx-...Windows-x64 Windows2008 0 0 0 0 *NULL*
CLIENT de08w93xx-...Windows-x64 Windows2008 0 0 0 0 *NULL*
INCLUDE ALL_LOCAL_DRIVES
SCHED Full 0 1 604800 2 0 0 0 *NULL* 0 0 0 0 0 0 -1 0 0
SCHEDWIN 0 0 0 0 0 0 0 0 0 0 82800 89999 0 0
SCHEDRES *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL*
SCHEDPOOL *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL*
SCHEDRL 2 1 1 1 1 1 1 1 1 1
SCHEDFOE 0 0 0 0 0 0 0 0 0 0
SCHEDSG *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL*
SCHED Daily 1 1 86400 2 0 0 0 *NULL* 0 0 0 0 0 0 -1 0 0
SCHEDWIN 7200 36000 7200 36000 7200 36000 7200 36000 7200 36000 7200 36000 0 0
SCHEDRES *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL*
SCHEDPOOL *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL*
SCHEDRL 2 1 1 1 1 1 1 1 1 1
SCHEDFOE 0 0 0 0 0 0 0 0 0 0
SCHEDSG *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL* *NULL
I removed some of the clients from this and altered the naming but everything else is the same from the output.
Thank you.
05-13-2013 04:37 PM
You will need the patches mentioned above to resolve this.
Thanks
05-13-2013 08:13 PM
You forgot the '-U' to give us 'User readable' format....
PLEASE run 'bppllist <policy-name> -U' and post output.
05-14-2013 07:47 AM
Hi Marianne,
I did run the command with the -U. I will attemp it again and repost.
Thank you
05-14-2013 08:08 AM
You will clearly see the difference when 'user' version of the command is displayed.
Please remember that NBU is case sensitive - it must be uppercase U.
05-14-2013 08:38 AM
[root@dexxxxx admincmd]# ./bppllist Appl_Dedup_8963 -U <-----I added the master to the end of this last time............
------------------------------------------------------------
Policy Name: Appl_Dedup_8963
Policy Type: MS-Windows
Active: yes
Effective date: 02/05/2013 19:14:14
Backup network drvs: no
Collect TIR info: no
Mult. Data Streams: yes
Client Encrypt: no
Checkpoint: yes
Interval: 15
Policy Priority: 50000
Max Jobs/Policy: Unlimited
Disaster Recovery: 0
Collect BMR info: no
Residence: stu_disk_de08u8963
Volume Pool: NetBackup
Server Group: *ANY*
Keyword: (none specified)
Data Classification: -
Residence is Storage Lifecycle Policy: no
Application Discovery: no
Discovery Lifetime: 0 seconds
ASC Application and attributes: (none defined)
Granular Restore Info: no
Ignore Client Direct: no
Enable Metadata Indexing: no
Index server name: NULL
Use Accelerator: yes
HW/OS/Client: Windows-x64 Windows2008 dexxxxxxxx
Windows-x64 Windows2008 dexxxxxxxxxxxx
Include: ALL_LOCAL_DRIVES
Schedule: Full
Type: Full Backup
Frequency: every 7 days
Maximum MPX: 1
Synthetic: 0
Checksum Change Detection: 0
PFI Recovery: 0
Retention Level: 2 (34 days)
Number Copies: 1
Fail on Error: 0
Residence: (specific storage unit not required)
Volume Pool: (same as policy volume pool)
Server Group: (same as specified for policy)
Residence is Storage Lifecycle Policy: 0
Schedule indexing: 0
Daily Windows:
Friday 23:00:00 --> Saturday 23:59:59
Schedule: Daily
Type: Differential Incremental Backup
Frequency: every 1 day
Maximum MPX: 1
Synthetic: 0
Checksum Change Detection: 0
PFI Recovery: 0
Retention Level: 2 (34 days)
Number Copies: 1
Fail on Error: 0
Residence: (specific storage unit not required)
Volume Pool: (same as policy volume pool)
Server Group: (same as specified for policy)
Residence is Storage Lifecycle Policy: 0
Schedule indexing: 0
Daily Windows:
Sunday 02:00:00 --> Sunday 12:00:00
Monday 02:00:00 --> Monday 12:00:00
Tuesday 02:00:00 --> Tuesday 12:00:00
Wednesday 02:00:00 --> Wednesday 12:00:00
Thursday 02:00:00 --> Thursday 12:00:00
Friday 02:00:00 --> Friday 12:00:00
Thank you,
05-14-2013 10:52 AM
Let's have a good look at Weekly schedule:
Schedule: Full
Type: Full Backup
Frequency: every 7 days
Daily Windows:
Friday 23:00:00 --> Saturday 23:59:59
So, you kicked off manual backups on 5 and 6 May.
Friday night 23:00 arrives and NBU checks if a backup is due.
How often must a full backup run?
Every 7 days.
When did last back run?
Monday 6 May. (Just over 4 days ago.)
This means no backup is required (only every 7 days, remember.)
So, 7 days pass, but by now the backup window is closed.
Please remember that manual backups affects Frequency Schedule.
To overcome this 'problem', we can reduce frequency to ensure that manual backups do not affect the normal schedule.
We make the frequency slightly bigger than the backup window, e.g. in your instance, you can make it every 2 or 3 days. Because the window is only open from Friday night to Saturday night, backup can only be submitted during this time and will not run more often.
David Chapa's article about frequency backups explains it better that I can:
https://www-secure.symantec.com/connect/articles/netbackup-frequency-based-scheduling-1
So, reduce the frequency in the Weekly schedule to ensure that it will automatically run this coming Friday night.