You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This example shell script has a special stanza at the end to prevent AzAcSnap from killing the external command due to the timeout described earlier. This allows for
55
57
a long running command, such as uploading large files with azcopy, to be run without being prematurely stopped.
56
58
57
59
The snapshots need to be mounted on the system doing the copy, with at a minimum read-only privilege. The base location of the mount point for the snapshots should
58
60
be provided to the `sourceDir` variable in the script.
59
61
62
+
The snapshot is uploaded as a single file by using the `tar` command to create a gzipped tarball. This is done to keep the file permissions and ownership as uploading the files individually will lose these attributes.
Restoring from one of these archives stored in Azure Blob storage at a high-level is as follows:
259
+
260
+
1. Copy the snapshot archive back to the local machine into an area separate from the database files but with enough capacity to allow for the file archive and the extraction (e.g., /var/tmp).
261
+
1. If they created the archive using the `--runafter` example shell script, then they can possibly extract the gzipped tarball directly from Azure Blob storage into the target location using an AzCopy pipe to tar to extract, for example:
262
+
1.`cd ${TARGET_DIRECTORY}`
263
+
1.`azcopy cp "${BLOB_STORE}/${ARCHIVE_BLOB_TGZ}?${BLOB_SAS_KEY}" --from-to BlobPipe | tar zxvf -`
264
+
1. Extract the contents of the snapshot archive.
265
+
1. Review the contents of the target location after extracting, comparing file permissions and ownership to the original database files.
266
+
1. For example, do `ls -lR`.
267
+
1. Shutdown the database server.
268
+
1. Copy the files from the target location restored to in step 1 back to their original location.
269
+
1. Proceed with the normal database recovery process.
0 commit comments