Need help with my backup plan - limited storage size

[marama]

Hi there!

I've been using Veeam "Veeam Backup Essentials - Enterprise Plus" for 6 months now, but I never seem to have a good backup plan, so now I am fighting all tghe symptoms.

This is our setup:

On site:
a) VmWare ESXi Host - Production, running some 30 VMs. Fileserver VM has 1.2 GB of usage (4 VMDKs of 300GB joined in LVM volume group, daily change of only 2GB), other VMs are much smaller. Total of 1.5 GB .
b) VmWare ESXi Host - Backup, running 1 VM running Windows, Veeam software (proxy, WAN accel, repository), and 2TB of disk space for the backups.
c) NAS (Synology) - as a secondary on-site Repository (4TB of disk space, but not so fast). No proxy agent suport for Synology, connected as SMB/CIFS share.
d) uplink 16 mbit/s

Off site:
e) ESXi Host, running Windows VM with proxy, WAN accel and repository, 2TB disk space

Current configuration (relevant):
- "backup - fileserver" backup job, inclued ALL vmdks from fileserver (1.5 GB), proxy: automatic selection, repository: local; "retention policy/restore points to keep on disk": 1; Advanced: "reversed incremental", Advanced/Advanced: "remove deleted VMs data from backup after 1 days"
- "backup copy - fileserver" backup copy job (offsite), inclued "backup - fileserver" backup job as source, target is "offsite repository", "restore points to keep = 14", data transfer: WAN accell (source = local, target = offsite)
- "backup copy - fileserver" backup copy job (onsite - synology), inclued "backup - fileserver" backup job as source, target is synology repository", "restore points to keep = 14", data transfer: WAN accell (source = local, target = offsite)

Goal:
- offsite repository should store the data for disaster recovery, in case of total onsite loss (fire, burglarym, earthquake), we need to be able to recover the data from last day or two. single restore point should be sufficient.
- onsite repository (NAS/Synology): should store multiple restore points, in case someone need to recover a single file from last week. Target = synology repository, 14 restore points to keep, data transfer = "direct"

Issues:
1. Seeding the 1.2 GB of fileserver data to offsite repository: this is a big issue for me, have tried "active full", putting the file on HDD, copying it to offsite repository, mapping the backup copy job... but seems like the backup copy starts copying from the beggining. This issue probably deserves a dedicated subject so we can leave it for now (have already read lots of posts).
2. backup to synology or backup copy to synology? Currently I the backup job makes a backup of fileserver data to local repository, and 2 copy jobs try to make a copy to 1 additional onsite repository (synology) and 1 offsite repository. Would it maybe more sense to skip the copying of backup to synology and have the backup save to synology repository directly? So no "backup localy + backup copy to NAS" but to "backup to NAS" directly (without agent running on NAS)?
3. (Off-site) Transformation: OK, i have some basic understanding of transformation, but am very disappointing having the fact Veeam needs double the backup diskspace . The concept of reverse-incremental seems fine to me since incremental backups would get too big in time, but this is currently a killer of the backup concept since I have a 2TB backup space on offsite location. The only workaround I came up with (not tested) would be to split the backup copy in multiple jobs, each copying a single 300GB vmdk. So I would only need 300GB for transformation overhead, right? The recovery would be a bit messy since I would probably have to manualy join/recover the VMDks beffore recovering the VM, right?
4. Transofrmation: since transformation seems like a very slow process, can I somehow reduce the frequency of transformation events? For example: retention 7 days, backup copy daily, transfers on sundays only? If I have retention of 1, I need to have transformation each day, right?
5. Fileserver: having 4x300 GB disks in a volume group: is it a bad or a good idea? I was hoping I would have more flexibility, but I am not sure if I can perform guest-filesystem based recovery if I have the vmdks in separate backup copy jobs.


Plese tell me what am I doing wrong and what I might want to improve/change. I went through various best practices docs, but haven't found anything covering my scenario, probably missed it ;(
Is there any way to have a VM with ~1.2 GB of data backed up offsite on a 2GB disk?

TIA

[foggy]

b) VmWare ESXi Host - Backup, running 1 VM running Windows, Veeam software (proxy, WAN accel, repository), and 2TB of disk space for the backups.

Please note that storing backup data on VMFS is not considered as best practice.

- "backup copy - fileserver" backup copy job (onsite - synology), inclued "backup - fileserver" backup job as source, target is synology repository", "restore points to keep = 14", data transfer: WAN accell (source = local, target = offsite)

Not sure why do you use WAN acceleration for on-site backup job.

Regarding your questions:
1. Have you read the following topics on backup copy job seeding: Seeding offsite backup files for a Backup Copy Job and Seeding v7 backup copy?

2. If the NAS is capable of handling the I/O put by synthetic activity of the backup copy job, then there's no need to switch to normal backups as you would have to touch production VMs twice this way. If you feel that backup copy transformation takes too long to meet the required window, then switching is reasonable.

3. Could you please clarify what do you mean by "double the backup diskspace"?

4. Right, transformation is performed at the end of each backup copy job cycle.

5. I recommend to keep all VM disks in a single job (from FLR perspective). After all, 1.2TB is not the largest VM at all.

[marama]

Hi Foggy!

On topic of using VMFS as not being best practice - thanx for the hint. I will set up a dedicated Physical Server with HDD and the USB3/eSata connector I currently so much miss.

As for using WAN accel for on-site backup job - it's a typo (c&p), no WAN accel for local backup copy.

1. I thought I've gone through all those docs, but I will give it another go.

2. there is very little activity on the fileserver, so touching twice would not be a big issue I think. Synology is quite low on I/O performance. Probably I will simply try the non-copying backup job and see how it goes.

3.might be I messed up something in my head, but I think I've seen transformation (or some other process) eating up my diskspace and eventually aborting. If you think I don't need the 2x backup size - then I'll give it another go. But I recall reading something about that.

4. hmm, so there is no way to avoid it? I simply want to have daily backups and daily backup copies. If I have a retention of 7, wouldn't that mean that the first 7 backup copies would be done without transformation, but each new copy would require a transformation, right? I was hoping I could have some "overhead" for not having to perform transformation each day, but maybe each 7th day. If it would be possible to define a retention as range 7-14, then I could probably have first 14 transformation-free, then transofrmation + freeing up 7 restore points, then after 7 copies another transformation... etc. Is my setup wrong, or there is no way around this?

5. Yeah, will probably have to keep it that way. Just hope to get my backup plan working soon ;(

Thanx for helping me out!!!

[veremin]

Hmm, so there is no way to avoid it?

Nope. Once the specified retention is reached, the backup copy job starts transforming the chain on per-interval basis. Thanks.

[marama]

Hi!

I made a small progress with seeding. Turns out it's not sufficient (at least in my case) to make a copy and ship it to the offsite location and then rescan the repository and map the EXISTING backup copy job to the repository "folder", but I need to clone the backup copy job, delete the old one - too. That's what I was missing before. Probably skipped that in the documentation, or there is something else messed up with my configuration.

Anyway, am still very happy you are helping, and also very dissapointed about the transformation thing, those transformation are taking HOURS. Is there some other backup (copy) plan that might involve larger diskspace and other retention settigs, even incremental setup with reasonable cleanups... that might work for me? It's very frustrating to have to have the backup copy process being finished in 10 minutes and then wait hours for the transformation. Kind of kills the idea of WAN acceleration for me.

TIA

[veremin]

If target storage can't hold transformation activity well, then, you can either use additional remote backup job or stick to the "old school" method of using Robocopy of similar tool. Thanks.