Veeam 101

These five machines, are they physical or virtualized? Veeam was designed to backup VMware VMs first and Hyper-V VMs second, but physical machines can be backed up with an agent.

A service account with essentially admin rights is needed if you want to do application-aware processing in your backup. I would highly recommend you do this for all your Windows machine. This will let Veeam use Shadow Copy and various backup methods to safely backup things like AD objects and Exchange.

Veeam does have the concept of a backup copy. We have it set to copy to an "offsite" in another city daily. Azure and AWS are natively supported as a backup copy target, but you'll need to read the documentation on how it works, the cloud service's pricing, etc.

A VAR could help with the scoping and implementation, but I found Veeam's docs to be very detailed. The price increases in the last couple of years was a bit of an ouch, but it's still very good backup platform. I'm happy with it.

Veeam is probably good for your needs, especially if you run things via Hyper-V, which I would recommend you do. Basically have 2 or 3 physical machines for the 5 servers you run. The 5 servers are virtual machines you host on the 3 physical machines. That way you can always keep the 2 domain controllers on different hosts even through updates that require a reboot. You can run a failover cluster if you really want but it is probably not necessary unless you have staff using those machines 24/7 etc.

The Veeam server would be a 4th physical host and you do not need to have it integrated to the domain, from what I have understood. It may be more secure to not do so, and to keep it a bit separate from the rest of the infrastructure. Veeam should be able to authenticate against a domain without the host operating system being integrated to that domain. In the case of standalone server backup targets, the agent software on the servers that are integrated to the domain would be configured with domain user accounts with appropriate access roles and the Veeam server talks to the agents for doing jobs it needs to do via the permissions the agent software is granted.

Just a side note, Microsoft doesn't really recommend you use full backup/restore procedures for active directory domain controllers. Due to the various nuances of time, version control, etc. involved in active directory, they recommend you have mutiple domain controllers as redundancy rather than backups where you would plan a full server restore. The full restore option is only recommended in the case of a catastrophic loss of the entire DC infrastructure. It is basically always easier to simply take a faulty domain controller offline and replace it with a new one than to try a full restore from backup. Of course, you can have backups, they just don't recommend using a full restore as a first option to repair problems unless the issue is basically a full loss of domain controller infrastructure, say... all your active servers are wiped or stolen or something.

As another side note, you can easily duplicate your DHCP role to the second domain controller as well. Windows server has supported redundant DHCP service for a good number of years and it works quite well.

If you do end up with a separate backup server, make sure to keep its role singular so you can be sure it will function for restore work regardless of the rest of the network being owned by malware etc. No active file share mappings, or running services the other machines connect to etc. No shared user accounts/passwords, or applications.

There's a mode that DCs can be restored in that will make it ask the other DCs for updates. I wouldn't use it on a DC that's been offline for more than a few days but it can save some time recovering from a boot loop due to a bad update.

You definitely do NOT want to join your Veeam server to your domain, or at least not your main domain. Otherwise, if your domain credentials get compromised, your backup is compromised.

I've been using Veeam 11 for ~3 years now, and it's . . . ok. It does the job, but the error reporting is atrocious. Every time I had a failure pushing an agent to a workstation I had to google the cryptic error message and dig through Google or the forum to find the fix (enable Remote Registry and turn on File Sharing and Discovery).

Veeam 12 is allegedly better at this, but Veeam 12 doesn't support Server 2008 R2, so I have to wait until I can retire my Server 2008 boxes before I can upgrade.

You don't need a Server OS to run your Veeam server. I have it running on a Win 10 Pro box.

They have free and demo version of a lot of their products. In fact, I think they have a completely free version for up to 3 or 5 servers or something. Why not just give it a shot?

stevenkan said:

I've been using Veeam 11 for ~3 years now, and it's . . . ok.

Click to expand...

Paladin said:

They have free and demo version of a lot of their products. In fact, I think they have a completely free version for up to 3 or 5 servers or something. Why not just give it a shot?

Click to expand...

Yes, I should caveat my statement by saying that the first 2 years I used the Community (free) edition to back up my two DCs, since my ancient WS 2012 Essentials-based box wouldn't back up a "server OS." I was able to build an entire backup appliance for <<$600.

That was just my "starter" box, and I've since spent a lot more on drives and on a duplicate box as an offsite repository, and then lately paying for a subscription, but Veeam Free is a very good option for getting started.

stevenkan said:

Veeam 12 is allegedly better at this, but Veeam 12 doesn't support Server 2008 R2, so I have to wait until I can retire my Server 2008 boxes before I can upgrade.

Click to expand...

Not according to the release notes I see at Release Notes .

On there, Backups of "all operating systems supported by VMware vSphere version in use" and "MS VSS integration is supported for Microsoft Windows 2008 and later, except for nano server (due to absence of VSS framework).

The HOST side is HV-2012 or later and vCenter 6.x and later, which is the same requirement for the B&R console and other Veeam component software installs, but installing you really shouldn't be installing any new software on such old OSes.

antonyart said:

am I wrong or Veeam Backup & Replication 12 no longer supports Server 2008 R2.

Click to expand...

your "supports" is vague...

It supports backing up of Server 2008R2 VMs as long as your hypervisor supports it.

It does not support Server 2008R2 Hyper-V as a hypervisor host and it does not support Server 2008R2 for installation of various Veeam server roles such as server/console/Repository/Proxy.

I have the pleasure of living on with two 2008R2 VMs and one 2012 VM which I just can't seem to rid myself of yet. They are running on esxi 7.0.3 (as legacy support) and backed up using veeam v12.

oikjn said:

your "supports" is vague...

It supports backing up of Server 2008R2 VMs as long as your hypervisor supports it.

It does not support Server 2008R2 Hyper-V as a hypervisor host and it does not support Server 2008R2 for installation of various Veeam server roles such as server/console/Repository/Proxy.

I have the pleasure of living on with two 2008R2 VMs and one 2012 VM which I just can't seem to rid myself of yet. They are running on esxi 7.0.3 (as legacy support) and backed up using veeam v12.

Click to expand...

I'd been reading this post by Gostev (Veeam employee):

You can't go ahead with the upgrade in principle, as it will be blocked until you remove these servers from the configuration.

If you need support for Windows Server 2008 R2, you should stay on V11.

Click to expand...

I still have 2 physical Server 2008 R2 boxes that I'm trying to migrate away from.

Generally you use groups for things that should have similar/the same policy applied to them. For example: you have 10 servers. 3 are doing content stuff, 4 do database stuff, 3 do financial transaction stuff. You want a group for each type of server so you can easily manage policies for each group and update the policies in moments instead of doing each individually. With only a small handful of servers, there is less value but still a bit to using groups unless each of your servers should have wildly different backup policies.

Managed by backup server should be the common option unless the thing you want to backup is often powered off, disconnected from the network/internet/VPN or otherwise should be in charge of starting its backups on its own timing which is initiated by the agent.

Entire computer is probably fine unless you have computers with multiple volumes and you want to backup one volume but not the other(s), etc. Say, a machine with important data on drive C: but a bunch of unimportant junk on drive or whatever. Or maybe you want one policy on drive C: and a different policy on drive (once an hour on C: and once a day on etc.).

File level backup is for when you either can't do a full device backup (due to operating system usually), can't do a volume level backup (due to operating system usually) or don't want to do either of those because all the data you want to backup is just some files in a folder. Say, a particular share on a NAS or something. You want the data but the OS can't be restored anyway so no point backing it up or you have 10 of the same server install and only care about the files in certain folders on those servers, not the OS files, etc.

Not sure about the console, I have never tried that. If remote desktop works for you, you could stick to that until you want a permanent setup or feel like you want to move forward in the demo.

Yeah that is a different design. Most modern platforms are centered around virtual machine backup these days. You tell the backup management platform about your hypervisor (VMWare vCenter, Hyper-V/SCVMM, Nutanix, etc.) and give it credentials and the backup system enumerates all your VMs, and you apply policies to them and it goes. No hassle.

With bare metal machines you have to put the agent on the machine and the agent needs to make outbound and accept inbound connections from the backup system. Generally that is not a big deal because the backup system is on your LAN along with the servers and it is common to allow connections to/from LAN IP addresses so there is no work to allow it. If you have your servers more locked down or the backup system is on another network then you will have more administrative work to do.

That is generally another motive for moving to virtual machines as well, backup is much easier and administration is more policy-centric instead of everything being a one-off that needs special tinkering.

++ to what Paladin said. These days, VMs are the default and physical hardware is the exception to the rule. I don't think Veeam 12 won't backup a physical 2008r2 server, but it will easily backup a VM. To answer your NAS file share question, each backup repository is a single share and Veeam would manage the sub-folders within that share so that you can have it put in multiple backups. That share and its total storage would be split across all the backups targeting that repository, so if you wanted to limit or dedicate specific backups by size, then you should create any number of additional shares and add those as additional repositories. For example, I have a single repository for all my server VM backups and a second repository for the handful of desktops I individually backup and while the physical storage is on the same NAS, they are in different shared folders with different quotas and are represented in veeam as two different repositories. If I were you, I would be updating that 2008r2 file server up to at least 2019 assuming it is just a file server and doesn't have some funky application... not sure why you haven't updated it already. I would then really look at getting two new physical host servers and P2V everything over and run every OS as a VM so you don't have to worry about hardware issues ever again and backups and recovery become soooo much easier.

My installation is 2 VMs and 10+ physical PCs, so I'm the opposite of the norm, and deploying agents definitely has a learning curve, as I mentioned above.

If your PCs are joined to your domain, and the PCs are on the same LAN as your Veeam server, and your Veeam server has domain credentials stored, then it's actually not that difficult once you know how to map unhelpful error messages to the root causes:

1. Network Discovery needs to be turned On for domain networks on the target PCs.
   1. Otherwise you will see the target PC in the domain list on the Veeam console, but you won't be able to push a client to it,
   2. or you'll be able to push the client, but backups will fail.
   3. I can't remember which symptom is tied with this root cause . . . .
2. The Remote Registry Service needs to be running on the target PCs.
   1. . . . and which is tied to this root cause.
3. I did not have to manually open any firewall ports on the clients PCs.
4. If you get mysterious "duplicate client" errors, it might be the result of stale DNS entries on your DC, as Veeam helpfully identifies clients by IP address , at least as of Veeam 11. Purging the DNS table fixed this for one client.
5. In a few cases of failed credentials, removing from the PC from the domain and then adding it back fixed the problem
   1. Of course this requires you to know the password for a local admin account first!

10+ PCs to backup? Yuck! All our general PCs are considered "disposable" nothing is backed up on them and anything important is saved to network shares/servers/onedrive. If any of those PCs gets messed up in software or hardware, it gets wiped and started fresh. We are manufacturing and there are four PCs connected to physical equipment which are the exception to the rule and get backed up. Veeam is OK for physical computers and I've done a few restores of those equipment computers over the years and it works great, but I wouldn't consider Veeam a great solution for managing backups for lots of physical computers unless you have even more Virtual machines and want to keep all the backups under one program for ease of management.

stevenkan said:

I'd been reading this post by Gostev (Veeam employee):


I still have 2 physical Server 2008 R2 boxes that I'm trying to migrate away from.

Click to expand...

As it turns out, a bunch of Veeam's online documentation was misleading. Server 2008 R2 is unsupported if and only if it lacks SP1, and "Veeam CBT driver is supported only if Microsoft Windows update KB3033929 is installed on the Veeam Agent computer."

Which is a long way of saying Server 2008 R2 can be compatible with Veeam 12 if set up properly. See my original link for Gostev's confirmation.

I did update my Veeam server to V12, and my sole remaining Server 2008 R2 SP1 VM has been backing up successfully. And we will get rid of the VM very, very soon.

way to bring up a necro thread If I recall properly, the issue of support isn't with VMs, it will support whatever VMs the Hypervisor supports, the issue is supporting it as a hypervisor.

I hate to admit it, but I still have a 2008 (NOT R2) VM I'm stuck with along with one 2008R2 VM that is backed up by Veeam 12.1.2 with no problem. Its running on VMWare and since it is supported there, its getting backed up happily along with the SQL instances with logs with no issue. I just can't wait for the day when I can really drop those VMs (hopefully in about 8 months)