Avamar: Impacto do SQL da execução de backup incremental SQL nativo nas operações do Avamar
Summary: Este artigo descreve como a execução de backups incrementais SQL nativamente a partir do SQL Management Studio afeta os backups SQL do Avamar. Por isso, espera-se que os backups incrementais do Avamar relatem uma lacuna de log devido a uma quebra na sequência de LSN da cadeia de logs. ...
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Instructions
As etapas a seguir foram projetadas para quebrar a sequência de "cadeia de logs" do Avamar, resultando em erros de "lacuna de log":
Passo #5:
Para resolver essa falha e sincronizar as informações da LSN, execute um backup completo para esse banco de dados.
- Execute um backup completo seguido pelo backup incremental do Avamar. Mantenha uma guia das entradas do banco de dados no arquivo sqlmeta.xml .
- Execute um backup incremental SQL nativo no banco de dados, forçando a alteração da LSN no SQL. Mantenha uma guia de entradas de banco de dados no arquivo sqlmeta.xml .
- Agora execute o backup incremental do Avamar, que deve relatar um erro de lacuna de log no banco de dados. Aqui notamos que a entrada do arquivo sqlmeta.xml é removida. A exclusão acontece somente para backups incrementais orientados por políticas. Se o backup incremental sob demanda for executado, as entradas no arquivo sqlmeta.xml serão preservadas.
- Execute a seguinte consulta na janela SQL Management Studio Query analyzer para obter detalhes do "número de sequência de log".
SELECT msdb.dbo.backupset.database_name,
msdb.dbo.backupset.backup_start_date,
msdb.dbo.backupset.backup_finish_date,
msdb.dbo.backupset.type,
msdb.dbo.backupset.database_backup_lsn,
msdb.dbo.backupset.first_lsn,
msdb.dbo.backupset.last_lsn
FROM msdb.dbo.backupmediafamily
INNER JOIN msdb.dbo.backupset
ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id
WHERE database_name IN ('test_db_1')
--and msdb.dbo.backupset.backup_finish_date between '1/20/2020' and '1/27/2020'
ORDER BY
2 DESC,
3 DESC O resultado dessa consulta é mostrado abaixo:
database_name backup_start_date backup_finish_date type
database_backup_lsn first_lsn last_lsn
test_db_1 2020-02-12 16:37:31.000 2020-02-12 16:37:31.000 D
34000000085100037 34000000089600037 34000000091300001
test_db_1 2020-02-05 20:29:23.000 2020-02-05 20:29:23.000 L
34000000085100037 34000000083100001 34000000087600001
test_db_1 2020-02-05 20:28:55.000 2020-02-05 20:28:55.000 D
34000000080600037 34000000085100037 34000000086800001
test_db_1 2020-02-05 20:17:30.000 2020-02-05 20:17:30.000 L
34000000080600037 34000000078600001 34000000083100001
test_db_1 2020-02-05 20:17:02.000 2020-02-05 20:17:03.000 D
34000000074600075 34000000080600037 34000000082300001
test_db_1 2020-02-05 11:53:18.000 2020-02-05 11:53:18.000 L
34000000074600075 34000000050200075 34000000078600001
test_db_1 2020-02-05 11:52:50.000 2020-02-05 11:52:50.000 D
34000000050200075 34000000074600075 34000000077800001
test_db_1 2020-02-04 15:05:18.000 2020-02-04 15:05:18.000 D 0
34000000050200075 34000000053600001 Passo #2:
- Execute o backup completo do Avamar nos bancos de dados
- Execute a consulta para verificar os números da LSN novamente
SELECT last_lsn, type, user_name FROM msdb..backupset WHERE
database_name=N'test_db_1' AND type LIKE 'L' ORDER by last_lsn DESC O resultado dessa consulta é mostrado abaixo:
last_lsn type user_name
34000000087600001 L NT AUTHORITY\SYSTEM
34000000083100001 L NT AUTHORITY\SYSTEM
34000000078600001 L NT AUTHORITY\SYSTEM Passo #3:
- Executar backup incremental do Avamar
- Verifique os números da LSN executando a consulta abaixo
- Verifique se o backup_lsn do sqlmeta.xml corresponde ao que a consulta abaixo mostra:
SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id
= DB_ID(N'test_db_1')" O resultado dessa consulta é mostrado abaixo:
test_db_1 2020-02-12 16:44:40.000 2020-02-12 16:44:40.000 L
34000000089600037 34000000087600001 34000000092500001
test_db_1 2020-02-12 16:37:31.000 2020-02-12 16:37:31.000 D
34000000085100037 34000000089600037 34000000091300001
test_db_1 2020-02-05 20:29:23.000 2020-02-05 20:29:23.000 L
34000000085100037 34000000083100001 34000000087600001
test_db_1 2020-02-05 20:28:55.000 2020-02-05 20:28:55.000 D
34000000080600037 34000000085100037 34000000086800001
test_db_1 2020-02-05 20:17:30.000 2020-02-05 20:17:30.000 L
34000000080600037 34000000078600001 34000000083100001
test_db_1 2020-02-05 20:17:02.000 2020-02-05 20:17:03.000 D
34000000074600075 34000000080600037 34000000082300001
test_db_1 2020-02-05 11:53:18.000 2020-02-05 11:53:18.000 L
34000000074600075 34000000050200075 34000000078600001
test_db_1 2020-02-05 11:52:50.000 2020-02-05 11:52:50.000 D
34000000050200075 34000000074600075 34000000077800001
test_db_1 2020-02-04 15:05:18.000 2020-02-04 15:05:18.000 D 0
34000000050200075 34000000053600001 Passo #4:
- Execute backups incrementais SQL nativos.
- Como documentado abaixo, há três maneiras de fazer isso.
- https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-a-transaction-log-sql-server?view=sql-server-ver16
Passo #5:
- Execute outro backup incremental do Avamar orientado por políticas, o que deve gerar o erro "lacuna de log".
- Execute novamente a consulta de validação da LSN
- Verifique os logs para verificar se o backup falhou com o erro de lacuna de registro, conforme mostrado no trecho abaixo:
2020-02-12 16:58:01 avsql Info <19487>: Start checking for SMO DLL version
12...
2020-02-12 16:58:02 avsql Info <7065>: Working on target '(local)/test_db_1'
2020-02-12 16:58:03 avsql Info <40399>: Last full backup of target
'(local)/test_db_1' was found, labelnum = '45'.
2020-02-12 16:58:20 avsql Info <15765>: A log gap was identified or a full
backup was not found.
2020-02-12 16:58:20 avsql Error <40418>: Skipping database '(local)/test_db_1'
due to the following reason: A log gap was identified or a full backup was not
found.
2020-02-12 16:58:20 avsql Info <14245>: Creating a thread pool with 2 worker
threads.
2020-02-12 16:58:20 avsql Info <14275>: There is no more tasks to process.
2020-02-12 16:58:20 avsql Info <14271>: Waiting for worker threads to finish
...
2020-02-12 16:58:20 avsql Info <16256>: Creating process summary ...
2020-02-12 16:58:20 avsql Info <18493>: Status wrapup summary for all tragets
was processed.
2020-02-12 16:58:20 avsql Info <16257>: Inserted task: 0, completed: 0,
aborted: 0.
2020-02-12 16:58:20 avsql Info <16260>: Generating sql metadata ...
2020-02-12 16:58:20 avsql Error <14272>: There are no successfully finished
database tasks!
2020-02-12 16:58:20 avsql Error <14294>: An error occurred when generating sql
metadata
Execute a consulta abaixo para verificar a quebra na sequência de LSN
SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id
= DB_ID(N'test_db_1')" Resultado da consulta SQL para obter as informações de last_lsn para Databases:
database_name backup_start_date backup_finish_date type
database_backup_lsn first_lsn last_lsn
test_db_1 2020-02-12 16:52:42.000 2020-02-12 16:52:42.000 L
34000000089600037 34000000092500001 34000000095800001
test_db_1 2020-02-12 16:44:40.000 2020-02-12 16:44:40.000 L
34000000089600037 34000000087600001 34000000092500001
test_db_1 2020-02-12 16:37:31.000 2020-02-12 16:37:31.000 D
34000000085100037 34000000089600037 34000000091300001
test_db_1 2020-02-05 20:29:23.000 2020-02-05 20:29:23.000 L
34000000085100037 34000000083100001 34000000087600001
test_db_1 2020-02-05 20:28:55.000 2020-02-05 20:28:55.000 D
34000000080600037 34000000085100037 34000000086800001
test_db_1 2020-02-05 20:17:30.000 2020-02-05 20:17:30.000 L
34000000080600037 34000000078600001 34000000083100001
test_db_1 2020-02-05 20:17:02.000 2020-02-05 20:17:03.000 D
34000000074600075 34000000080600037 34000000082300001
test_db_1 2020-02-05 11:53:18.000 2020-02-05 11:53:18.000 L
34000000074600075 34000000050200075 34000000078600001
test_db_1 2020-02-05 11:52:50.000 2020-02-05 11:52:50.000 D
34000000050200075 34000000074600075 34000000077800001
test_db_1 2020-02-04 15:05:18.000 2020-02-04 15:05:18.000 D 0
34000000050200075 34000000053600001 sqlmeta.xml arquivo mostra o último backup_lsn como: 34000000092500001:
2020/02/12-21:58:20.86999 [avsql_assist] avsql_metadata::avsql_metadata
sqlmetadata = '<sqlmetadata threadpool_size="2" version="1.1">
<instance name="(local)">
<database last_incremental_backup="1581525880" last_restore_backup="0"
backup_lsn="34000000092500001" last_differentail_backup="0" name="test_db_1"
is_system="false" last_full_backup="1581525451"
differential_base_lsn="34000000089600037">
<backup_data stream_mark="stream" backup_lsn="34000000087600001"
av_group_replica="primary" num_vd_streams="1" name="f-0.test_db_1"
size="4915200" backup_time="1581525451">
<file_group name="PRIMARY">
<file file_type="Rows Data" physical_path="C:\Program Files\Microsoft
SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\test_db_1.mdf"
logical_name="test_db_1" />
</file_group>
<file file_type="Log" physical_path="C:\Program Files\Microsoft SQL
Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\test_db_1_log.ldf"
logical_name="test_db_1_log" />
</backup_data>
<backup_data stream_mark="stream" backup_lsn="34000000092500001"
av_group_replica="primary" num_vd_streams="1" name="i-1.test_db_1"
size="655360" backup_time="1581525880">
<file_group name="PRIMARY">
<file file_type="Rows Data" physical_path="C:\Program Files\Microsoft
SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\test_db_1.mdf"
logical_name="test_db_1" />
</file_group>
<file file_type="Log" physical_path="C:\Program Files\Microsoft SQL
Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\test_db_1_log.ldf"
logical_name="test_db_1_log" />
</backup_data>
</database>
</instance>
</sqlmetadata> O trecho de logs SQL de depuração do Avamar abaixo mostra que dois números LSN da consulta SQL e do sqlmeta.xml não correspondem:
2020/02/12-21:58:20.87599 [avsql_assist] <===
avsql_assist::evaluate_backup_lsn
2020/02/12-21:58:20.87599 [avsql_assist] ===>
sqlconnectimpl_smo::get_last_backup_lsn
2020/02/12-21:58:20.87599 [avsql_assist] retrieving last backup lsn for
'test_db_1' db from sys.database_recovery_status
2020/02/12-21:58:20.87599 [avsql_assist] ===> sqlconnectimpl_smo::InitDll
2020/02/12-21:58:20.87599 [avsql_assist] SMO dll already loaded.
2020/02/12-21:58:20.87599 [avsql_assist] <=== sqlconnectimpl_smo::InitDll
2020/02/12-21:58:20.87899 [avsql_assist] ==> SMOWrap::SMO_GetLastBackupLSN
2020/02/12-21:58:20.87899 [avsql_assist] database 'test_db_1', last backup lsn
= '34000000095800001'
2020/02/12-21:58:20.87899 [avsql_assist] <===
sqlconnectimpl_smo::get_last_backup_lsn
2020/02/12-21:58:20.87899 [avsql_assist] ===> avsql_metadata::get
2020/02/12-21:58:20.87899 [avsql_assist] ===> avsql_metadata::get
2020/02/12-21:58:20.87899 [avsql_assist] <=== avsql_metadata::get
2020/02/12-21:58:20.87899 [avsql_assist] <=== avsql_metadata::get
2020/02/12-21:58:20.87899 [avsql_assist] Last backup LSN: '34000000092500001',
Current LSN: '34000000095800001'
2020/02/12-21:58:20.87899 [avsql_assist] ===>
avsql_assist::align_numeric_ustrings
2020/02/12-21:58:20.88000 [avsql_assist] Before alignment - Str1:
'34000000092500001', Str2: '34000000095800001'
2020/02/12-21:58:20.88000 [avsql_assist] After alignment - Str1:
'34000000092500001', Str2: '34000000095800001'
2020/02/12-21:58:20.88000 [avsql_assist] <===
avsql_assist::align_numeric_ustrings
2020/02/12-21:58:20.88000 [avsql_assist] Aligned before compare- Last backup
(metadata) LSN: '34000000092500001', Current (SQL Server) LSN:
'34000000095800001'
2020-02-12 16:58:20 avsql Info <15765>: A log gap was identified or a full
backup was not found.
2020/02/12-21:58:20.88199 [avsql_assist] ===> sqlconnect::~sqlconnect
2020/02/12-21:58:20.89100 [avsql_assist] <=== sqlconnect::~sqlconnect
2020/02/12-21:58:20.89100 [avsql_assist] <===
avsql_assist::snapup_check_timestamps
2020-02-12 16:58:20 avsql Error <40418>: Skipping database '(local)/test_db_1'
due to the following reason: A log gap was identified or a full backup was not
found.
Para resolver essa falha e sincronizar as informações da LSN, execute um backup completo para esse banco de dados.
Affected Products
Avamar Plug-in for SQLArticle Properties
Article Number: 000214572
Article Type: How To
Last Modified: 05 Sept 2025
Version: 2
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.