@mint@kirby@matty@graf@sun@p@0@dcc Do any of you guys have experience restoring your pleroma database in postgres following the instructions detailed in https://docs-develop.pleroma.social/backend/administration/backup/ ? I've been trying to do a dry run of moving to my new VPS with the postgres dump I made a few days ago and it always hangs at pg_restore: creating INDEX "public.activities_visibility_index" and never completes even if I leave it for a whole day.
I'll give that a try. Follow up question, it's not going to make a difference if I wait to rollback the glussy migrations until after I restore on the new server, right? I just don't want to fuck anything up on the old VPS while we're still using it.
@Hoss@dcc@p@kirby@matty@0@graf@sun Of course. I think it's a batter course of action since you'll still have an active backup that could be switched back in case you fuck up.
@Hoss@dcc@p@matty@0@graf@mint@sun If you import the db next to a fresh install of pleroma i don't think you can perform the automated rollbacks properly, tried to rollback after i went back to 2.6.3 git commit and it only rolled back one thing rather than many like i was expecting
@kirby@dcc@p@matty@0@graf@Hoss@sun That migration with rollback you showed me was added months after the last Pleroma source sync in Rebased. Don't make him worry about it.
> I think it still doesn't help much if you're restoring the DB in one go.
Yeah, the issue is that the activities_visibility_index is created *before* the AP ID index. Using awk on the dump like the other thing in the post, that works.
It will take a long time to do a restoration. Use the jobs flag when restoring, based on the number of processors you have. So, if you have a 4c/8t processor do -j 8 and it should help with the speed, considerably.