Sql-server – By Mistake Deleted AlwaysOn Availability Database from live Production Server

You can backup the transaction log from either of the replicas. Doing the transaction log backup on either the primary replica or the secondary replica will mark both replicas' transaction logs as reusable (provided no other stoppers are in place like active transactions, etc.).

To do a test, in a non-production environment, setup an availability group just as you have it in your production system (asynchronous commit to the secondary replica).

In my test environment I have a test database, TestBackupDatabase, and I bloated it with logged transactions through a dummy table:

use TestBackupDatabase;
go

create table dbo.TestTable
(
    id int identity(1, 1) not null,
    some_int int not null
        default 1
);
go

insert into dbo.TestTable
default values;
go 1000

Now when I do a transaction log backup on my primary, using DBCC SQLPERF(LOGSPACE) I see on both transaction logs (primary and secondary) that space used has dropped due to log truncation. Bloating the transaction log back up with the same test on the primary:

insert into dbo.TestTable
default values;
go 1000

I now do a transaction log backup on the secondary async replica. Running DBCC SQLPERF(LOGSPACE) again on each replica I see the same behavior: transaction log reuse.

BOL Reference: Active Secondaries: Backup on Secondary Replicas (AlwaysOn Availability Groups)

These errors mean you had a connection timeout. The subsequent messages are a result of that. In a multi-subnet environment, each AG will have an IP address in each subnet and be registered in DNS. The DNS server returns multiple IP addresses when queried. Only one will be online. SQL tries all the ip address, serially, until connection is established. The TCP timeout is 21 seconds. If the first ip is not online, it will wait 21 seconds before it tries the next one. The default connection timeout period for .NET client libraries is 15 seconds. You can see where that could be a problem. You need to read this article http://blogs.msdn.com/b/alwaysonpro/archive/2014/06/03/connection-timeouts-in-multi-subnet-availability-group.aspx

If you don't have a multi-subnet environment, then I would look at the network logs again and see how long it was taking for your tcp connections.