SecuriveServers & databases
Physical server and database backup
Windows and Linux servers with bare-metal restore, and SQL Server, PostgreSQL, MySQL and Oracle recoverable to a point in time rather than to last night.
No credit card · 14-day trial · Migration assistance included
The problem
What goes wrong today
24 hours
A nightly dump means a day of lost transactions
If the only copy is last night's dump, the recovery point is last night. For anything transactional, that is a day of business gone.
Days
Rebuilding a physical box from scratch
Reinstalling the OS, drivers, roles and agents before the data can even go back is what turns a bad afternoon into a bad week.
Unknown
An RTO nobody has measured
Most teams cannot say how long a restore takes because they have never timed one end to end.
How it works
What Securive does about it
Bare-metal restore
Recover a whole server — OS, applications, configuration and data — to the same hardware or to dissimilar hardware, including into a VM.
Point-in-time database recovery
Transaction logs ship continuously, so you can roll a database to a moment: to 14:32, just before the bad migration ran.
Native, supported methods
SQL Server VSS writers, PostgreSQL WAL archiving, MySQL binlogs, Oracle RMAN — the vendors' own mechanisms, not a filesystem copy of a running datafile.
Application-consistent, always
Databases are quiesced through their own APIs before capture, so a restore point opens cleanly without recovery gymnastics.
Restore to a VM
A dead physical box can come back as a virtual machine while replacement hardware is on order.
Measured RTO
Scheduled restores time themselves, so your recovery objective is a figure from last week rather than an estimate from a document.
Specifics
The technical detail
- Operating systems
- Windows Server 2016+ · major Linux distributions
- Databases
- SQL Server · PostgreSQL · MySQL · Oracle
- Method
- Agent-based, block level with native quiescing
- Log shipping RPO
- Down to minutes
- Recovery
- Bare metal · to dissimilar hardware · to VM
- Granularity
- Volume, file, database, or single table
Known limitations
Published deliberately. You would find these during a proof of concept anyway — better to find them now.
- Point-in-time recovery requires the database to be in a logging mode that permits it — full recovery model on SQL Server, WAL archiving on PostgreSQL, binlogs on MySQL. We can enable it, but it is a change to the database.
- Bare-metal restore to dissimilar hardware may need drivers for the target's storage controller. Prove it in a drill before it is in the plan.
- Oracle support covers RMAN-based protection; direct storage-snapshot integration is Enterprise and depends on the array.
Recovery scenarios
What actually happens on the bad day
A file server is encrypted overnight
Restore points sit outside the server's reach, on versioned storage. Anything holding the server's credentials can encrypt what is in front of it, not the versions behind it.
Volume rolled back to the last clean hour.
A migration script corrupted production data at 14:32
Log shipping lets you recover the database to 14:31 rather than to last night, so only the migration is undone.
Minutes of data lost, not a day.
The RAID controller took the array with it
Bare-metal restore rebuilds the server onto new hardware, or onto a VM while replacement parts are in transit.
Back in service without waiting for hardware.
Comparison
Against how you do it today
- Recovery point
- Today: Last night's dump
- Securive: Any point in time, to the minute
- Full server recovery
- Today: Rebuild, reinstall, then restore
- Securive: Bare-metal restore, including to a VM
- Consistency
- Today: Copy of files on disk
- Securive: Native quiescing through the vendor's API
- RTO
- Today: Estimated in a document
- Securive: Measured weekly and reported
- Surviving a leaked key
- Today: Depends where the dump landed
- Securive: Versioned storage; the backup key cannot delete a version
Questions
The things people ask before they switch
With log shipping enabled, to the minute — often to the transaction. Without it, to the last full or incremental backup.
For point-in-time recovery, yes: the database must retain its transaction logs. It's a standard, supported configuration, and we'll walk through the change with you.
Yes. Physical-to-virtual restore is a normal path and is the usual answer while replacement hardware is on order.
Servers and databases are agent-based — that's how native quiescing is possible. The agent reads at block level and is throttled so it doesn't compete with production.
Yes. Restore points can be mounted and individual objects extracted without recovering the entire instance.
Find out whether your backups actually restore.
Connect one hypervisor, set one policy, and let a scheduled drill try to bring it back. If it doesn't, you'll know in a day rather than during an incident.
No credit card · 14-day trial · Migration assistance included