Home > Workload Solutions > SQL Server > White Papers > SQL Server 2019 Containers on Linux > Step 6: Run a destructive test and recover the modified database
In this use case scenario, the quality assurance teams perform automated destructive testing on the most recent version of the AdventureWorks database application, and the tests fail. Therefore, the developer returns to the state that preceded the destructive testing by removing the attached storage and restoring the AdventureWorks database from the XtremIO Virtual Copies snapshot.
The developer uses the following YAML file to restore the database to the former version:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mssql-restore
spec:
snapshotClassName: csi-xtremio-sc
dataSource:
name: mssql-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
ReadWriteOnce
Resources:
Requests:
Storage: 8Gi
The following figure shows the database restore in Kubernetes:
Figure 15. Restoring the database in Kubernetes
Restoring the database is fast, saving our developer valuable time. The capability of incrementally saving work with the XtremIO Virtual Copies feature provides for more iterative development by: