Tagged in

SQL Server

Rubrik -  - Performing DBCC Health Checks with SQL Server Live Mount

Product

Performing DBCC Health Checks with SQL Server Live Mount

For many organizations, Microsoft SQL Server supports their most critical applications and has become a key component for modernizing their data center. However, managing and protecting SQL workloads is often a cumbersome and inefficient process. That’s why Rubrik pioneered Live Mount capabilities for SQL Server, which enables SQL recoveries and clones in seconds. Rubrik’s SQL Server Live Mount brings many benefits to organizations and is best known for providing fast item-level recovery. But Live Mount is also a powerful tool for accelerating app development, supporting many testing and development scenarios. Under the Hood of SQL Server Live Mount Many Rubrik customers chose to utilize SQL Server Live Mount for testing and development use cases due to its high efficiency. With Live Mount, there is no need to provision storage resources for point-in-time (PIT) database copies, nor is there a need to wait for complete PIT copies to traverse the network. This efficiency is achieved by utilizing Rubrik’s resources as the underlying storage that hosts our database file structure. The PIT backups, along with any transaction logs, are replayed and presented to the SQL Server of choice via an SMB 3.0 share. The RBS then creates a new database on the…
Rubrik -  - Stop Waiting for Full Restores: SQL Server Live Mount for Item-Level Recovery

Product

Stop Waiting for Full Restores: SQL Server Live Mount for Item-Level Recovery

Regardless of how big or small an organization is, chances are that they rely heavily on a database to power some of their most important mission-critical applications. For this reason, organizations go to great lengths to ensure databases are protected and data has been backed up multiple times to various locations. While the focus seems to always be on backups, a strong data protection strategy must also take into consideration recovery–more specifically, the Recovery Time Objectives (RTO). After all, it’s the recovery that gets us back online, granting end-users and customers access to what they need. The database of choice for many enterprises is Microsoft SQL Server. Traditional recovery methods that move data from a data protection solution back into production SQL Servers are ideal for entire database restores, but they lack the ability to restore individual tables or records. Should we really have to wait for storage to be provisioned and a complete database to be copied across the network just to restore a few rows or records that were accidentally deleted? When dealing with large databases, traditional recovery methods can drastically affect whether or not an RTO is met. Even more, when dealing with highly-transactional databases, companies run…