Hi I occasionally see this error, e.g. this morning in my archiving log::
ARCHIVING: Authentik | FROM: gateway-obiwan | TO: skywalker-archive | PROJ: gateway-Week-32
Error: Error transferring instance data: Failed migration on target: Failed creating instance on target: Volume already exists on storage but not in database
I use Incus a lot, and I especially love the incus copy --refresh feature to create functioning copies of everything important to me. I am used to seeing this error, which is caused by a prior copy failure that happens sooner or later for a variety of reasons when you send to servers, and I know exactly what to do - destroy the partial file on storage and re-run the copy, so I have to:
Notice the error in a log where I am copying a lot of files.
Log into the : storage node (in this case, it’s not a local storage server)
zfs list the dataset where the storage is to find the file, then zfs destroy -r it. A safe way to do this for me is something like this:
zfs list -r nvme | grep Week-32 | grep Authentik
nvme/deduppool/containers/gateway-Week-32_Authentik 2.18G 3.05T 2.18G legacy
zfs destroy -r nvme/deduppool/containers/gateway-Week-32
(I know you can do this all on one line, and it’s a “thing of wonder” to watch a syntax error gladly destroy several hours of prior copies that were NOT meant to be destroyed, so I personally tend to go slowly with zfs destroy -r now). Then I can re-run the copy and it works again.
I am wondering if this (and possibly more) could be solved by having a --force copy option, so that incus attempts to delete the storage on the :pool if this occurs automatically. 'twould be a handy-dandy feature for script-lovers.
Just an idea. And since I rarely have any, I thought I could use it as an excuse to post, say hi and to again say, THANK YOU ! to the Incus Team for your excellent product, which has been the heart of my homelab since I first started using LXD back in 2017.
V/R
Andrew