-
- Novice
- Posts: 4
- Liked: never
- Joined: Oct 03, 2017 1:44 pm
- Full Name: Ying Vang
- Contact:
Windows Server 2016 NTFS w/Dedup or ReFS
Hi,
I'm testing out the storage requirement between Veeam Dedup Only w/Windows 2016 Dedup on NTFS vs Veeam Dedup/Compression and ReFS on a small subset of my virtual environment. What I'm seeing at close to a 40% average storage savings with Windows 2016 Dedup over using Veeam Dedup/Compression with ReFS. I'm aware that both file system formats had issues the beginning of this year but seemed to have fixes presented that may have resolved these issues. For the Windows 2016 NTFS w/Dedup repo, I have applied KB4025334 and formatted with 64K /L. For the ReFS repo, I made sure to format the volume with 64K blocks. I have about 200 TB of data to backup up and plan to create 60 TB volumes in either NTFS or ReFS to satisfy that need. There's a lot of benefits to ReFS, however, the space savings with NTFS w/dedup seems too big to ignore. I plan on doing 1 full backup and have up to 29 days worth of incrementals for my primary backup rotation. I some concerns and would like to ask those who have large storage volumes and currently using Windows 2016 Dedup with Veeam the following questions:
1. What is the largest backup job set ( TB written to storage before Windows Dedup)?
2. How long does it take to merge the oldest incremental to the Full backup for that job?
3. Do you run a backup health check on that job, how long does it take on avg?
4. Do you run a defrag and compact for that job, how long does it take on avg?
5. Have you considered changing over to ReFS?
I'm testing out the storage requirement between Veeam Dedup Only w/Windows 2016 Dedup on NTFS vs Veeam Dedup/Compression and ReFS on a small subset of my virtual environment. What I'm seeing at close to a 40% average storage savings with Windows 2016 Dedup over using Veeam Dedup/Compression with ReFS. I'm aware that both file system formats had issues the beginning of this year but seemed to have fixes presented that may have resolved these issues. For the Windows 2016 NTFS w/Dedup repo, I have applied KB4025334 and formatted with 64K /L. For the ReFS repo, I made sure to format the volume with 64K blocks. I have about 200 TB of data to backup up and plan to create 60 TB volumes in either NTFS or ReFS to satisfy that need. There's a lot of benefits to ReFS, however, the space savings with NTFS w/dedup seems too big to ignore. I plan on doing 1 full backup and have up to 29 days worth of incrementals for my primary backup rotation. I some concerns and would like to ask those who have large storage volumes and currently using Windows 2016 Dedup with Veeam the following questions:
1. What is the largest backup job set ( TB written to storage before Windows Dedup)?
2. How long does it take to merge the oldest incremental to the Full backup for that job?
3. Do you run a backup health check on that job, how long does it take on avg?
4. Do you run a defrag and compact for that job, how long does it take on avg?
5. Have you considered changing over to ReFS?
-
- Veteran
- Posts: 385
- Liked: 39 times
- Joined: Oct 17, 2013 10:02 am
- Full Name: Mark
- Location: UK
- Contact:
Re: Windows Server 2016 NTFS w/Dedup or ReFS
I believe NTFS depude still doesn't work well with large VBKs that need transforming/merging. In testing your results will look good, but when your VBKs are 1TB or larger you may have issues.
-
- Novice
- Posts: 4
- Liked: never
- Joined: Oct 03, 2017 1:44 pm
- Full Name: Ying Vang
- Contact:
Re: Windows Server 2016 NTFS w/Dedup or ReFS
The Veeam repository are set to do per VM backups so the individual backup files so I do not get near the 1TB size as of yet.
-
- Novice
- Posts: 7
- Liked: never
- Joined: Jun 08, 2015 9:20 am
- Full Name: Patrick Beau
- Contact:
Re: Windows Server 2016 NTFS w/Dedup or ReFS
Hi,
from my point of view, you'll go in a hole.
My configuration is this one :
Backup server: Windows 2016 Server w/ 34*4To (SAS) + 2*400Go SSD (for Storage space write back cache), 160GB RAM, Dual 4 core server
It's cutted in:
- 80To REFS Dual parity 11 columns 2 groups. (+20GB SSD Cache)
- 10To NTFS Dual parity 11 columns. (+10GB SSD Cache)
Note: each repository is per vm file.
The 80To REFS is the main backup repository: everything backup's in. 18To to backup are splitted in 4 jobs. Each job have a one week Active Synthetical full backup accelerated with REFS and not using a lot of space. Another day in the week there is a file check. Once a month there is a Active Full backup Job (which eat space but I do not mind). I have 500GB a day of data moving: I can keep around 45 days.
Once a day, there is a copy job of long time retention data (aka files servers only) which copy those VMs (2TB pure data, 50GB a day moving) to the NTFS volume. Deduplication is activated on it. 70TB of data are in 10TB and 7TB are free. (96% deduplication cost saving). The process is one day and a half each 4 days.
This setup is the best performing setup that I've found, since I've tested a lot of things to have more data.
from my point of view, you'll go in a hole.
My configuration is this one :
Backup server: Windows 2016 Server w/ 34*4To (SAS) + 2*400Go SSD (for Storage space write back cache), 160GB RAM, Dual 4 core server
It's cutted in:
- 80To REFS Dual parity 11 columns 2 groups. (+20GB SSD Cache)
- 10To NTFS Dual parity 11 columns. (+10GB SSD Cache)
Note: each repository is per vm file.
The 80To REFS is the main backup repository: everything backup's in. 18To to backup are splitted in 4 jobs. Each job have a one week Active Synthetical full backup accelerated with REFS and not using a lot of space. Another day in the week there is a file check. Once a month there is a Active Full backup Job (which eat space but I do not mind). I have 500GB a day of data moving: I can keep around 45 days.
Once a day, there is a copy job of long time retention data (aka files servers only) which copy those VMs (2TB pure data, 50GB a day moving) to the NTFS volume. Deduplication is activated on it. 70TB of data are in 10TB and 7TB are free. (96% deduplication cost saving). The process is one day and a half each 4 days.
This setup is the best performing setup that I've found, since I've tested a lot of things to have more data.
-
- Veteran
- Posts: 385
- Liked: 39 times
- Joined: Oct 17, 2013 10:02 am
- Full Name: Mark
- Location: UK
- Contact:
Re: Windows Server 2016 NTFS w/Dedup or ReFS
Patrick, on your copy job, have you reached the retention yet so that the copy job has to manipulate the original 2TB file? As this is where I came unstuck because it was all going well, with good de-duplication until the day came that the older restore points had to be removed and original big file had to be transformed. It then failed and my restore points kept growing until I scrapped it and started again without dedupe. This was a long time ago though, when 2012R2 first came out so things may have changed.
-
- Novice
- Posts: 4
- Liked: never
- Joined: Oct 03, 2017 1:44 pm
- Full Name: Ying Vang
- Contact:
Re: Windows Server 2016 NTFS w/Dedup or ReFS
I recently got the Windows 2016 Insider's edition and currently testing out the ReFS w/Dedup. My testing size is limited but here's how it pans out.
Full Backup stats:
Total Data Processed: 3481.60 GB
Total Data read: 2150.40 GB
Total Data transferred to ReFS w/Dedup storage volume: 2048 GB
Storage used against different type of dedup and compression settings for a single FULL backup:
(veeam backup copy job) After Veeam Compression/Dedup with ReFS: 865.89 GB
(veeam backup job) After Veeam No Compression w/Dedup and Windows Dedup on ReFS: 545.90 GB
(veeam backup copy job) After Veeam No Compression w/Dedup and Windows Dedup on NTFS: 538.63 GB
My production environment requires at a minimum of 200 TB to process, so doing more than Active full will be time and storage prohibitive, but seeing that Dedup will eventually be available for ReFS now has me leaning backup to ReFS as my primary backup storage format. I'll be getting in a Cisco s3260 storage server with 288TB (48 x 6GB NL-SAS drives) soon, so I'll have to see how well that performs against the NetApp that I'm currently testing against with.
Full Backup stats:
Total Data Processed: 3481.60 GB
Total Data read: 2150.40 GB
Total Data transferred to ReFS w/Dedup storage volume: 2048 GB
Storage used against different type of dedup and compression settings for a single FULL backup:
(veeam backup copy job) After Veeam Compression/Dedup with ReFS: 865.89 GB
(veeam backup job) After Veeam No Compression w/Dedup and Windows Dedup on ReFS: 545.90 GB
(veeam backup copy job) After Veeam No Compression w/Dedup and Windows Dedup on NTFS: 538.63 GB
My production environment requires at a minimum of 200 TB to process, so doing more than Active full will be time and storage prohibitive, but seeing that Dedup will eventually be available for ReFS now has me leaning backup to ReFS as my primary backup storage format. I'll be getting in a Cisco s3260 storage server with 288TB (48 x 6GB NL-SAS drives) soon, so I'll have to see how well that performs against the NetApp that I'm currently testing against with.
-
- Novice
- Posts: 7
- Liked: never
- Joined: Jun 08, 2015 9:20 am
- Full Name: Patrick Beau
- Contact:
Re: Windows Server 2016 NTFS w/Dedup or ReFS
Lando_uk, Files are 500GB+ around for 4 VMs: 2To is the sum of those.
Windows 2016 Deduplication is far better than 2012R2 one one huge amount of data, but when 50-60TB is reached, it's time intensive: mine only work each 4 day, and is during for 36 hours around.
By the way retention is not reached since it's around 2 years But since i'm doing Weekly and Monthly syntethic full, there is no problem with old file deletion: there i no VBK manipulation.
Windows 2016 Deduplication is far better than 2012R2 one one huge amount of data, but when 50-60TB is reached, it's time intensive: mine only work each 4 day, and is during for 36 hours around.
By the way retention is not reached since it's around 2 years But since i'm doing Weekly and Monthly syntethic full, there is no problem with old file deletion: there i no VBK manipulation.
Who is online
Users browsing this forum: Bing [Bot] and 95 guests