Files and Pins recover after crash?

I have a Go-IPFS node that runs happily on a little Linux box in my corner most of the time, though recently the whole computer crashed and had to be restarted. When I restarted the IPFS node, all the files and pins were reset to the default (just the two default pins that were represent the “empty folder” and the tutorial/readme info). The “data” folder for the IPFS node appears to be intact; is there a specific file I can find on the filesystem to inspect and hopefully restore those?

Seeing this conversation about copying “the pin file”, since the computer crashed while the daemon was running, it’s possible the pin file got corrupted?

Where on disk (where in the “data” folder) is the root pin file, that I could back it up and be able to at least restore from a backup in this sort of situation?

I’ve stopped my node for now, given that it’s possible that the data is all there, just “unpinned”, and if the node keeps running it may eventually garbage-collect it?

What does this command show? Copied IPFS data directory onto new host but it's showing no pins - #16 by adin

I find it strange that pins would just dissapear. Can you verify you are starting ipfs exactly as before (same user, same config folder etc).

That ipfs-ds script doesn’t seem to have any instructions on how to compile it, nor any downloadable binaries? I only see Go source files in the repo, and none of them named ipfs-ds.go, so not sure how that script is obtained?

I run my server via a Docker container, launched from a systemd service file, and I didn’t upgrade Docker nor change the service script recently, so I’m pretty sure those weren’t contributing factors.

Taking a look at my “data” folder with the service off, I see it only takes up 29 MB of space, while I know I had over 1 GB of content in the “files” architecture previously, so that says to me my content is probably no longer there on the IPFS node and I’ll have to re-add it from other copies of those files, unfortunately…

any chance you were not mounting your “data” volume in the place where it should be mounted so that it actually didn’t get used?

Here’s the service file I’ve been using:

[Unit]
Description=IPFS daemon
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
Restart=on-failure
RestartSec=10
ExecStartPre=-/usr/bin/docker stop %n
ExecStartPre=-/usr/bin/docker rm %n
ExecStartPre=/usr/bin/docker pull ipfs/go-ipfs:v0.7.0
ExecStart=/usr/bin/docker run --name %n \
  -p 8080:8080 -p 4001:4001 -p 5001:5001 \
  -v /opt/ipfs/staging:/export \
  -v /mnt/data/ipfs:/data/ipfs \
  -w /export \
  ipfs/go-ipfs:v0.7.0
ExecStop=/usr/bin/docker stop %n

[Install]
WantedBy=multi-user.target

So, I’ve been saving the contents of /data/ipfs (path location inside the Docker container) to an external hard drive (/mnt/data/). If IPFS has actually been saving other content to a different location outside of /data/ipfs, then that’s not been part of my “backups” of that data, and some Docker internal garbage collection might have lost it?

No… your service file looks alright :confused:

lol sorry about that, I wrote that tool pretty quickly to do some diagnostic work. It’s a pretty simple Go project if you just clone the repo and do go build it’ll create the binary (or go install to automatically put it in your Go binary path).

Edit: I updated the repo README, if you run into any problems or have any issues feel free to file an issue/PR.