Unsolved

1 Message

628

December 10th, 2021 06:00

Cloning file server backup

Networker 19.1, Data Domain, and CloudBoost

I have a 5TB Windows file server VM that is being backed up as "full" backups on a weekly basis and "incremental" daily. These are VMware type backups and the backup target is a Dell Data Domain.

The savesets are being cloned to AWS via CloudBoost on a daily basis. The clone transfers 5TB every day even when an incremental is occurring -- Dell says this is because VMware savesets always clone as a full backup if they are sourced from a Data Domain. I suspect this is causing some problems with clones. 

What is the best practice for cloning a large file server drive from a Data Domain device to avoid these huge unnecessary transfers? Use a filesystem backup instead of VMware?

The person who normally handles these things left the company, so Networker is a bit new to me. Thanks

2.4K Posts

December 10th, 2021 08:00

I admit I have absolute no idea about CloudBoost but with respect to NW cloning, the facts are clear:

  -  Cloning will and can always be done per save set

        (a volume clone will just contain the clones save set of the source volume)

  -  Consequently, the size of a save set clone will always be the same as the one for the backup save set.

In other words: If you simply clone a 'small' (incremental) save set NW will just copy this object with the exact same size. You could also say: you can only clone what has been backed up.

Now - it could theoretically be that a scheduled incremental will become almost as big as a full but this is another story.

To get a clear picture about the size, may I suggest that you just check the size of all instances to the save set like:

  mminfo -q "ssid=your_ssid" -r "client,name,level,ssid,cloneid,sumsize(20),volume" -ot

 

December 12th, 2021 07:00

As DD and Cloudboost are both dedupe solutions, but how I understood it they are not doing things similar wrg to how data is being cloned. At least not with cloudboost 9.x at the time...

Unlike with DD that offers CCR (clone controlled replication) cloning between source and target DD, only sending the changed blocks, with Cloudboost to Cloudboost cloning all data needs to be actually read and send to the other cloudboost instance. Hence in our first cloud adventure, we replaced the cloudboost instance in favor of DDVE when cloning also was required.

Also we expected DD to dedupe better, giving further incentives to use DD instead. Initially DDVE was not yet possible in azure, but once it was, for us it was a no-brainer having much more experience with DD/DDVE than with cloudboost (also due to some issues we had not beong able to use the proxy setting in 9.x when ypu still had to use a webportal to manage a cloudboost instance and get the statistics and be abe to upgrade cloudboost.

There is a difference between what NW states is protected (the VM of 5TB in size as VM backups are virtual synthetic fulls where even if you do not backup anything or barely nothing since the previous backup) as it says nothing about how much data needs to be cloned.

It will not have to send all data, only the blocks the target DD does not yet have.

If you look at how much data is transferred in the last backup, it is ecpected that the clone also will have to send a similar amount, if indeed yo7 clone daily.

Because of that, a clone of multi TB's, would finish rather quickly and dedupe statisr8cs on target and source DD would be through the roof as NW will report all backup as a full backup.

The same is the case for other blockbased technologies like BBB backup. Also BBB incr. backups are reported as full backups, even if no data is even backed up.

When you look at ddboost in/out performance on DD end while the clone is running, you will not see the same speeds that NW reports about. In our case on NW we see at times GB/s speeds, while aon DD it will show much lower actual ingress speeds.

That's what makes dedupe also difficult at times to see how things actually do, as NW also does not show what a DD achieves (only after the fact reporting DD statistics).

So be aware how NW does things and how DD plays its part in that.

Also when deleting data within NW you might not actually cleanup anything or that much on DD end. So dealing with capacity or when a DD is starting to fill up, can be rather complex.

1 Rookie

 • 

38 Posts

December 24th, 2021 07:00

Before we get into clone issue. Could you please tell us the reason you have scheduled VProxy backups as weekly full.?

Vproxy backups are supposed to be Forever Incr. Networker Uses the previous backup and leverages changed block tracking to write only incremental blocks to a new backup that is independent of other backups.
Note: Since the backup is performed to Data Domain, the resulting backup on the target device is a new full backup because NetWorker uses Data Domain virtual synthetics technology to create a synthetic full backup. This type of backups are also referred to as forever incremental. NetWorker uses the DDBoost API to create the Virtual Synthetic full backups. Just after incremental backup to Data Domain boost device.

Every NVP backup is a full backup. There is no need to restore from the last full and subsequent incremental backups to reach the desired recovery point. After an initial full backup, only incremental backups are sent to the DD.

No Events found!

Top