-
- Novice
- Posts: 9
- Liked: never
- Joined: Jul 19, 2017 12:55 pm
- Contact:
ReFS Dedup/Compression/Compaction Rate
Hi!
I am using ReFS for my Backup Copy Jobs SOBR.
Now i want to migrate this Data to a new server with new disks.
I have the "Old" Win2016 Server with a SOBR with only one ReFS Extent
with a Capacity of 384 TB, Free 177 TB.
And i have the "New" Win2016 Server with a ReFS Drive with 300 TB.
Now i added the new drive to the SOBR and put the "Old" Extent into Maintenance Mode.
Then i started the Evac.
Unfortunately the Evac Process Failed.
For failed Evac Processes i got from the Support an alternate procedure, short summary:
* Disable Jobs that uses the "Old" Extent and put it in Maintenance Mode
* Copy Data manually from Old to New Extent
* Rename Folder on Old Extent and Enable it
* Rescan the SOBR
* Check the Backup Properties of the copied Jobs, if there are on the New Extent,
and no missing (Red X on Filename) Files
* Remove old Extent and enable Jobs again
Now, the copy process (robocopy) is running from Old to New Extent.
On the old Extent, i have used 206 TB on the ReFS Drive (Properties of Drive),
and 1,17 PB of Data on this Drive (Properties of Veeam-Folder),
that means a Compaction Rate of ~5,8.
On the new Extent, i have used 70 TB on the ReFS Drive (Properties of Drive) so far,
and 70 TB of Data on this Drive (Properties of Veeam-Folder),
that means NO Compaction!
Do i have to enable some kind of Dedup/Compression/Compaction on the new ReFS
drive?
The 1,17 PB of Data will not fit on the new 300 TB drive, if no compaction will happen.
Do you have any suggestion on this topic?
Thank you,
Fritz Pexa
I am using ReFS for my Backup Copy Jobs SOBR.
Now i want to migrate this Data to a new server with new disks.
I have the "Old" Win2016 Server with a SOBR with only one ReFS Extent
with a Capacity of 384 TB, Free 177 TB.
And i have the "New" Win2016 Server with a ReFS Drive with 300 TB.
Now i added the new drive to the SOBR and put the "Old" Extent into Maintenance Mode.
Then i started the Evac.
Unfortunately the Evac Process Failed.
For failed Evac Processes i got from the Support an alternate procedure, short summary:
* Disable Jobs that uses the "Old" Extent and put it in Maintenance Mode
* Copy Data manually from Old to New Extent
* Rename Folder on Old Extent and Enable it
* Rescan the SOBR
* Check the Backup Properties of the copied Jobs, if there are on the New Extent,
and no missing (Red X on Filename) Files
* Remove old Extent and enable Jobs again
Now, the copy process (robocopy) is running from Old to New Extent.
On the old Extent, i have used 206 TB on the ReFS Drive (Properties of Drive),
and 1,17 PB of Data on this Drive (Properties of Veeam-Folder),
that means a Compaction Rate of ~5,8.
On the new Extent, i have used 70 TB on the ReFS Drive (Properties of Drive) so far,
and 70 TB of Data on this Drive (Properties of Veeam-Folder),
that means NO Compaction!
Do i have to enable some kind of Dedup/Compression/Compaction on the new ReFS
drive?
The 1,17 PB of Data will not fit on the new 300 TB drive, if no compaction will happen.
Do you have any suggestion on this topic?
Thank you,
Fritz Pexa
-
- Service Provider
- Posts: 171
- Liked: 13 times
- Joined: Jun 29, 2013 12:14 pm
- Full Name: Peter Enoch
- Contact:
Re: ReFS Dedup/Compression/Compaction Rate
What your trying to do with REFS to move to another server or drive is currently as I understand not possible.
It’s not possible to recreate the block cloning with a move or copy.
It’s not possible to recreate the block cloning with a move or copy.
-
- Novice
- Posts: 9
- Liked: never
- Joined: Jul 19, 2017 12:55 pm
- Contact:
Re: ReFS Dedup/Compression/Compaction Rate
Hello!
Ok, that means, there is no possibility to use the "block cloning benefits" to a new
device
Any other suggestion?
Some kind of ReFS-Job to do a "manual" recheck for block cloning?
Thank you for your quick answer!
Fritz Pexa
Ok, that means, there is no possibility to use the "block cloning benefits" to a new
device
Any other suggestion?
Some kind of ReFS-Job to do a "manual" recheck for block cloning?
Thank you for your quick answer!
Fritz Pexa
-
- Service Provider
- Posts: 171
- Liked: 13 times
- Joined: Jun 29, 2013 12:14 pm
- Full Name: Peter Enoch
- Contact:
Re: ReFS Dedup/Compression/Compaction Rate
Currently as I read there is no way to recreate the block cloning on new device.
Veeam is aware of this and should be working on a way to move REFS data to new device.
Veeam is aware of this and should be working on a way to move REFS data to new device.
-
- Enthusiast
- Posts: 75
- Liked: 5 times
- Joined: Aug 08, 2018 10:19 am
- Contact:
Re: ReFS Dedup/Compression/Compaction Rate
Is Veeam working on a REFS-target aware move confirmed? Or is this a "I hope they are working on this because it seems so nice" kind of "should be working on a way"?enoch wrote:Veeam is aware of this and should be working on a way to move REFS data to new device.
-
- Service Provider
- Posts: 171
- Liked: 13 times
- Joined: Jun 29, 2013 12:14 pm
- Full Name: Peter Enoch
- Contact:
Re: ReFS Dedup/Compression/Compaction Rate
This is only something I heard, if it’s 100% true I cannot say. But it would maks sense.
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: ReFS Dedup/Compression/Compaction Rate
Not actively implementing yet, just planning for now.
Who is online
Users browsing this forum: No registered users and 53 guests