The most recent Data Domain release, DD OS 6.1.2, enhanced both the efficiency and cloud readiness of the Data Domain platform. This blog will focus on the efficiency improvements of this release, specifically when it comes to Data Domains Instant Access and Restore. So what is Instant Access? Instant Access is the ability to boot a VM directly from the Data Domain appliance. You simply find the VM you would like to access, power it on and connect to it. By doing this, you can decrease the downtime. If you need to perform a full restore, … READ MORE
|Update your feed preferences|
|Article Number: 524449||Article Version: 3||Article Type: Break Fix|
VxRail Appliance Family
VDP shows error: “There were no valid disks selected for backup. Only VM configuration files were backed up” when trying to backup a VM
VDP logs show:
2018-08-07T15:37:32.460-09:00 avvcbimage Warning <0000>: [IMG1002] Disk 2000 ([MARVIN-Virtual-SAN-Datastore-xxxxx/ABC.vmdk) has been intentionally excluded from backup
VM disk mode was set to “Independent – Persistent”. This disk mode doesn’t allow snapshots to be taken on the disk, and thus unsupported by VDP. You can check that from the VM settings as shown below:
1. Power off the affected VM (You may need to take a clone as a backup before proceeding).
2. Once powered off, change the disk mode on the affected VM to “Dependent”.
3. Power back on the VM, and retry the backups from the VDP plugin.
Refer to AvamarKB-468794
This document (7023339) is provided subject to the disclaimer at the end of this document.
PlateSpin Migrate 12.x and up
PlateSpin Protect 11.x and up
This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.
Actually i think you can’t do that. Here are the supported Dell EMC storages for Veeam 9.5 for backup based on storage snapshots.
For Dell EMC:
- Dell EMC VNX
- Dell EMC VNX2
- Dell EMC VNXe
You will need to do this only with direct SAN, but Veeam will create the snapshot in VMware and read the data directly from the storage. It is not necessary put the LUNs in read only mode, just present it to the veeam backup server after the veeam application is installed, Veeam will mark as read only automatically.
I hope this information helps you.
The recovery works with a granularity of a Consistency Group. This means that when all VMs in a CG would be recovered when performing a recover production and all VMs in a CG would be failed over upon failover.
When performing a test (and every recover activity starts with a test), it’s possible to prevent the power on of the replica VMs (there’s a checkbox in the test wizard for that) so that one or replica VMs in a CG can be powered on manually as needed.
To your final question, recover production is a different recovery action than a failover. Recover production is a restore so that in case there’s a need to bring up to production as fast as possible on the original production site (rather than brining it up on the replica site as prod like in failover), this would be the recovery action to do that. So, recover production revereses replication, once recovery is complete, the original replication direction is resumed and he production VM is started up. The replication roles doesn’t change as in failover.
Hope that helps,
Before I get into what is Block Based Backup, I would like to highlight what challenges our customers get into while backing up large file servers and how BBB can help. Data growth with servers having millions of files and then issues around backing them up, long backup windows, missed SLA’s etc are some of the very common examples.
Incremental backups do not solve this problem as they also take a long time as backup software has to look into the whole file system.
This imposes a business risk or production data for multi-million file systems. Another aspect to look into is that Index database or catalogs become huge and slow for protecting millions of files using traditional methods. Overlapping of backups, poor performance and business impact is what we get. This results in a very poor RPO (recovery point objective).
Why is the backup of millions of files slow?
Effect (millions of files)
- Slow backups
- Huge space required for the internal database of backup software
- Long recovery window
- Data loss -> far point to which we can recovery (RPO)
- Backups overlap user activities/business
- Users have poor performance during business hours
How NetWorker BBB resolves these challenges?
Block-based backup (BBB) is a technology where the backup application scans a volume or a disk in a file system and backs up all the blocks that are in use in the file system. Unlike the traditional file system backup, block-based backup supports high-performance backups with a predictable backup window.
BBB is supported on Linux and Windows, however, you need to verify compatibility of various versions, example RHEL, CENTOS is supported, however, Oracle Linux isn’t supported yet.
Block-based backups use the following technologies:
- The Volume Shadow Copy Service (VSS) snapshot capability on Windows and Logical Volume Manager (LVM) and Veritas Volume Manager (VxVM) on Linux to create consistent copies of the source volume for backups.
- The Virtual Hard Disk (VHDx), which is sparse, to back up data to the target device.
Block-based backups support only the following Client Direct enabled devices as target devices:
- Advanced File Type Devices (AFTDs)
- Data Domain devices (DDBOOST)
- Cloud Boost devices
The block-based incremental backups use the Change Block Tracking (CBT) driver to identify the changed blocks and back up only the changed blocks.
Block-based full and incremental backups are fast backups with reduced backup times because the backup process backs up only the occupied disk blocks and changed disk blocks respectively. Block-based backups can coexist with traditional backups.
Block-based backups provide instant access to the backups. The block-based backups enable you to mount the backups by using the same file systems that you used to back up the data.
Block-based backups provide the following capabilities:
- Mounting of a backup as a file system.
- Mounting of an incremental backup.
- Sparse backup support.
- Backups to disk-like devices.
- Backups of operating system-deduplicated file systems as source volumes on Windows.
- Forever virtual full backups to Data Domain.
- Data Domain retention lock.
- 38 incremental backups to AFTD and Cloud Boost devices.
- Synthetic full backups to AFTD and Cloud Boost devices.
- Backups of volumes up to 63 TB each.
- NetWorker-supported devices as secondary devices for backups.
- Recoveries from Data Domain without using CIFS share.
- Recovery of multiple save sets in a single operation.
- Setting parallel save streams if the target or destination is Data Domain.
For backup and recovery types, please consult NetWorker administration guide.
Supported OS: Windows and Linux. Only 64-bit architecture.
For Compatibility please check the online compatibility matrix
One example is Oracle Linux is not supported for BBB.
– New Technology File System (NTFS)
– Resilient File System (ReFS)
– Third extended file system (ext3)
– Fourth extended file system (ext4)
Block Based Backups (BBB) do not support the WINDOWS ROLES AND FEATURES save set.
For more details on supported configurations, and limitations please refer NetWorker administration guide.
- AFTD (Advanced File Type Devices)
- Data Domain CIFS and NFS
- DDBoost devices
There is one important information which you must consider before configuring BBB.
For block-based backups to succeed, ensure that you meet the following requirements:
- Create a separate pool.
- The pool must contain only one backup device.
- Perform all backups of a client to the same backup device.
If you want to make a local AFTD a Client Direct-enabled device, specify either the CIFS path or the NFS path in the Device access information field of the Create device properties dialog box.
Backup and Recover Architecture
Let us look a little deeper how it works
NetWorker reads the whole disk space as blocks (speeds up backup!)
- does NOT open/close files (speeds up backup!)
- does NOT write info about files into internal index databases (speeds up backup!)
NetWorker uses its own CBT (Change Block Tracking) mechanism to track changes on filesystem between backups, and how does it works is as follows
- NetWorker has CBT map of all blocks on disk
- The CBT map is set of bits
- Every bit corresponds to a single block on disk
- After the backup, all bits in the CBT map are set to „0”
- If the block on a disk is changed than NetWorker knows about it and set the corresponding bit in CBT map to „1”
CBT map is kept by NetWorker in memory, during incremental backup NetWorker reads only changed blocks, those which correspond to value 1.
NetWorker writes backups in native Windows format
- whole disk recovery
- single file recovery
How is CBT implemented in NetWorker?
Results are amazing, I have tested them in a LAB and in a few customer environments, and results were more than satisfactory.
Some FAQ’s around BBB
- Do we support the FAT32 file system?
No, backups fall to traditional method for FAT32 volumes.
- Does BBB support Distributed File System, DFS?
- Can the traditional backup and BBB co-exist?
Yes. You can backup a volume by separately using the traditional file system backup and the BBB. However, because of the inherent behavior of the backup, you cannot anchor or chain the save sets that you backed up by using the traditional file system backup to the save sets that you backed up by using the BBB or vice versa.
- In case of backup or recovery failure, what logs do I need to see for initial checks or reporting?
You can see the daemon.raw file for all the status related messages during backup or recovery.
You can see the following files to get a brief overview of the backup or recovery:
In case of a backup failure, see the savegroup log files in the following location
<NetWorker Installation Location>logssg<Group Name>
In case of a recovery failure, see the log files in the following location
<NetWorker Installation Location>logsBBB<Client Name><SSID>
Alternatively, NMC can be used for both the backup and recovery related logs.
- Do I need to restart the machine after installation? What if I do not reboot?
No. Reboot is not required for performing level full and level incremental backups
Note: First backup after a reboot is performed at level full and subsequent backups shall be at level incremental.
- How big can be source volume?
In NetWorker 9.x and above releases, the source volume can be up to 63 TB.
- How much space is consumed as part of the backup on the target device?
The size of the backed up data on the target device would be approximately 10% more than that of the data on the source device.
- Are index entries for the file system that is being backed up created? What does Index DB (CFI) store?
No, An index entry with the save set name is created for compatibility and is stored in the indexDB. The index entry is created with the namespace of ‘BBB’.
- How do I browse or perform a granular level recovery?
File level recovery can be performed by directly mounting the save set which is in the VHDx format. Once the save set is mounted it can be browsed as any regular file system. NMC can be used to search saveset and mount for browse and FLR or CLI can be used to perform this.
- Can BBB be performed at file/directory level?
No, you can perform BBB at volume level only. Volume mount points are supported.
- Can I perform client initiated block based backup?
Yes, you can perform client initiated backups of individual and multiple volumes. A new command line option -z is provided for performing client initiated block-based backups.
- How would the backup policy work? How many incremental backups can be taken before performing a level full again?
The respective group policy is enforced while performing a block based backup. If the target device is AFTD,
then you can perform 38 block based incremental backups only. If the count exceeds 38, the backup shifts to a level full backup.
If the target device is Data Domain, then we can perform forever incremental backups. Here VSF will treat them as
synthetic Full backups, VSF means Virtual Synthetic Full which is a feature of DDBoost.
- How do I know the current incremental level?
You can know the current incremental level from.
- A message that is logged for each backup.
- The BBB_LEVEL attribute of the mminfo -S output.
- How does BBB incremental backup work?
The filter driver tracks the changed blocks from the previous instance of a backup, and stores the information in system memory. During the incremental backup, the changed blocks are queried and backed up.
Note: Storing the changed blocks’ information in system memory does not have any performance impact. Restarting the machine results in a block-based full level backup because the changed blocks are not persistent
- What are the scenarios in which the level incremental backups shift to level full backup?
- You restart the client machine for any reason.
- When a new volume is added to the machine
- When there is a failure during an incremental backup
- When there is a change in the disk geometry, say the change in volume size either due to volume shrink or volume expand operations.
Note: EMC recommends you to perform a full level backup on a volume after de-fragmenting the volume
- When 38 incremental backups have been performed after a level full backup to an AFTD device.
- When an immediate previous incremental backup is deleted.
- What if I perform only level full backups to de-dupe targets like DD?
The data on the target device is deduplicated. Though the backup is triggered at full level, the actual data is very less.
So, the impact is minimal.
- How do I list only block based backup enabled save sets?
“mminfo -avot -q “ssattr=*BlockBasedBackup”
Note: The query option can be mixed with other query specs
To list the block-based virtual full backup save sets, run the following command:
mminfo -avot -q “ssattr=*BlockBased Virtual Full”
To list the block-based synthetic full backup save sets, run the following command:
mminfo -avot -q “ssattr=*Synthetic full”
- How do I list the CFI of Block based backup enabled save sets?
The following command can be given to listing the CFI of block based backup enabled save sets
“nsrinfo -n bbb <ClientName>”
Note: -n option is for namespace and BBB is the namespace value for block-based enabled save sets
Have a look at NetWorker Administration Guide for more details on backups and restores.
- Can we clone the data to Tapes?
Yes, data can be cloned to tape, however in case of a recovery data has to be re-cloned to DD or AFTD.
- Does BBB support staging?
- Is BBB I18N compliant?
- IPv6 Support?
- Does BBB support Data Domain devices over FC interface?
- Can the customer apply compress and encrypt ASM as the global directive?
No, it is not supported.
- Do BBB support volume managers and dynamic disks?
- What is the impact if my filesystem is highly fragmented?
There is no impact. BBB reads the used blocks in a single pass and is agnostic to the fragmentation
of the underneath file system.
- What will be backed up if I run -de-fragment?
De-fragmentation results in a huge number of changed blocks. This increases the incremental backup size though the data
has not changed much. Therefore, DEL EMC recommends you to perform full level backups after performing defragmentation
Note: There is no impact if you run the de-fragmentation before performing a full level backup.
- Will there be any impact if I have antivirus?
- Can BBB co-exist with SnapImage?
No, BBB replaces SnapImage on Windows platforms.
- Can i use VSS:*=OFF with BBB?
Hope it helps
Just wondering on the space used on a Data Domain when you do several backup of the same server in a short period of time.
Since a while (exactly from the 7 of June) we experiment an increase of the space used on our DD not in relation with data growing.
I discover that on the date where we had a capacity increased we had several manual launch of some backup.
What is “bizarre” is the fact that the capacity used on the DD seems to increase accordingly to the number of backups… (which is “acceptable” in case of traditional file level backup)
If you look at the number of backup version we have for the server “Server one” (as an example) you can see that on the 22 of June we had 5 backup of this server (don’t ask me why 5…) and every backup has a Data Domain copy (which is confirmed by the column AE of the Excel report.
I was expecting that with all CBT + Dedup and whatsoever optimization we will have just few blocks added and not the full disk.
(We are using Networker 220.127.116.11)
1) Is CBT an option to be setup on every VM (found an article on that). We are running vSphere 6.5 with vProxy.
2) Even if not activated, a Block Based Backup should do that for you ?
3) Will an Incremental backup not take only modified Blocks ?
3) And what is the role of DDBoost in that “party” ?
Any explanation or answers welcomed because EMC dosen’t want to give me a clear explanation how things are really working here…