Ive been playing around with Veeam the last day or so and not having much luck. we have 2 servers running 2016 with RDX backup drives. I have installed community addition on one im using as a test server, the other one is in production running AD, DHCP, DNS etc. We also have a small NAs we can locate in a seperate building to give us ofsite backups/copies.
So far non of the backups have worked, seems to fail on a rescan needed.
Maybe I should be using agents and not community ? Just about all the help/instructions go into VM and more complex stuff than we need. I have only ever had to recover files twice and server once in the 15 years Ive been supporting them but its enough to know that next time I want it to be a lot easier and have backups configured so we have fairly up to date data. Weekly would do at a pinch. So yes critical that we have it but no ones going to lose much and its a balance with costs of loss and cost of implementattion. Sorry for going on.
Any suggestions as to best approach? Thanks. Liam
Best answer by StefanZi
Thanks @Mildur, I kind of thought RDX is tape and done - I wasn’t aware of these appearing like external USB HDDs. That’s then fully working and supported, agreed.
As the others stated: Use the Veeam Community Edition, install it on one of your servers. It acts as a manager for your backup. From there you can distribute the agents which are required to backup physical systems. The alternative would be to have unmanaged agents (same agent, but no management VBR), so I’d recommend to use the VBR in your case. So your decision is not whether to use agents OR VBR but if you use agents or agents AND VBR - agent’s will always do the heavy lifting on servers/desktops.
You can also backup the VBR server itself with an agent backup (so let VBR deploy the agent to itself :D). You can take the servers (and possible also agents) to the RDX drives and then create a backup copy job to the remote NAS (as Mildur said - prefer to use iSCSI discs on the NAS instead of SMB/NFS so you can leverage ReFS block cloning and fast synthetics).
Sounds like you are not using any virtualization but just hardware servers?
First of: RDX is not supported by Veeam, just LTO. So you won't be able to make use of these.
S if you want to back up your physical servers you will have to roll out the agent on them. You can do this managed by the VBR Community server and then create a backup job for the servers. That way you can leverage application backups for AD.
If the connection to the NAS is good enough you can run a direct backup to the NAS device.
Have a look in the Veeam Help Center and maybe start by understanding protection groups.
Sounds like you are not using any virtualization but just hardware servers?
First of: RDX is not supported by Veeam, just LTO. So you won't be able to make use of these.
S if you want to back up your physical servers you will have to roll out the agent on them. You can do this managed by the VBR Community server and then create a backup job for the servers. That way you can leverage application backups for AD.
If the connection to the NAS is good enough you can run a direct backup to the NAS device.
Have a look in the Veeam Help Center and maybe start by understanding protection groups.
Yes using the agent is probably the best suggestion here as noted by @StefanZi so check out the link he posted and the help for agents.
Thanks for the replys guys. RDX is not a tape and is recognised as a usb attached HD when installed and is recognised as a drive to backup to in Veeam same as a portable drive. The RDX was specified with the Lenovo thinksystem servers along with Veeam so what your saying is a bit of a suprise to me.
As well as trying to backup to RDX I have also had same issues backing up to an internal drive (the one veeam defaulted to on install).
Aside from the RDX issue, it seems from what you are saying Veeam is designed to operate in a VM environment and not with physical servers is that correct ? How would it look if the second servers main function was a backup server, would this then run community addition or would I still just be using agents ? I would still like to use the NAS and could at least copy to RDX ?
In the meantime I will follow your advise and do more reading and maybe rebuil my test server / try a fresh install. Cheers
@liamg Veeam can operate virtual and physical. You decide where you want to install it and what you need to backup.
Install your vbr server
configure your nas with iscsi and connect it to the vbr server
add a direct attached backup repo, which targets the mounted iscsi lun
configure a rotated Backup as mentioned in my posted link for the rdx drive. The rdx drive should to be connected to the vbr server
Configure protection groups for your Server and computer
configure a backup Job/backup Policy to backup the Agents in the protection Group to the iscsi lun. Do not forget to exclude the iscsi LUN from the Agent Backup, or you will be creating a backup of the backup each day ;)
configure a backup Copy Job to copy the backups from the iscsi lun to the rdx drive
Thanks @Mildur, I kind of thought RDX is tape and done - I wasn’t aware of these appearing like external USB HDDs. That’s then fully working and supported, agreed.
As the others stated: Use the Veeam Community Edition, install it on one of your servers. It acts as a manager for your backup. From there you can distribute the agents which are required to backup physical systems. The alternative would be to have unmanaged agents (same agent, but no management VBR), so I’d recommend to use the VBR in your case. So your decision is not whether to use agents OR VBR but if you use agents or agents AND VBR - agent’s will always do the heavy lifting on servers/desktops.
You can also backup the VBR server itself with an agent backup (so let VBR deploy the agent to itself :D). You can take the servers (and possible also agents) to the RDX drives and then create a backup copy job to the remote NAS (as Mildur said - prefer to use iSCSI discs on the NAS instead of SMB/NFS so you can leverage ReFS block cloning and fast synthetics).
