USB and replication

[SledDogOlson]

how come you can do an initial replication to a USB device, move it to some other site/device and continue subsequent replications, BUT, you cannot constantly do a replication to a USB device?

I don't have a lot of bandwidth. I can only get so many replications done per week to our offsite storage. I would be great if I could run replications continuously to a USB device and move that device monthly to the offsite location and rotate another USB device back to the main location. In this way, I could have important replicas done automatically and lesser VMs done in a semi-manual method monthly.

Any thoughts?

Thanks.
Wj

[Gostev]

Constant replication to a USB device is called backup and we do provide this capability

[SledDogOlson]

Yeah, I get that sort of (for lack of thoroughly reading through all the documentation). Thus, you are telling me that a replica and a backup are identical. Therefore, I can copy a backup to a remote SAN when I carry over my USB device and light-it-up just like a replca. Correct?

[Gostev]

That's right, replica and backup are almost idential (only differences are target, and data format).
Correct, except that you do not copy but "restore" backup from USB device to a remote SAN.

You may want to read the sticky FAQ topic, as it goes into details of how various job types that we provide compare to each other.

[SledDogOlson]

Gostev, thank you so much for the answer and quick response. That is perfectly right for me. I still get to whine a bit...too bad I have to formally restore them. I have been spoiled by taking replicas to an offsite and just copying them on, right click on the VMX file, and add to inventory. Nonetheless, thank you!

[Gostev]

Well, you can do exactly what you want with VM Copy job (again, I strongly encourage that you read FAQ).

However, both backup and restore will be much slower with VM Copy comparing to Backup job. Particularly, compare time required to fetch uncompressed 100GB VMDK from slower USB device in copy approach, versus fetching only 10GB of data (compressed and deduped representation of VM you need) in backup/restore approach. Moreover, we will even register the VM automatically for you (no need to click VMX file).

Likewise, full backup speed will be much faster for the same reason (much less data to write to USB device). Incremental backups are going to be 20x faster, thanks to copying changes only versus full VMDK each time. With multiple restore points, backups will also take gazillion times less disk space (full flat VMDK files for each restore point, versus deduped and compressed full backup files along with compressed and deduped incremental deltas).

In short, backup benefits are simply overwhelming. The only times I see customers using VM Copy approach is when they need to perform single ad hoc backup of running VM to tape or another long-term media in native format, or for purpose of building test environment. Nobody uses VM Copy for continuous backups, it just makes no sense.