Considerations, selecting entire ESX host in backup jobs?

[Fiskepudding]

Hello

It seems very convenient to select an entire ESX host when creating the backup job.
I am thinking one HOST for each job.

Lets say the host has 15 VM's with total of 3 TB data.
I guess there will better deduplication, so storage space is reduced some.

But is this generally a good idea? I am thinking about restore issues, and especially "Instant VM recovery".
How well will this play out, when running 15 VM's from the same deduped and compresses file?
If there were a optoin that planned the job for all VM's on the host but actually did split the VMS in different .vbk files i guess i would have been less concerned.

Anyone given this a thought, or have experience with this?

Thanx

[foggy]

Espen, placing several VMs in a single job is a common practice and the number of VMs in a job does not affect the restore speed of a particular VM. However, if we are talking about Instant Recovery of several VMs, I would like to pay your attention at this thread as it contains some good considerations about the whole concept and usage of this functionality, which could be useful in regard to your question.

[Fiskepudding]

Thanx, good thread.

[dellock6]

You would also say seelcting an ESX as backup source is good only if your VMs are not managed in a cluster, since using vMotion or HA will move the VMs into other hosts and so your backup jobs will have different VM lists from time to time, and so the VM moved into a new ESX will have to get a full backup.
Usually clusters, resource pools or datastore (even VM folders) are good "high-level" selections for backup of multiple VMs.