Axcient intelligently backs up Microsoft Exchange and SQL Server databases.
In an image replication job or when you specify Use Open File Manager in a file replication job, Axcient does the following steps when backing up an Exchange or SQL Server database:
1. Alerts the application to quiesce the database gracefully to a safe state.
2. Takes a snapshot of the database.
3. Alerts the application that the database snapshot is complete.
For this process to work properly, it is essential that all pertinent files be included:
- In an image job, select all disks that contain Exchange or SQL Server database and transaction log files.
- In a file job, select all folders on every disk that contain Exchange or SQL Server database and transaction log files.
See your Exchange or SQL Server documentation for information about the database and transaction log files that must be backed up.
Axcient flushes the logs as a part of backing up Exchange and SQL Server, but managing log file growth is left to the application, which can be an issue in the case of SQL Server. See the SQL Server documentation for information on managing log files.
Avoid Circular Replications
Disk space is usually at a premium, and the partner deploys a specific entitlement based on their client’s needs. Some local practices can affect how much storage space is required.
Circular logging on an Exchange database should be disabled if the log flushing option is selected in the image or file job.
This is important to note: if you have two replications of the same databases or servers with the flush setting enabled, it will cause issues with the replications, since one job will flush the logs at a different time than the other causing, data to be missing.
The best practice is to enable log flushing on the image job, and then, if a file job exists, to disable flushing there.
Of course, always disable the circular logging on the exchange server so that the Axcient image job can be responsible for capturing all the logs and truncating them efficiently.
File replications can also have log flushing, as long as the image job on the same server has exclusions for the database and log files in the image definitions for the databases that the file job is backing up.
SQL Replication Recovery Model
By default, SQL databases are set to use a replication recovery model of SIMPLE in the database properties>options. This setting should be sufficient and is optimal, working best with the Axcient replications. See the table below:
MS SQL Replication Recovery Model – Adjustable through SQL Management Studio.
|Recovery model||Description||Work loss exposure||Recover to point in time?|
No log replications. Automatically reclaims log space to keep space requirements small, essentially eliminating the need to manage the transaction log space. For information about database replication under the simple recovery model, see Full Database Backups (SQL Server).
|Changes since the most recent replication are unprotected. In the event of a disaster, those changes must be redone.||Can recover only to the end of a replication. For more information, see Complete Database Restores (Simple Recovery Model).|
|Requires log replications. No work is lost due to a lost or damaged data file.Can recover to an arbitrary point in time (for example, prior to application or user error). For information about database replications under the full recovery model, see Full Database Backups (SQL Server) and Complete Database Restores (Full Recovery Model).||Normally none.If the tail of the log is damaged, changes since the most recent log replication must be redone.||Can recover to a specific point in time, assuming that your replications are complete up to that point in time. For information about using log replications to restore to the point of failure, see Restore a SQL Server Database to a Point in Time (Full Recovery Model).
|Bulk logged||Requires log replications. An adjunct of the full recovery model that permits high-performance bulk copy operations.Reduces log space usage by using minimal logging for most bulk operations. For information about operations that can be minimally logged, see The Transaction Log (SQL Server).||If the log is damaged or bulk-logged operations occurred since the most recent log replication, changes since that last replication must be redone. Otherwise, no work is lost.||Can recover to the end of any replication. Point-in-time recovery is not supported.|
The local replication strategy can affect how much space is needed to replicate an SQL (or other) database.
For example, the user may be replicating their SQL database as SQL.backup.date1, SQL.backup.date2, SQL.backup.date3, and so on. Because each file has a unique name, the Axcient solution replicates every file. If each of the three files in the example was 20 GB, then you have just consumed 60 GB of storage space.
The Axcient solution uses reverse differential methodology to perform replications. This means that on each subsequent job run, it backs up just the differences from the previous run for an existing file.
However, any file with a new name must be replicated in its entirety, which results in excessive storage when this type of local replication strategy is used. To resolve the example outlined above, name the main replication file SQL backup and simply apply any changes to that file on a daily basis. This allows the Axcient technology to correctly replicate the file and save space on the appliance.
What are the best practices for protecting SQL servers?
- Avoid or minimize defrag or other operations that cause the blocks in the SQL files to be moved around. Otherwise, the replication will interpret moved blocks as new blocks and back them up, which increases the size of the incremental replications.
- If performing file replications of a SQL database, enable OFM for VSS snapshots. This will ensure application consistent replications.
- Databases are sometimes configured to automatically generate what are called “rolling backup files”. Evidence of this is the presence of .bak files, often with a timestamp or sequence number incorporated into the file name. Each such file is a complete copy of the database and will be backed up if not excluded from the replication job. If rolling replication files must be backed up, a space-saving technique is to rename each uniquely named generated file to a common file name prior to the replication job. Doing this causes only the changed blocks of data to be captured within each incremental replication.
Is it possible to perform a granular SQL restore?
Virtualize a server restore point on the appliance, export the desired SQL records, and then import the records to the production database.
Is it possible to restore a database to an alternate server?
The server must have the exact same version of the server the database was replicated from to work.