Sql-server – Failover strategy for SQL Server 2016 Standard Edition

I don't think this is a very good idea because replication is not just as bullet proof as a sound backup strategy. A blocking situation could stop replication jobs and you could easily be out of sync for some time. Or maybe a network card will fail and replication will be dead for a period. This means you won't be up to date for some time, and also, you will be without a good backup of the main, updated site.

Similar technologies, that will deliver updates to a copy of the main db, are mirroring and log shipping, but they both rely on full recovery model and log backups.

I'd suggest that you'd better study compression for your backups. Starting from SQL 2008 (Enterprise) and SQL 2008 R2 (from Standard) you have the option of compressing the backups using native SQL compression. In addition you should investigate data compression (in place compression for tables and indexes data). These will give you some help by making the backups smaller.

There are also 3rd party backup tools that will be able to help with compression if you need more complex solutions. See this site for question about how to make SQL Server backups as small as possible.

Also, you might think about moving old data from big tables to a history database, and play with connection strings in your app.

You could also try to make the backups locally, in a folder on the main server, and then just copy it to the tape (maybe backup to disk + direct copy will take less than backup to tape).

Sorry for the emphasis: YOU JUST WON'T BE SAFE WITHOUT TESTED PRODUCTION BACKUPS!

If I understand you correctly, your major problem is the log files during the several hours of backup. From your opening statement I understand that the 1.5 TB database normally runs in SIMPLE recovery, and thus no log backups to do.

Disclaimer: I have never done log shipping on this scale.

Of course, you should ask whether you can get more space allocated for your log files. If you can, then great.

However, I think a small modification of your plan, providing that you already run in SIMPLE recovery model and/or the risk of SIMPLE recovery model for a few hours is worth it, would ease some of your worries.

1. Keep (or set) DB in SIMPLE recovery model.
2. Take FULL backup (5-6 hours) on primary
3. Restore FULL backup to secondary (leaving in NORECOVERY)
4. Set DB in FULL recovery model
5. Take DIFF backup on primary
6. Restore DIFF backup to secondary (still in NORECOVERY)
7. Initialize log shipping using 'The database is already initialized'

The apparent advantages are:

1. No log files to backup during the large FULL backup.
2. Switching to FULL before beginning the DIFF backup will give you the needed log to start with and its longest growth is probably during the DIFF backup.

Regarding when a log backup can start:

https://technet.microsoft.com/en-US/library/ms190729(v=SQL.105).aspx

This says: "A new log chain starts either with the first full database backup following database creation or after switching from the simple recovery model to the full or bulk-logged recovery model."

So, I still believe that this will work as outlined. (Not identical, but I have used a differential backup to cover a gap when log files were lost, so as to establish a new origin for the log backups.)

(Remember my disclaimer, of course.)