Tags
I decided to move my Pleroma instance from my old cloud service to the new, free one (guess which one). The reason for moving is simply cost cutting. Turned out it it took more time than I anticipated.
First, I spun up a VM with specs I thought would be enough to host a Pleroma instance. I set up one with 2 cores and 12 GB RAM, and 100 GB block storage. Other than same number of cores this was an upgrade to the previous VM, which only had about 2 GB RAM and 60 GB block storage.
I largely followed the instructions here on backing up and moving instance. I stopped the Pleroma service, then dump the PostgreSQL database.
The rather tricky part is moving the files. Not only Pleroma configs, but also nginx config and systemd service file. I can recreate them, but it seems easier to just copy them to the new server. You can copy paste the text files, but what about the database dump? It was time for me to get acquainted with scp (secure copy). The database dump was about 792 MB, but it was transferred rather quickly.
The time-consuming part was restoring the database back when I was reinstalling Pleroma on the new server. When it was still not finished after 36 hours, I decided that the VM was probably adequate to handle day-to-day load for Pleroma, but underpowered for database restore task. I boosted the capacity by upping the processor cores to 8. I also did some PostgreSQL tuning (using PGTune).
I repeated the restoration task, and this time it was finished after about 12 hours. After the reinstallation task was completed I lowered the specs of the VM back to the original state.
Lesson learned: Database restoration task is very computationally intensive. When I searched around, the time-consuming nature of the task is apparently a known problem. I also appreciate the ability of cloud services to temporarily scale up VMs capability when necessary.