SQL Server - Restore de backup trará os dados como eles estavam no início ou no término do backup?

Olá,

No SQL Server, suponha que um backup FULL do banco de dados XYZ se inicia às 00:00 e termina às 04:00. Vale a pena salientar que o banco de dados está aberto e recebendo transações normalmente durante a execução do backup. Agora vem a pergunta: Se precisarmos realizar uma restauração desse backup, os dados do banco de dados XYZ serão restaurados como eles estavam às 00:00 ou como eles estavam às 04:00?
 

Fazendo uma comparação com outros bancos de dados teremos o seguinte:

• Oracle RMAN: O backup feito devidamente em conjunto com os archivelogs restaurará o banco de dados como ele estava ás 04:00.

• Oracle Datapummp: Se for utilizado a cláusula flashback_time=systimestamp do comando expdp, o dump será consistente a partir do início do backup, ou seja, o dump restaurado trará os dados como eles estavam ás 00:00.

• MySQL: Se for utilizado a cláusula --single-transaction do comando mysqldump, os bancos dedados não serão lockados durante o backup e o dump será consistente a partir do início do backup, ou seja, o dump restaurado trará os dados como eles estavam ás 00:00.

• MongoDB: Se for utilizado a cláusula --oplog do comando mongodump, ao final do backup, será realizado um backup também da collection oplog que poderá ser utilizada para aplicar as transações realizadas durante o backup e restaurar os dados como eles estavam ás 04:00. Caso seja utilizado a tecnologia de snapshot como por exemplo no disco EBS da AWS, o snapshot restaurado trará os dados como eles estavam ás 00:00. Vale a pena salientar que o MongoDB precisaria ter sido inicializado com a opção --journal.

E no caso do SQL Server, a restauração do backup trará os dados como eles estavam ás 04:00. Algumas evidências como esta e essa, comprovam esta afirmação.      

               

"A full database backup provides a complete copy of the database and provides a single point-in-time to which the database can be restored. Even though it may take many hours for the backup process to run, you can still only restore the backup to a single point (effectively at the end of the backup, but I'll discuss exactly what that point is later in this article). A full backup does not allow recovery to any point in time while the backup was running. Another misconception about full backups is that they only contain data. Both full backups and differential backups also contain some transaction log records so that the restored component (database, file, or filegroup) can be made transactionally consistent."

               

"Consider an example transaction that inserts a record into a table with a single nonclustered index. The pages of the table and index are spread through the data file. The transaction is split into two parts internally: a record insertion into a data page in the table and then the insertion of the required record in an index page in the nonclustered index. If the backup process just happens to read the nonclustered index page before the record insertion, but reads the table data page after the record insertion, then the database represented by just the data in the backup is transactionally inconsistent. This is where the transaction log comes into play. By also including some transaction log records in the backup, recovery can be run on the restored copy of the database, making it transactionally consistent. For this example transaction, depending on when it commits, the recovery part of restore may roll it forward (meaning it will appear as committed in the restored copy of the database) or roll it back (meaning it will not appear at all in the restored copy of the database). In either case, transactional consistency is maintained, which is crucial."