SQL Server and MySQL backup, without stopping the application
Consistent database backups taken while your system keeps running — because an accounting system cannot close for the night.
Why databases need their own answer
Copying a database file while the database is running usually produces a file that will not restore. The engine is writing to it, and a half-written copy is a broken copy. That is why a plain file backup of a live SQL Server or MySQL server can look perfectly healthy for a year and then fail on the one day it matters.
Proper database backup asks the engine itself for a consistent copy, so what lands in storage is something that will actually open again.
What we cover
- Microsoft SQL Server, including full, differential and transaction-log backups
- MySQL and MariaDB
- The application data files that sit alongside the database and are just as necessary
Point in time, not just last night
With transaction-log backups in place, recovery is not limited to "yesterday at 11 pm". You can go back to a specific moment — for example, just before the wrong entry was posted. For accounting, inventory and ERP systems this is often the difference between an inconvenience and a month of re-entry.
Proving it works
We restore a database with you as part of setting up, to a spare instance, so you have watched your own data come back. It takes an afternoon and it changes how you sleep.
Databases we back up
- Microsoft SQL Server (full, differential and transaction log)
- MySQL and MariaDB
- Application data files stored alongside the database
- Scheduled consistency checks so a broken backup is noticed early
Questions about sql server backup
Can you back up SQL Server while it is running?
Yes. We ask the database engine itself for a consistent copy, which is what makes the backup restorable. Copying the database file while the engine is writing to it usually produces something that will not open — a common and expensive surprise.
Can I recover to a specific moment, not just last night?
With transaction-log backups in place, yes — you can go back to a point in time, for example just before a wrong entry was posted. This matters most for accounting, inventory and ERP systems.
Not sure which plan fits?
Tell us what you need protected — how many machines, how much data, which databases — and we will tell you honestly what it takes.