It depends. If you can afford the addtional storage space for backing up both nodes then you are good to go with backing up both nodes. But there are other things you have to take into consideration when planning your backup strategy. It has to deal with your other questions.Question 1:
Should both nodes be backed up, isn't this just duplicating information and backup window?
Even after changing the values you've mentioned under question 5 there is still the possibility that you experience a database failover from the active node to the passive node when snapshot creation or commit takes place. This is something that happend to me in our environment. While Job 1 on Node 1 was running (database failover due to snapshot creation has happened) the job for the second node started too cause my backup windows overlaped. Now while backup of Node 1 was still running and the backup of the second node was intiated all the active databases from Node 2 made a failover back to node 1. Backup job on Node 1 finished and as snapshot commit was performed the databases failed over again to Node 2. Now after snapshot commit on Node 1 finished the job on Node 2 began his snapshot commit. Now the active databases again started to initiate a failover back to Node 1. They never failed over to Node 3 as we've setup database preferences. This is why i ended up in a situation where my databases flapped around between Node 1 and Node 2. Additionally because of the amount of load and mailboxes the Indexing service on these two nodes went wild resulting in VMs that were under 100% load and thus not responding anymore to any requests for quite a while. Not really funny having thousands of users complaining about a non working Outlook anymore
In the end we've setup a complete passive node (Node 3) and just backing up this one. That way we are preventing active databases from doing a failover and additionally offloading the backup processing to this single node. This is by the way the preferred method by Microsoft too in an Exchange DAG environment. Here's an article from a Microsoft blog where you can read something about it (scroll down to VSS Backup of Passive Copy). It's written for Exchange 2007 but still applicable for Exchange 2010 i think.Question 2:
If only a single node is recommended should it be Active or Passive?
Just in case of VSS based restores it is a bit troublesome when backing up a passive node . But this is not applicable for Veeam as your are not performing VSS based restores with it. So it doesn't really matter if you backup an active or a passive node with Veeam.
Yes. See the link to my post Vitaly referenced. But you should always keep an eye on your backup and see if log truncation really happens. In case you've got any issues with the Replica writer log truncation can fail. So again: watch it!Question 3:
If passive will truncate logs still work?
See answer to question one. If you can do backups from an active node without initiating a database failover you are good to go with a mixed environment. If not you should consider creating a passive node an just doing backup of this single passive node.Question 4:
If node has mixed active and passive databases, should this be altered so all databases are active on a single node and passive on alternate node?
These settings are intended to prevent a database failover when vMotion or snapshot takes place. You have to try it. You can safely increase the timeout values even when not needed.Question 5:
I have read about snapshot timeouts resulting in DAG failovers, should I increase cluster timeouts (SubnetDelay/SubnetThreshold) from offset or wait and see if this issue affects me?
Take a look into this article too. There are some recommended hotfixes for an Exchange 2010 DAG cluster you may want to implement in your environment.