OS Name/Version: Debian 12.9 - Bookworm
Product Name/Version: AMP (any edition) 2.6.0.12
Problem Description: You want to move an instance to a new datastore!
Preface
This is not an issue I am having, but I wanted to provide steps for migrating an instance to a new datastore, hopefully this can be made into a KB article. This is probably a semi-common task, eg. for users who acquire new disks and want them to be separate datastores as opposed to extending the default. In my case, I got some new faster drives, and wanted to have a “priority” datastore for my more frequently-used instances, to avoid filling up the smaller available space. These steps should be applicable to any Linux AMP instance, but a similar process probably applies to Windows instances, too.
Backup!
Always start by backing things up in case things go sideways. If running on a VM, that means taking a snapshot or a true backup. If running on real hardware, you can take a full clone of the relevant disks (which may be slow), or you can just make a copy of AMP’s default datastore, plus the datastore currently housing your instance (if separate).
Identify Instance
Next is to identify the instance you want to move. In your current datastore, find the folder that contains the instance files. If you’re on AMP’s default datastore this will be at /home/amp/.ampdata/instances/<your-instance>.
You’ll also want to identify it in the instances.json file (at /home/amp/.ampdata/instances.json) - this is a big JSON file, but look for the section that contains your instance.
Copy Files
Start by stopping your instance to prevent file changes. Then, copy (or move if you’re brave) the instance files to the new datastore - it’s important that you move the folder, and not just the files within the folder. AMP does not like when the instance files are floating in the datastore (eg. move <your-instance>, not <your-instance>/*). The best way to do this is with rsync. Assuming the target location is /new-datastore:
rsync -aX /home/amp/.ampdata/instances/<my-instance> /datastore/
This takes care of preserving file permissions and other metadata, which is something that could bite you when using other file migration strategies if you’re not careful. It also takes care of moving files over the network, if you configure either end to be remote.
Note that there is ==not== a trailing slash on the first path. If you include it, the files will be floating, and you’ll need to clean out the target before rerunning the command. That’s an easy task when the datastore is empty; less so when it’s got files in it. If you’re unsure, you can use the following command to see what the result would be without actually making any changes:
rsync -aXv /home/amp/.ampdata/instances/<my-instance> /datastore/ --dry-run
If each line starts with the instance folder name (instead of the filename of a file within the folder), you’re good and can drop the --dry-run flag!
Update AMP
Now, if you tried to start the instance right this moment, AMP would still be using the old datastore. This is because we haven’t told it that the instance has moved, nor have we deleted the original copy. Let’s start by updating AMP.
Go to the instances.json file we discovered previously (which should not have moved), and open it. Find your instance, and edit the "Path" key to point to the new location. Then, restart AMP itself (either reboot the entire machine or just restart the AMP service). Now, AMP will use the new location for the instance - you should be able to confirm this by going to the file manager and navigating to it.
If you want to ensure it’s using the new datastore before deleting files, you can try creating a random text file at the old location (eg. blah.txt), and then use the VDS shortcut in AMP’s file manager to see what the contents are. If the file manager does NOT show the file, everything worked! If it does show the file, it means AMP is still looking for the old directory.
At this point, you should delete the old instance files - having multiple copies could be confusing and wasteful, and in worst-case scenarios (eg. if AMP’s configuration was rolled back somehow), could lead to split progress.