My Veritas VCB backups seem to be very large. I typical Differential backup, as I understand it, is based off your last full backup. Every backup after that backs up everything that has changed since the last full. So I would expect, depending on the amount of data that has actually changed day to day, each sequetial differential backup would be less than the original full but would grow in size each day until the next full takes place. The problem I seem to have is that every backup is essential the same size (give or take a few hundred meg) as the full. I have confirmed the client settings for the VCB proxy to use Time Stamps instead of Archive Bits.
Anyone have any ideas?
Are you mounting the VMs as a fullvm (vmdk) mount or a file level mount?
If you're doing a fullvm mount, then the vmdk file is copied as a monolithic file. That file will have a date and time consistent with the time the snapshot was taken.
Veritas will always see it as a new/changed file and back it up.
If you want to use Incremental or Differential backs, you must use a file-level mount.
You select whether it is a file or disk level mount using the command line options of the mount utility. use -t fullvm for a vmdk mount, or -t file for a file level mount. You'll need to check your pre-exec scripts to see which you're using.
Are the files that are being backed up a small number of .vmdk files, or do they look like the normal files you'd expect to see on a Windows server?
If there is a "letters" in the path - then you are doing file level backups.
There is a bug in VCB - so if you use ....\letters or .....\letters\C it will always do everything - even if you tell it to use incremental.
If you use ....\letters\C\* then it will correctly do incremental.
I suspect you could stick in a few paths - one for each drive letter - but I've not tried it.
Excellent!! I'll give that a try this afternoon.
One quick question though, any idea if I can use something like c:\mnt\servername\letters\* or do I have to break it down for each drive letter per VM?
The file level mounts work by creating an NTFS Junction point (similar to a Unix mount point) in the letters folder.
By default, Veritas won't traverse mount points / junction points in a backup job. I think that there is a check box in the advanced option of the backup job to permit this, so you may need to set that if you want to use letters\*
Explicitly specifying letters\C\*, letter\D\* is probably better and safer in the long term. If you use letters\*, and for some reason one drive mounts and the other does not, then your backup job will still show as 100% successful, because the backup job doesn't know that there's supposed to be a second drive.
I think that I'm a little confused by all this.
It was my understanding that VCB takes a snapshot of the live drive, and you then backup the snapshot.
After the backup is completed the snapshot is deleted.
If this is the case, then when Veritas comes along and clears the Archive flag on the files, this is only on the snapshotted filesystem, not the real system; the following day when the incremental comes along it will backup all the flags again, as the archive bit is still set.
I guess that you could use the 'using modified time' option, but I've never been too keen on this, as I've found that it's never been too reliable for me.
Correct - you can't use the default archive bit for incremental backups done with VCB.
Don't know about backup exec - but in the documentation for the Netbackup integration module - it clearly states that you need to change the default incremental setting from archive bit to journal (or something similar)
Your understanding is correct - I wasn't clear in my original post.
The Archive flag is an attribute of the "file". Despite having integration scripts, the backup software is not aware of anything to do with VMWare. So, for a fullvm disk mount, the backup software is only backing up one VMDK file. And that file's archive bit should always be set, because it was modified/created when the snapshot was taken.
For a file level mount, you're right: the snapshot will be taken and mounted. When a full or incremental backup is taken, the backup software may well try to clear the archive bit. But it's a read only mount, so it can't clear the flag. Even if it did, the backup snapshot is deleted, not merged, so the changes would never be written back to the original disk.
So, Dinny is correct - if your backup software supports journal/database type incremental or differential backups and you're using file-level mounts, you can do it. But you can't rely on the Archive bit on individual files or the disk file. It won't work.
Hope that clears things up,
we are using Backup Exec 12 and are experiencing the same problem. The differential backups seem to be coming accross as full backups. VCB is set up correctly as the file level backups and restore are working fine.
I have tried the suggestions in this post about selecting driectories letters/c/someting/. but it still doesn't seem to work.
I'm not sure if it VCB breaking things or backup exec not checking the time on the files?
Ideas on how to make Backup Exec 12 work in differential mode with VCB?
We have wrestled with this issue for some time now. Backup Exec is not quite at the enterprise level for doing what you are asking. It relies on the windows file system to tell it whats needs backing up.
This has been highlighted in previous posts on this thread. What I would say is that working sets are the only other option that Backup Exec offers. These use the date that a file has changed to highlight to the scanning engine in BE to include it in the job. We have found version 11d of BE to be a bit flaky in determining anything more than files altered that day so we have to run a working set job every day and if it misses or fails we need to consider running a full backup to cover the missed data.
For us we are only using VCB on the VMs and not any RDM and so within VCB full weeklys are enough. We do the data backups direct from the SAN on a daily basis.
The only other option we are considering is moving to an enterprise backup product.