Comments
Sort by recent activity
While Backup Operator is sufficient to open a connection to VDS (although I should note that since this is deprecated, SQL Clone now uses the Windows Storage Management API on supported platforms), that isn't enough to do operations that SQL Clone requires, such as attaching virtual disks. That requires the privilege "Perform volume maintenance tasks", which is only available to local Administrators by default (which Microsoft recommend as best practice). There's a lot of other permissions that would be required on top of Backup Operator to perform SQL Clone's basic functionality - I attempted a build which didn't enforce local admin and had to change permissions on certificate private keys and SQL Server data files, and grant "perform volume maintenance tasks" just to get part-way through the process, but that still wasn't sufficient to perform the required storage management API calls. Moreover, SQL Clone agents auto-update themselves by virtue of the fact that they are running as local admin, so even if we were able to find a lengthy set of permissions that could permit perform imaging/cloning, auto-updating would be broken without permission to install software. Of course, we would always want to keep the requirements for our software as low as possible, but haven't managed to find a reasonable way to run SQL Clone Agents with lower than local admin privileges given the kinds of operations it does. What we would generally recommend is to not install SQL Clone Agent on production systems where there would understandably be much greater scrutiny, and instead use backups to import data into the system. / comments
While Backup Operator is sufficient to open a connection to VDS (although I should note that since this is deprecated, SQL Clone now uses the Windows Storage Management API on supported platforms),...
Ah, thanks for the feedback - is that for the Server or Agent or both which required a fake password? We do have some code that's meant to accommodate gMSAs in credential validation but I'll take a look at it as there might be some incorrect checks somewhere. / comments
Ah, thanks for the feedback - is that for the Server or Agent or both which required a fake password? We do have some code that's meant to accommodate gMSAs in credential validation but I'll take a...
SQL Clone ought to work with Group Managed Service Accounts provided that the services are granted the permissions they require (SQL Clone Server needs Windows Auth access to its configuration database, while SQL Clone Agents need admin access on the machines on which they run, full control over locations where you create images, and Windows Auth access as sysadmin to local instances where you want to create images and clones where relevant). You should be able to specify the gMSA username and leave the password blank in their respective setup tools. If you run into any problems with this, though, do let us know. / comments
SQL Clone ought to work with Group Managed Service Accounts provided that the services are granted the permissions they require (SQL Clone Server needs Windows Auth access to its configuration data...
Is the SQL Clone Agent service running? Databases need to be remounted by the service on reboot, which should be done automatically by the Agent. / comments
Is the SQL Clone Agent service running? Databases need to be remounted by the service on reboot, which should be done automatically by the Agent.
Furthermore, if you are running SQL Clone 3 and running Data Masker as part of image creation, if you go to the Activity page in the web UI, you should be able to download the logs from there: [image] / comments
Furthermore, if you are running SQL Clone 3 and running Data Masker as part of image creation, if you go to the Activity page in the web UI, you should be able to download the logs from there:
Is this a machine on which you're creating images from live databases (as opposed to from backups)? If the conflict is occurring during image creation from live databases then it might be because both SQL Clone and Veeam are trying to simultaneously create Volume Shadow Copy snapshots, as Windows doesn't permit this to happen. This could be prevented by scheduling these operations to happen at different times, or by creating images from backup, which doesn't use the Volume Shadow Copy service. If the machine has clone databases on it, then depending on how your backups are performed, it's possible that it's attempting to back up the entirety of the database, including unchanged data. Excluding clone mount locations (by default, inside the SQL Server default data directory) from the VM backup could help if that's the case. SQL Clone works through disk virtualization. If there's an interruption in the network connection between the clone and its image while the database is being accessed, the resulting disk errors can cause the database can get stuck in an error state which requires restarting SQL Server to fix because of https://support.microsoft.com/en-us/help/4094893. The best way of preventing this is to ensure that this connection is reliable and low-latency - it's usually beneficial for images and clones to be on the same LAN. / comments
Is this a machine on which you're creating images from live databases (as opposed to from backups)? If the conflict is occurring during image creation from live databases then it might be because b...
Hi Robb, Does this occur on a machine where you are creating images from live databases? Since SQL Clone uses the Volume Shadow Copy Service to do this, there can be conflicts with other software which is trying to use the same service at the same time (we've heard of Veeam preventing SQL Clone from creating images because of this). If you're creating images from backup, this service isn't used. It would also be interesting to hear the error message that you're getting from Veeam to see whether it's likely to be this issue or something else. Chris / comments
Hi Robb,Does this occur on a machine where you are creating images from live databases? Since SQL Clone uses the Volume Shadow Copy Service to do this, there can be conflicts with other software wh...
Usually the reason that this would occur would be because the Clone Agent believes that it can no longer access the image (at which point the clones would become invalid to access, so we attempt to kill connections and detach the clone database until the image is availabl). Given that you say that the image is on the same machine, it sounds like this is something worth investigating, since the image shouldn't be intermittently unavailable. Could you share your agent logs with us as described in https://documentation.red-gate.com/clone2/troubleshooting/log-locations? It may be preferable to open a ticket by emailing support@red-gate.com rather than posting them on the forums. / comments
Usually the reason that this would occur would be because the Clone Agent believes that it can no longer access the image (at which point the clones would become invalid to access, so we attempt to...
Usually the reason that this would occur would be because the Clone Agent believes that it can no longer access the image (at which point accessing clone databases causes file system errors, so we attempt to kill connections and detach the clone database until the image is available again). Given that you say that the image is on the same machine, it sounds like this is something worth investigating, since the image shouldn't be intermittently unavailable. Could you share your agent logs with us as described in https://documentation.red-gate.com/clone2/troubleshooting/log-locations? It may be preferable to open a ticket by emailing support@red-gate.com rather than posting them on the forums. / comments
Usually the reason that this would occur would be because the Clone Agent believes that it can no longer access the image (at which point accessing clone databases causes file system errors, so we ...
Usually the reason that this would occur would be because the Clone Agent believes that it can no longer access the image (at which point accessing clone databases causes file system errors, so we attempt to kill connections and detach the clone database until the image is available again). Given that you say that the image is on the same machine, it sounds like this is something worth investigating, since the image shouldn't be intermittently unavailable. Could you share your agent logs with us as described in https://documentation.red-gate.com/clone2/troubleshooting/log-locations? It may be preferable to open a ticket by emailing support@red-gate.com rather than posting them on the forums. / comments
Usually the reason that this would occur would be because the Clone Agent believes that it can no longer access the image (at which point accessing clone databases causes file system errors, so we ...