The “lxc image import” failing is because you’re attempting to import the generated image on the same server that produced it. You should just remove the image from the image store (with “lxc image delete”) after you’ve exported it as a tarball. That’ll solve that.
To clone a container, you’d just do “lxc copy SOURCE DESTINATION”, but that’s on a single local LXD. In your case, it looks like you’re trying to test your backup mechanism.
Say you have a container called “blah”. For backup as an image tarball, you’d do:
- lxc snapshot blah backup
- lxc publish blah/backup --alias blah-backup
- lxc image export blah-backup .
- lxc image delete blah-backup
Which will get you a tarball in your current directory.
To restore and create a container from it, you can then do:
- lxc image import TARBALL-NAME --alias blah-backup
- lxc launch blah-backup some-container-name
- lxc image delete blah-backup
This is still pretty indirect and abusing the image mechanism to use it as a backup mechanism though 
One alternative you could use is to just generate a tarball of /var/lib/lxd/containers/NAME and dump that on your NAS.
Restoring that is a bit harder though. You’ll need to create a /var/lib/lxd/storage-pools/POOL-NAME/containers/NAME path matching the name of the backed up container. Then if the storage pool is zfs or btrfs or lvm, you’ll need to create the applicable dataset, subvolume or lv and mount it on /var/lib/lxd/storage-pools/POOL-NAME/containers/NAME and then unpack your backup tarball onto it. Lastly, you can call “lxd import NAME” to have LXD re-import the container in the database.
I think we can do something quite a bit simpler by directly allowing the export/import of containers as tarballs but it may take a while until we get to that: https://github.com/lxc/lxd/issues/3730