Per-Machine Backup Files Best Practices.

[Supraman]

Hello Everyone,

I was review the option for "Use Per-Machine backup files" on our repositories under the advance options and from what I take it, this option should not be enable if we are using backup repositories with rotated drives. From option description itself, it is suppose to improve backup performance for storage devices that are enterprise grade block storage. Now my question if I am using several Synology NAS with rotating disks some with 7200 RPM and some that are 5400 RPM should I be enabling this option?

The reason why I am asking because I am looking at the manually and from it appear it is listed under the limitation for per-machine backup files and that it cannot be enable for rotated drives.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

"Limitations for Per-Machine Backup Files

When planning to use per-machine backup files, mind the following limitations:

The Use per-machine backup files option cannot be enabled for backup repositories with rotated drives.
If you enable the Use per-machine backup files option, data deduplication between VMs will not work. For more information, see Data Compression and Deduplication."

[HannesK]

Hello,
I believe that there is a confusion between "spinning disk" (meaning hard disks at 7200 RPM or 5400 RPM) and "rotated drives" which means in Veeam terms that devices (usually disks) are changed / disconnected / re-connected.

If I got it correctly, then per-machine files are good to go (and recommended) for your scenario.

Best regards,
Hannes

[Supraman]

Hello Hannes,

May I ask would these spinning disk consider as Enterprise grade block storage would you say? I have notice by enabling this per-machine backup files when it goes to tape it might take up all the tape drives unless I set the limit for. I can see that it might befit someone using flash storage or with forward incremental backups. However in our case at least in my environment we are primarily using active fulls instead.

[HannesK]

Hello,
I would says Synology products are more SOHO (small office / home office) as they don't have a real RAID-controller, but the per-machine chains are still the recommended option. In worst case you can still limit storage load by reducing the tasks on the repository.

Actually we plan to make per-machine chains the default in V12, so we probably will change the description of that text

If you use SMB protocols (SMB / NFS), then active full is the only option (for performance reasons), yes. If you map the storage as iSCSI LUN, then XFS / REFS block cloning would also allow synthetic fulls or forward forever incremental

Best regards,
Hannes

[Supraman]

The reason to my question was basically we had it disable and since we had multiple VM in one job it simply created one VBK to disk and to tape; however after enabling this change I have notice as it states "pre-machine" it create multiple vbks file which then, when writes to tape uses multiple tape drives. Now what it does create a problem in which I have seen where one Job might be using 4 tape drives at once while other job are waiting for the resource and than fail.

I know that we could set the policy on the tape medial pool to use X amount of tapes drive per job; however, the lowest number was only 2. Furthermore, currently we are only using active full and the synology are map via iSCSI Lun on a 10GB connection.

[HouliNZ]

This is a really good question. We are considering moving to 'Per-machine backup files' because we are running ReFS which has block level de-duplication already present. We are finding it increasingly difficult to remove old backups of some servers (since retired) but still consuming backup storage space.

How much more (assuming that it is) efficient is VBR11a's deduplication to a single file to VBR11a's pre-machine backup using ReFS for deduplication?

Or is there a smart way from removing files for old machines from existing backup sets?

[HannesK]

from my point of view the recommendation is easy: always use per-machine files for the following reasons (there are probably more reasons. these are just the most common ones):

- Easier tape restore
- More performance through parallel processing
- Easier job management (put more VMs in one job)
- Resource usage with SOBR
- Easy deletion of VMs from backups
- Per VM accounting

@Supraman: parallel tape processing can be disabled completely.

@HouliNZ: First: welcome to the forums. I would say it's impossible to predict how much space savings might get lost with per-machine chains. Because it's impossible to predict how much equal data exists between different machines during the same backup run. From my point of view it's not worth the time thinking about that.

[Supraman]

Hello Hannes,

Disabling it would effectively make it no difference in term of increasing the tape performance job, but actually it has the negative effect. Now if I have like 1 job with 10 VM being backup, disabling parallel tape processing will force the job to independently back up those VMs one by one which could take hours.

However, I do see you point and the benefit assuming we have like a flash/hybrid flash storage as a repositories but for the slower NAS(s) this would essential make it much worst in term of overall performances. As the only negative effect that I can see is that by disabling the per-machine, the backup job will produce one giant VBK. However, we would benefit on the tape performance in term of duration.

[HouliNZ]

@HannesK,

Thank you for you quick and useful post. We have come from a ShadowProtect backup product and moved to Veeam about a year or so ago. Having multiple servers locked up in single backup files has been quite a change - particularly around per VM accounting and locked up storage from old VM's no longer used.

We will plan the change to per VM backups and look to implement in November.

Again - thanks for your help.

Cheers Houli

[HannesK]

@Supraman: having one large file effectively also disables parallel tape processing It's just one file that is copied to one tape drive. Example: 1x10TB instead of 10x1TB.

agree, NAS systems are the worst option for backups. that's why we don't recommend them. if the source hardware is too slow for two tape drives (meaning less than around 225 MByte/s for 2x LTO8), then it makes no sense to try parallel processing for tape. For two LTO8 tapes, the storage should deliver at least 500 MByte/s to get some performance gains (one LTO8 writes 360 MByte/s).

if a backup storage can only handle one stream, then the repository settings also allow to configure only one task. that's something that can be tried out with the specific hardware in place to see which option is the fastest. but that's independent from per-machine chains best practices from my point of view

[Supraman]

@HannesK: @Hannesk I hope with Version 12 per-machine is not automatically enable as you indicated earlier I would say this option should be an option as user with slower NAS and limited tape drives will actually have a negative effect on their overall performance. Furthermore, may I asked what would Veeam truly consider as a "deduplication storage appliance."

[HannesK]

that means these ones