- Posts: 61
- Liked: 10 times
- Joined: Mar 01, 2010 5:57 pm
- Full Name: Glenn Santa Cruz
1. Can we "map" properties for a replicated VM? For example, our Production Datacenter has different network labels than our Disaster Recovery site ; with esXpress, we "replicate" (successive restore) only the VMDK files (after having initially replicated the VMX and then manually modifying the resulting VM properties to reflect the "new" environment). This allows for customization of the target environment without affecting the "guts" of the Virtual Machine itself ( all the VMDKs )
2. Speaking of "mapping" VM properties in replication, I know Veeam does not yet offer the feature to replicate individual VMDK files to particular datastores in the target environment. From what I can tell, this has been requested a few times, and *might* be slated for an upcoming release, and that a hack workaround using symlinks is possible. Again, this is a feature of esxpress (although you must manually configure this) that we are currently using and believe it is a sorely needed feature of Veeam. Frankly I'm surprised this doesn't exist.
3. Soft-stop VMs prior to snapshot. In the event that VSS cannot be leveraged to properly prepare a guest OS for backup ( think of Linux ), the feature to shutdown a VM prior to backup is quite nice. The point here is to allow for a graceful shutdown, followed immediately by a snapshot, then a startup; the backup then runs against the "cold" snapshot, ensuring a consistent state of the VM. Total downtime for the VM is a few minutes. Perhaps something similar could be achieved with the "pre/post" scripts -- has anyone done this already and can share experience?
4. WAN throttling for replication. It appears that most of the replication posts are focused on "in-building" replication or replication between nodes that have a high speed interconnect. For the rest of us with remote datacenters / DR sites connected with "small" 10Mbit pipes, that WAN is very important. Yes, we could achieve traffic shaping with an external appliance or routing gear, but to have it "baked" into the product would be a wonderful feature. Especially if you include time-of-day scheduling ( X Mbps between 8am - 5pm ; Y Mbps between 5pm and 11pm ; Z Mbps Sat/Sun ; etc. )
5. Failover backup targets - another important esXpress feature is that a given backup can "failover" to multiple backup targets (all configurable). For instance, the primary backup target could be an NFS mount point in a Linux server ; if that server were offline (or ran out of storage, etc.), a secondary (or tertiary) target could be defined and the backup would automatically fail over to that location. Clearly one of the key reasons that esXpress can do this is their technique of providing non-catalog-required backups ( each backup can live "anywhere" in the network, and each backup makes reference to a "parent" backup by naming convention. ) Their philosophy (to my understanding) is that they provide a very specific naming convention to all backups, and from this convention they can successfully "index/catalog" all available backup files to present a list of available restorations to the end-user. Again, I realize this may be a competing philosophy to Veeam, but having a failover target I think is still quite important.
6. I second (or third) many of the feature requests listed from http://www.veeam.com/forums/viewtopic.php?f=2&t=2881
7. Great product - great forums - I think you guys certainly demonstrate a polished product and a clear commitment to fulfilling your user needs. I'm looking forward to further evaluation and hope the above points can be addressed soon.
- Chief Product Officer
- Posts: 30853
- Liked: 6347 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
1. Right now this is not possible as our replication is fully automated. It is also true replication vs. restore from backup as in case with esXpress. Ability to customize target replica is in the roadmap though, there are a few other requests besides network customization and we plan to deliver them all at once as this would take reworking some parts of the replication wizard.
2. Yes, this is one of the other features I was referring to in the previous bullet actually
3. Yes, most people are using pre-freeze and post-thaw scripts for this. You can find some on forum, for example for Oracle. One of our SEs had also written a whitepaper about MySQL backups recently, this also has script samples - if you are interested, you can request this WP through your sales rep.
We will also some have one new and unique feature in the next release that will really help with hot Linux backups, but I cannot share any details just yet
4. This feature is not in our short-term roadmap because we have a number of higher priority features pending for replication. We believe this feature is more "nice to have" because there are workarounds available...
5. This would not work for synthetic backup, as forever-incremental and requires previous backup file to exist by definition. Failing over to empty location would increase the backup time 10 times because full backup will be needed, so your backups will not completely on time, will get into the business hours and you would have to stop backups anyway.
6. Some of these features will be in v5.
7. Thank you for your kind words. I am sorry you are missing some features that esXpress has, but you are correct that our product's philosophy is totally different. And as you may have already noticed, we are mostly missing small features, but on the other hand we beat esXpress by having more important/affecting ones available (like vStorage and changed block tracking support, ESXi support and such).