Mounting options can also be configured for both first and second-generation copies. See the AppSync User and Administration Guide for mounting option details. Each application type has different mount options that are not covered within this white paper. However, the following notes should be considered:
- The first-generation copy is not typically mounted when planning on taking second-generation copies, unless using the repurposing workflow for data masking purposes. Specifically, this action applies to changing the data on the first-generation copy before creating the second-generation copy.
- The first-generation copy should never be mounted while creating the second-generation copy since there is no application integration with the second-generation copy, and it is an exact duplicate of the first-generation copy. If there is I/O on the first-generation copy when creating the second-generation copy, it is likely the second-generation copy will not be in a consistent state.
- Since first-generation copies are application-aware, in cases with SQL Server and Oracle, they can be recovered. However, since second-generation copies are not application-aware, they cannot be recovered in an automated fashion with AppSync. Post-mount scripts can be used for this purpose, and the unmount callout script must be used before refreshing the second-generation copy. See the AppSync User and Administration Guide for more details about unmounting callout scripts for second-generation copies.