Deduplicated Backups to Tape

[husetech]

Good Morning Everybody,

we are about to set up deduplication on our Backup Repositories.
How does a Disk to Tape Job behave regarding saving a deduduplicated Full Backup to Tape?
We basically do a Backup to Disk (Reverse Incremental) first, after that we copy the .VBK to Tape. Does Veeam copy the deduplicated .VBK to tape so that we will keep the Storage savings?
Could we face any problems regarding the Restore process?
Thanks in advance.

husetech

[PTide]

Hi,

Given that you refer to Veeam built-in deduplication, it will be stored as is, without inflation or modification, so you'll keep storage savings. There should be no problems with restores.

However, if you are referring to storage-based deduplication (DataDomain, Windows Deduplication etc), then the backup gets rehydrated before getting to tape.

Thanks

[husetech]

We are talking about a Windows Deduplication. By rehydrated you mean that the deduplicated Backup file will be duplicated before goint to tape?
In this case, why wouldn't it be possible to perform a backup to tape but to a backup to disk with WIN Dedup enabled?
And why would the VEEAM in-built dedup work, the data has to get rehydrated before going to tape here as well.

[PTide]

By rehydrated you mean that the deduplicated Backup file will get duplicated before goint to tape?

Right, backups will be full sized on the tape, but will stay deduped on the repo.

In this case, is there no other possibility to save storage when performing a backup from disk to tape?

Hardware compression on tape device might help (if your tape device supports it). Also you might want to switch to forward incremental backup method so you won't have to pull VBK to tape every time thus saving space on tape. What dedupe ratio do you get, and what is the VBK size?

Thanks

[husetech]

These are the Lines i edited in my post before:

In this case, why wouldn't it be possible to perform a backup to tape but to a backup to disk with WIN Dedup enabled?
And why would the VEEAM in-built dedup work, the data has to get rehydrated before going to tape here as well.

What dedupe ratio do you get, and what is the VBK size?

We transfer 14TB of Data to Tape, 7TB every Day which are the daily VBKs of our VMs. Another 7TB every Weekend which are our Weekly VBKs of our VMs.

Thus the idea of a Windows Data Deduplication (+ the VEEAM Inbuilt Dedup) which would decrease the transferable data from disk to tape about 70%.

[PTide]

In this case, why wouldn't it be possible to perform a backup to tape but to a backup to disk with WIN Dedup enabled?

Not sure that I get it right. Could you rephrase the question please?

And why would the VEEAM in-built dedup work, the data has to get rehydrated before going to tape here as well.

Veeam in-built deduplication occurs between internal data blocks of a backup file and is independent of the underlying storage, while Windows Deduplication works on a file system level.

We transfer 14TB of Data to Tape, 7TB every Day which are the daily VBKs of our VMs. Another 7TB every Weekend which are our Weekly VBKs of our VMs.

That's a lot. Why wouldn't you switch to forward incremental mode so you won't have to transfer full backup every time?

Thanks

[husetech]

Not sure that I get it right. Could you rephrase the question please?

You already answered it with your first answer:

Veeam in-built deduplication occurs between internal data blocks of a backup file and is independent of the underlying storage, while Windows Deduplication works on a file system level.

My thought was that the MetaData somehow gets written to the Tape as well so that we could use the deduped Files later on. This is apparently not the case and you explained why with the answer above.

Why wouldn't you switch to forward incremental mode so you won't have to transfer full backup every time?

That's the alternative we are probably going to use now.

Thank you for your help.

[DonZoomik]

Actually it would be nice if Tape jobs had the option to modify storage options (like Backup Copy). For example first repository is dedup based so jobs don't use compression and minimal dedupe. Later when moving jobs to Tape, we could recompress and re-dedupe them (if Veeam compression/dedup was better than hardware compression).

[husetech]

Since we are going to use Incremental Backup Strategie now I wonder if the following method works and Veeam supports it:
Until now we've had always two different backup Jobs, one for Daily and one for Weekly.
My attempt is to only have one Job for both:


Doing a normal Incremental Job and copying all the daily backups to tape, which will be our daily Backup to Tape. At Sunday we also copy the Daily Full Backup which is our weekly Backup at the same time.
So we would be able to restore every single day for the past 2 Weeks for examble, but we will keep the Full Backup for 4 Weeks so we can restore the last 4 Weeks. Is it possible to have Veeam delte the Incremental Backups older than 2 Weeks but keep the Full?

[skrause]

I run tape jobs once a month with the source being a Repository that has Windows Deduplication enabled. As long as the files you are putting on the tape are not older than the "file age to deduplicate" set in Windows, you will not see any performance impact on your tape speed.

If you are doing, say, a full+all increments once a week to tape then you will likely have a much slower tape run because the source "chunklets" from Windows Dedupe need to be rehydrated before they get put on tape. The process is not a full rehydration in the normal sense, the file is not expanded back out to its real size on disk, Windows just reads the individual chunklets from wherever they are and sends them. That leads to a lot of random reads which can be pretty slow.

I notice about a 50-60% performance penalty on my tape jobs when the source file has been processed by Windows Deduplication.

By default, Windows only dedupes files older than 3 days so if you are backing up to tape every day you should see little to no read/write penalty.