Forum Discussion
thanks again for any help
- davidmoline2 months agoLevel 6
Hi bc1410
First I trust you have accelerator enabled for this backup. This will greatly reduce the time to complete subsequent full (and incremental backups) as only the changed blocks are captured. This of course assumes that you are writing to a storage device capable of supporting accelerator (such as MSDP).
The reporting of VMware backups in the GUI is not entirely helpful, and you need to delve into the detailed messages for the backup to see what is happening. Although the backup is reporting 5TB, only the used blocks (200GB) will be captured and sent to storage, and then with with deduplication the data transferred will be less again. Review the last 10 or so lines from the detailed status for the job. For instance:
30/05/2024 7:03:44 PM - Info bpbkar (pid=2499385) accelerator sent 494618624 bytes out of 27686256640 bytes to server, optimization 98.2%
30/05/2024 7:03:44 PM - Info bpbkar (pid=2499385) bpbkar waited 120 times for empty buffer, delayed 114984 times, each delay is 1000 micro-seconds
30/05/2024 7:03:48 PM - Info XXXXX (pid=2499418) StorageServer=PureDisk:XXXXXX; Report=PDDO Stats (multi-threaded stream used) for (XXXXXX): scanned: 27040342 KB, CR sent: 256359 KB, CR sent over FC: 0 KB, dedup: 99.1%, cache disabled, where dedup space saving:98.1%, compression space saving:1.0%
30/05/2024 7:03:49 PM - Info XXXXX (pid=2499418) Using the media server to write NetBackup data for backup XXXXX_1717059614 to babmd1.bable.ad
30/05/2024 7:03:51 PM - Info bptm (pid=2499418) EXITING with status 0 <----------
30/05/2024 7:03:51 PM - Info XXXXX (pid=2499418) StorageServer=PureDisk:XXXXX; Report=PDDO Stats for (XXXXX): scanned: 179 KB, CR sent: 60 KB, CR sent over FC: 0 KB, dedup: 66.5%, cache disabled, where dedup space saving:3.4%, compression space saving:63.1%
30/05/2024 7:03:51 PM - Info bpbrm (pid=2499357) validating image for client XXXXX
30/05/2024 7:03:51 PM - Info bpbkar (pid=2499385) done. status: 0: the requested operation was successfully completed
30/05/2024 7:03:51 PM - end writing; write time: 0:03:33The backup has only had to transfer 500MB of 27G to complete the backup. The GUI still reports this as a 17GB backup (this is a differential incremental).
There is a setting to change how the backup size is reported (but I can't find it quickly).
As for the second question - you are correct, if there is no full backup then an incremental will effectively be a full backup (this goes for any backup type). Using accelerator, the Full backup of your large volume will take about the same amount of time that an incremental will, so no benefit to reducing the frequency of fulls.
Cheers
David- bc14102 months agoLevel 5
Hi davidmoline - thanks for the reply!!
We dont have accelerator enable since we dont use MSDP. Im not to familiar with the accelerator option but read you need to have MSDP which we dont use and the storage should not be to tape which it is - Our backups are written to tape. Is this accurate to say regarding the accelerator option?
Im thinking we may need to scale back the FULL level jobs for the VMs that have very large vmdks. This whole topic of very large vmdks just became active recently as I mentioned that they (storage/vmware admins) started migrating the RDM disks to vmdks not knowing that netbackup will take a long time to backup these new large vmdks..
I mean if we retain our FULL level jobs for 6 months is it safe to say to just run differentials on these VMs that have large vmdks. Maybe run a FULL level once a month instead of once a week. How would a restore play out? Would we still be able to perform a FULL VM restore.?
Thanks
BC
- davidmoline2 months agoLevel 6
Hi bc1410
Gawd - tape. Okay, then mostly ignore what I mentioned above (unless you can convince your management that some local MSDP to stage the backups before offloading to tape would help speed up the backups).
Anyway, I still believe even though the GUI shows the backup as the 5TB vmdk size, the actual tape used will only be 200TB - or the used space within the vmdk.
Certainly to answer your question, running a single monthly full backup may speed up the backup side, but the restore side could become a nightmare (especially if you lost one of the required incremental backups from tape). I would suggest not going down this path if you can avoid it.
If you can convince management to let you create MSDP, you may be able to utillise the old storage being migrated off to host an MSDP pool - it would not be a great idea to use the new SAN storage for this (hosting live data and backup data on the one array is a disaster waiting to happen).
Cheers
David
Related Content
- 5 years ago
- 12 years ago
- 4 years ago