All I wanna here right now is that rc4 has no mistakes and I can pull the lever on final release and breathe free :thinkhappy:

@Gargron i updated to rc4 and i think the glaceon.social database got wiped but it was probably my own fault somehow

@monorail "mr monorail i dont feel so good" - your db

no but seriously that doesnt sound great i hope you figure it out or have backups

@Gargron would the federated timeline still work if the database was completely dead? how would it know which accounts the users followed. is there still a chance that the data is there or is this wishful thinking

@Gargron it's on the landing page glaceon.social

but i can't log in, and it says "home to 0 users who authored 0 statuses"

god i feel like such a moron for putting off learning how to set up backups

@monorail It's only posts since you restarted the server? Then it doesn't look good. What did you actually do that led to this? Something with docker-compose?

@Gargron i just tried updating normally but i didn't bring the instance down first like i usually do, just trying to update while it was running from memory and restarting after

i might have done `docker-compose down` instead of `stop` by accident but the thing i was looking at only said that would result in lost toots...

@monorail another victim to docker-compose's awful command naming. up isn't start, it's create. down isn't stop, it's destroy.

still, data volumes should not be deleted just because container is deleted, essentially the newly recreated container got a brand new volume instead. the old volume is still in the filesystem. your main mistake is not editing docker-compose.yml and uncommenting the thing that pins the volume to a permanent directory...

@monorail huh. okay. then the data should be there. i am confused

@monorail when did you uncomment it. before or after you ran docker-compose up -d?

@Gargron like, ages ago when i set the instance up

i tried to dump it with pg_dump to see if stuff is still in there but pg_dump fails with `role "myusername" does not exist`

@monorail if stuff existed it would show up on mastodon (also the command is something like:

docker exec mastodon_db_1 pg_dump -Fc -U postgres postgres > somefilename.dump

) What seems likely to me is that when you first started it, you hadn't uncommented the lines, and when you did, you didn't do up -d to recreate the containers with the new configuration, so they were running all this time as-if the lines were still commented out

Follow

@monorail if that's the case what i said originally is still the solution. the volume is out there in the system, you need to find the correct one and move the contents over to the new folder.

@Gargron do you think that either ~/live/postgress or /var/lib/postgresql/9.5/main has the right data and it has to be moved to the other

@Gargron i have no idea what any of this means

hastebin.com/oxenuxoleb.bash

i'm sorry i don't know what i'm doing

@monorail what about this command, what output does it give?

docker inspect -f '{{.Name}}: {{.Volumes}}' $(docker-compose ps -q)

@monorail anyway you can try looking inside /var/lib/docker/volumes/ONE_OF_THE_LONG_HASHES_YOU_GOT/_data for signs of it being a postgres database (compare to your new one at ./postgres). once you find it, stop the thing, delete insides of ./postgres and replace them with that old data, then start the thing again

@monorail no guarantees tho it's 4:38am for me and i am not strictly speaking customer support, you can try asking around others for help, use hashtag too

@Gargron thank you very much for your help. i promise if i get this working again i will not leave my chair until wal-e is set up

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!