Replication to Dedupe appliance compression settings?

[davidb1234]

I am going to be replicating VMs from one data center off standard RAID spinning disk to a new PURE Storage all SSD array in another data center. I am wondering what replication settings to use for compression and deduplication. Can someone guide me? Something tells me these settings apply differently than when this is a backup job.

I just want to make sure to get the best deduplication and compression on the PURE when I transfer my production VMs to that data center.

[foggy]

You can leave inline deduplication enabled, as for compression, if your repository is set to decompress data prior to write it to the storage, you can use any compression level (typically, optimal is recommended), otherwise disable compression or set it to dedupe-friendly.

[davidb1234]

It is not a backup repository it is a replicaton job so it is a VMFS partition on the pURE that the VMs are landing on using NBD mode. Can I leave compression on then for the network data stream or will it end up putting compressed data on the vmfs partition on the PURE?

I am specifically talking about the advanced storage settings on a replicaiton job for Storage Optimization and Compression Level.

[foggy]

Mmm, storing replica VMs on a dedupe appliance is not a good practice, think of performance in case of DR. Basically, replicas are stored in native format, not deduplicated/compressed by Veeam B&R, so not much you can affect the dedupe rate on the storage. Replication jobs do not have inline deduplication settings, just compression, which is effective while data is transferred between source and target proxy servers only.

[davidb1234]

I don't know what you mean. I am just moving VMs from one data center to another using Veeam replication. They are being permanently moved. Once I replicate the VMs I am deleting the snapshots on them and they will become production VMs. Is this not a good process?

From what you are saying it sounds like the storage optimization setting on a replica job just doesn't do anything and that its OK to use compression.

[DaveWatkins]

Replication is designed to be used so you can keep a almost current backup version of the VM ready to power up should a site fail, not to migrate VM's. This is where the confusion is.

What you want to look at is one of the quick migration options, this is designed for moving actual VM's across datastores or hosts. However, you may find it just as easy to use storage vmotion

[foggy]

Replication can also be used in a migration scenario, it even provides a more flexible approach than using Quick Migration (think planned failover). Confusion from my side was caused by the fact that the OP mentioned dedupe appliance as a target, which made me think he was asking about backup copy jobs.

Storage optimization settings in replication jobs affect storing of replica metadata and amount of data transferred during incremental runs, but not how replica VMs are actually stored on target.

[davidb1234]

Thanks for all your help. You are indeed correct I am using replicas to time and plan the failovers. I need to change the IP, shut down the VM, perform 1 last replication run while the VM is offline then do a permanent failover. That is my plan at least and what I am testing. Thanks for clarifying the settings.

My failed over replicas will be running on PURE SSD for production once they are failed over.

[foggy]

You are indeed correct I am using replicas to time and plan the failovers. I need to change the IP, shut down the VM, perform 1 last replication run while the VM is offline then do a permanent failover. That is my plan at least and what I am testing.

Consider using planned failover, since it automates some of these operations. Also, you can specify Re-IP rules right in the replication job settings.