Hi, I am curious what is in the .ipfs folder’s datastore? It seems like the blocks folder stores the files you pin and cat, but what about the stuff that are outside of blocks? (the datastore and keystore folders here)
The datastore folder is the leveldb database, used to store some stuff (like the mfs root). You can see this in the .ipfs/config file (Datastore/Spec/mounts part). When using badger, all information goes into badger, so the datastore folder/LevelDB and the blocks folders are not used.
The keystore folder is used to store keys as managed with the ipfs key subcommands.
datastore_spec keeps some additional info about datastores. I don’t remember exactly how it is used, but I think among other things it helps detecting mismatches between what’s on disk and what’s on the normal configuration (if the user changed it).
And version is the “repo version”. Used to detect whether migrations need to be run on upgrades.
1 Like
Thanks for the explanations! So does that mean as long as I keep what is in the blocks folder, I can retain the same files I have downloaded or pinned? I can delete everything else and start a new node pointing to the folder and it will work? (Work as in I can access the files and others are able to download them from me)
Yes, but better keep ~/.ipfs altogether.
1 Like
Are there downsides to not keeping ~/.ipfs together?
Basically I am storing only blocks in a cloud storage so I never lose the files I’ve downloaded. The rest are locally living in a VM that can shut down (maybe outage or cluster migration) and rerun ipfs init + connecting to the blocks when a new VM starts up.
Just want to see that if there will be issues if I only keep blocks. (Assume I only ever use ipfs cat and ipfs add/pin). Thank you!
Yes, the downside is that you’re not storing datastore, version and other files that let ipfs know how things are laid out. IPFS is not built under the assumption that a user has backed up only the blocks folder.