Резервные копии снимком на вторичных репликах группы доступности

Автор: Andrew Pruski, T-SQL Snapshot Backups on Availability Group Secondary Replicas

Одной из моих любимых возможностей SQL Server 2022 были резервные копии снимком (Transact-SQL snapshot backup). Возможность использовать снимки современных систем хранения для создания согласованных на уровне приложения снимков наших баз данных — это прорыв для всех, кто имеет дело с очень большими базами данных и изо всех сил пытается уложиться в RPO при заданном RTO.

Однако согласованные на уровне приложения снимки требуют, чтобы запись ввода-вывода базы данных была приостановлена/заморожена/остановлена… и (справедливо) это может заставить администраторов баз данных нервничать.

SQL Server 2025 добавил возможность делать полные и разностные резервные копии баз данных вторичных реплик в группах доступности… но как насчёт T-SQL-резервных копий снимком? Разве не было бы здорово, если бы мы могли делать их на вторичной реплике и не приходилось бы приостанавливать ввод-вывод на первичной базе данных?

Увы, если мы попытаемся сделать «обычную» резервную копию снимком вторичной реплики:

ALTER DATABASE [tpcc] SET SUSPEND_FOR_SNAPSHOT_BACKUP = ON

Мы получим следующую ошибку:

Msg 1468, Level 16, State 3, Line 5
The operation cannot be performed on database "tpcc" 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.
Msg 5069, Level 16, State 1, Line 5
ALTER DATABASE statement failed.

Ладно, полагаю, это имеет смысл…

Однако у меня был разговор с двумя замечательными людьми (Sean Gallardy и Allan Hirt) в Microsoft, и выяснилось, что вы МОЖЕТЕ сделать снимок базы данных вторичной реплики!

Правда, есть пара условий: база данных на вторичной реплике должна быть доступна только для чтения, необходимо указать COPY_ONLY, и делать это нужно на уровне SERVER CONFIGURATION.

Итак, если мы попробуем:

ALTER SERVER CONFIGURATION SET SUSPEND_FOR_SNAPSHOT_BACKUP = ON
(GROUP = (tpcc), MODE = COPY_ONLY);

Ага! Ввод-вывод (запись) заморожен на базе данных!

Database 'tpcc' acquired suspend locks in session 75.
I/O is frozen on database tpcc. No user action is required. However, if I/O is not resumed promptly, you could cancel the backup.
Database 'tpcc' successfully suspended for snapshot backup in session 75.

Теперь мы можем сделать снимок томов на нашей системе хранения, а затем создать резервную копию METADATA_ONLY:

BACKUP DATABASE [tpcc] TO DISK = 'E:\SQLBackup1\tpcc.bkm' WITH METADATA_ONLY;

Это снимает приостановку, и у нас есть согласованный на уровне приложения снимок!

I/O was resumed on database tpcc. No user action is required.
Database 'tpcc' released suspend locks in session 76.
Database 'tpcc' originally suspended for snapshot backup in session 76 successfully resumed in session 76.
Processed 0 pages for database 'tpcc', file 'tpcc' on file 3.
BACKUP DATABASE successfully processed 0 pages in 0.003 seconds (0.000 MB/sec).

Конечно, если что-то пойдёт не так и нам нужно прервать операцию, мы можем выполнить:

ALTER SERVER CONFIGURATION SET SUSPEND_FOR_SNAPSHOT_BACKUP = OFF
(GROUP = (tpcc));

Это возобновит ввод-вывод!

I/O was resumed on database tpcc. No user action is required.
Database 'tpcc' released suspend locks in session 76.
Database 'tpcc' originally suspended for snapshot backup in session 76 successfully resumed in session 76.

Но вот оно: способ делать согласованные на уровне приложения снимки баз данных, не беспокоясь о влиянии приостановки на наши приложения.