This is mainly about copying large database to remote site with limited WAN bandwidth. Typically this is needed when an organization require DR site for Exchange but the number of users and/or changes on Exchange environment are relativly small.
For instance, an organization with (1,000+) mailboxes has a (35) Mbps WAN link to one of their offices. However, they can only allocate (18) Mbps for Exchange replication. Although daily changes usually do not exceed (25) GB, which is okay with such WAN link, the initial seeding of the databases (2+) TB cannot be done over WAN link.

I have done this several times in the past few years, but recently while I was doing it for one of our clients I noticed there was no refernce for it on the net. I found something for Exchange 2010 which is close to the procedure I’m having here, but I believe the followin steps are more accurate.

The last time this is applied was on Windows Server 2016 Standard and Exchange 2016 Standard. Yet it was tested with Windows Server 2008R2, 2012, 2012R2, and 2016 along with Exchange Server 2013 and 2016 both Standard and Enterprise editions.

The procedure basically must done within limited timeframe, and it cannot be done when servers on primary site have limited disk space and rely mainly on backup to keep free space.
During the process, the backup appliction will not be able to reset any logs until the new copy at DR site is up and running by getting into sync and healthy status for all databases.
Please make sure to read the full procedure then setup your plan accordingly.

Preparing:
1. DAG already extended and the server at DR site is joined.
2. No database copies on DR site created yet.
3. Have external storage attached, ready, and accessible from database owner(s).
4. Schedule and announce downtime.
It is important to calculate the size of databases and amount of time it needs to be copied to external storage.
5. Initiate backup to reset logs, or easier, run following procedure directly before you start execution
https://as7ablog.com/kinan/?p=347

Execution:
a. Add database copies to the DR server using PowerShell preventing seeding of data

Add-MailboxDatabaseCopy -SeedingPostponed -MailboxServer ExchMBX-DR -Identity ExchDatabaseName

This will create the database folders on DR server without contents.
Repeat the above command for all databases, but only for one server at DR.
Do NOT create copy on other servers at DR.
b. Dismount the databases on owner servers. Dismount each database on its own server.
c. Copy databases and logs from owner server(s) to the external storage.
You may need to stop “Information Store” service to get proper access to all files.
d. Start “Information Sotre” service if you have stopped it, then mount databases back.
e. Ship the external storage to DR site, connect and access it from Exchange server.
f. Stop “Information Store” service on DR server.
g. Copy data from external storage to respective path for each database.
h. Start ” Information Store” service.
i. Run powershell command to resume and copy delta logs from main site

Resume-MailboxDatabaseCopy ExchDatabaseName\ExchMBX-DR

Repeat the above command for all databases in DR.
j. Be patient and keep monitoring the status until it get healthy.
k. Run backup again and verify if logs are being reset.

Yep, you’ve seen so many like this one, mostly they will suggest you to stop Exchange searching services, then delete the indexing folder (located inside the database folder) and then restart the searching services.

Well, that would work if you don’t have DAG.

Again, mostly you’ll find suggestions to use the update-mailboxdatabase with -catalogonly key

Yeah, that would work if any of the DAG members have a healthy catalog. Now what if all DAG members doesn’t have it?

You’ve two options, but both are risky and I have no responsibility what so ever happens to your data.

Option 1:

Remove one of the copies of the database from one DAG member

Delete the database folder copy from that member’s disk

Add the database copy again to the DAG member

Database index shows crawling for few hours, then healthy

Finally, you can use this new catalog to update other DAG members

Option 2 (have downtime):

Dismount all database copies on all DAG members

Shutdown Exchange searching services (two services) on all DAG members

Delete the catalog folder from all copies on all members

Restart Exchange searching services (two services) on all DAG members

All servers will start crawling

HTH