Guides · LUSONA · Updated 2026-09-23 · 8 min

SQL Server backups are not disk snapshots

Cópias do SQL Server não são instantâneos de disco

English

A photograph of the disk can catch a database mid-write. The program’s own backup is the one you restore on a Tuesday.

Two layers

LUSONA snapshots the virtual disk. That brings the whole Windows machine back, including SQL Server, if the machine itself is lost. It is the wrong tool for “put yesterday’s invoices back and leave today’s alone”. SQL Server has its own backup: a full backup, optional differentials, and a transaction log if you need a point in time. Those files are what you restore into the running instance.

A schedule that fits an office

For a small accounting database, a full backup every night to a second disk (not only to C:) is the minimum. If the file is under a few gigabytes, that night job finishes before anyone arrives. Keep seven daily files, and delete older ones in the same job so the disk does not fill with backups of backups. Once a week, copy one of those files off the server entirely, using the method in the file-moving guide.

Test a restore twice a year onto a spare database name, not over the live one. A backup that has never been restored is a rumour. If the restore asks for a login you do not have, write that down now, while the person who installed SQL still remembers it.

Before a risky import

Take a SQL backup immediately before an import, a year-end, or a program upgrade. Do not rely on last night. Tell us if you also want a disk snapshot at that moment: we can take one, and you still keep the SQL file. If the import goes wrong, restore the SQL backup first. Roll the whole disk back only if Windows itself is broken.

Português

Uma fotografia do disco pode apanhar uma base de dados a meio de uma escrita. A cópia do próprio programa é a que se restaura numa terça-feira.

Duas camadas

Os instantâneos da LUSONA fotografam o disco virtual. Isso traz a máquina Windows inteira de volta, incluindo o SQL Server, se a máquina em si se perder. É a ferramenta errada para “repor as faturas de ontem e deixar as de hoje”. O SQL Server tem a sua própria cópia: uma cópia completa, diferenciais opcionais, e um diário de transações se precisar de um momento exacto. Esses ficheiros é que se restauram na instância em funcionamento.

Um horário que serve um escritório

Para uma base de dados pequena de contabilidade, uma cópia completa todas as noites para um segundo disco (não só para C:) é o mínimo. Se o ficheiro tiver poucos gigabytes, esse trabalho nocturno acaba antes de alguém chegar. Guarde sete ficheiros diários e apague os mais velhos no mesmo trabalho, para o disco não encher com cópias de cópias. Uma vez por semana, copie um desses ficheiros para fora do servidor, pelo método do guia de mover ficheiros.

Teste um restauro duas vezes por ano para um nome de base de dados à parte, não por cima da que está em uso. Uma cópia que nunca foi restaurada é um boato. Se o restauro pedir um início de sessão que não tem, anote isso agora, enquanto quem instalou o SQL ainda se lembra.

Antes de uma importação arriscada

Faça uma cópia SQL imediatamente antes de uma importação, de um fecho de ano ou de uma atualização do programa. Não conte com a da noite passada. Diga-nos se também quer um instantâneo de disco nesse momento: podemos fazê-lo, e você fica na mesma com o ficheiro SQL. Se a importação correr mal, restaure primeiro a cópia SQL. Reverta o disco inteiro só se o próprio Windows estiver partido.

Questions: info@lusona.org and contact@lusona.org.