Need help?

Our experts have had an average response time of 11.7 minutes in August 2021 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

How to restore a database in Alwayson Availability Group

by | Feb 1, 2021

Wondering how to restore a database in alwayson availability group? We can help you do it.

In some cases, we may need to restore the database that is a part of alwayson availability group in order to fulfil our business needs. However, restoring a database in the availability group is different than restoring a normal database. It is not possible to restore the Availability Group database directly like the normal database. You can come across the below error message.

The operation cannot be performed on database “DBNAME” because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.

Here at Bobcares, we have seen several such database-related errors as part of our Server Management Services for web hosts and online service providers.

Today we’ll take a look at how to restore a database in alwayson availability group.

 

Restore Databases in Availability Group

Now let’s discuss how our Support Engineers restore the database in the Availability Group.

Here are the steps that we follow to restore the database.

 

1. Remove Database from Availability Group

First, we remove the identified database from the AOAG configuration.

Note: If you want to restore the primary database in the AOAG configuration then you should remove it from the primary replica. Because it will automatically remove this database from AOAG configuration on secondary replica as well. So there is no need to separately remove the secondary databases from the AOAG configuration.

Here is the T-SQL statement that we use to remove the primary database from the AOAG configuration.

–Change the name of Avail_Group to your Availability group.
–Change the database name from DBName to your primary database.

ALTER AVAILABILITY GROUP Avail_Group REMOVE DATABASE DBName

 

2. Restore Database

After removing the primary database from the availability group, it will disappear from the Availability Database folder showing under the Availability group name on both replicas.

Now, we shall restore the database by running the below T-SQL statements.

–First, we restore the primary database with the help of the backup file.

RESTORE DATABASE DBName
FROM Disk= ‘F:\Backups\DBName_Full.bak’
WITH NORECOVERY, REPLACE;

–Next, we restore log backup till the time we want to recover the database.

RESTORE LOG DBName
FROM Disk= ‘F:\Backups\DBName_TLog.trn’
WITH NORECOVERY, REPLACE, STOPAT = ‘Dec 21, 2020 8:00 AM’;

–Finally, we bring the database Online.

RESTORE DATABASE DBName WITH RECOVERY;

After restoring the database and once it comes online, we will go ahead to add this database to the availability group again.

 

3. Add database to Availability Group

In order to re-add this database to the availability group, we first prepare the corresponding secondary database.

For that, we first need to take a full backup and immediate transaction log backup of the newly restored primary database.

Then we copy these files to a secondary replica and restore the corresponding secondary database in norecovery mode.

After that, we restore the corresponding secondary database with the help of above-copied files in norecovery mode with REPLACE option.

Now, we run the below T-SQL command to add this database to the existing availability group.

— Connect to the server instance that hosts the primary replica.
— Add an existing database to the availability group.

ALTER AVAILABILITY GROUP Avail_Group ADD DATABASE DBName;
GO

Finally, we ensure to configure the secondary database on the secondary replica. However, if we don’t want to add this database to the availability group then we can ignore this step and use the database for transactions.

Also, it is possible to use that database from a secondary replica for any purpose. And can bring it online by running the below command on the secondary replica.

–Run-on secondary replica in case you don’t want to configure this database in AOAG rather want to use it for transactions.

RESTORE DATABASE DBName WITH RECOVERY;

That’s it! Now, we are done with the database restore in Alwayson Availability Group.

[Need any further assistance in restoring the database? – We are here to help you]

 

Conclusion

Today, we saw how our Support Engineers restore a database in alwayson availability group.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

var google_conversion_label = "owonCMyG5nEQ0aD71QM";

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF