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.

SQL/Database Replications

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?

Yes.

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?

Yes.

The server must have the exact same version of the server the database was replicated from to work.