Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Incremental backup: backup too big and files that are backed-up are not modified from last full backup

Created: 12 Jul 2013 | 8 comments
Angelo Maturi's picture

Hi,

this is my first post in the blog, so... hi to all.

I describe first the enviroment:

Master Server: Netbackup 7.5.0.6 on Windows 2008 R2.

Client Server: Virtual Machine (agentless) with raw device attached on Windows 2008 R2. We have mapped the raw device and we have a shared folder     created on.

The full backup is about 1.2 TB (scheduled once a week) and the incremental backups are approximately 280 GB (sceduled all afternoon). We don't have this movimentation of data, i think that the right size of incremental backup should be about 50 GB as max.

I have checked using the restore tools which files are backed-up, and in different days i see the same files in the backup. Files that have as last modified date 2012 or before.

We have disabled the antivirus too, but same story.

Could someone help me to understand?

ps: sorry for my elementary english.

 

Thanks

A.

Operating Systems:

Comments 8 CommentsJump to latest comment

Mark_Solutions's picture

If I understand you correctly you are running the backup as a VMWare policy type

The client has a raw device mapping mounted to it.

I am interested to know how large your backups actually are as when you perform this type of backup you backup the vmdk file which would not include the RDM area

In general you need to install a client on the server to back up the RDM areas

Do you actually see the expected full backup size when you go to the Backup Archive and Restore GUI and view each VMDK file?

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

Marianne's picture

Thanks for detailed info. Nothing wrong with your English (not my home language either!). 

Do you have 'Perform block level incremental backup'enabled in the policy? 

See http://www.symantec.com/docs/HOWTO44444

Verify that Changed Block Tracking is enabled for NBU user. See http://www.symantec.com/docs/TECH129738

Hope this helps...

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Angelo Maturi's picture

Thanks for the answer!

We are not using Vmware policy type. We read something about raw device on virtual machines that is not supported ( or something like that, but this is not our case).

We use a MS-Windows policy, we backup the shared folder like if it's a normal lun presented to a physical server. I have mentioned that it's a virtual server just to provide a complete description.

So consider that we are doing a normal backup of a folder used as shared area, that contains normal file, nothing of special.

Thanks!

A.

 

Mark_Solutions's picture

AH!

OK it  was the "agentless" part that got me - with you now.

Are the files that get backed up every day of any particular type?

I am thinking of things like PST files - never get "updated" and yet ever time Outlook opens they get "touched" and so back up during an incremental backup every day.

If there is nothing obvious we would probably need to increase the logging level for the bpbkar process and create a log folder for it on the client to see exactly what it is capturing and why

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

Angelo Maturi's picture

Oh sorry, it was my mistake about agentless... I was doing too many things togheter :)

The machine is a media server because we use, in the past, this machine to write on disk storage unit, but know works as a normal client (althought if it's registered as media server).

We don' t have pst files on the shared are and files that are stored are normal files (office, pdf, log files,binary etc).

I have created a bpbkar folder in the logs folder on nbu installation path.

Thanks!

A.

Mark_Solutions's picture

OK - the log will get big but you probably need to increase the logging level on the client to get most detail

Once you have the log after the next backup then zip it and attach it on here as an attachment

In the mean time do take a look through the actual backup job for the client (on the detailed status tab) to see if it actually reports anything during the backup - it may have some sort of rights issue preventing it resetting the archive bit on those files.

The alternative is to open up its host properties and set it to use the Timestamp rather than the archive bit

This is found under Client Host Properties - Windows Client - Client Settings

You could even use the Change Journal if it is enabled on the server

Hope this helps

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

smurphy's picture

One other easy thing to check:  Is your Incremental schedule inside the same policy as the Full schedule?
And did said Full schedule ever run successfully and whose image is not yet expired?

Steve Murphy
NetBackup Technical Support
_________________________________
http://go.symantec.com/nb