2022-07-21 20:19:47 +02:00
# The data directory
2023-04-11 17:42:35 +02:00
Nimbus stores all the information it needs to run in a data directory.
In this directory, you'll find a database, your validator keys and secrets, and several other items.
2022-07-21 20:19:47 +02:00
When following the installation guide, the chain data will be stored in `build/data` with separate directories for each chain (mainnet, prater, etc).
2022-07-24 22:13:47 +02:00
!!! tip "The `--data-dir` option"
2023-04-11 17:42:35 +02:00
The `--data-dir=/path/to/data` allows picking a specific data directory to store the chain.
Make sure you use the same `--data-dir` option for all beacon node commands!
2022-07-21 20:19:47 +02:00
## Contents
Inside the data directory, you'll find several subdirectories and files containing various information about the node, chain and validators.
You can examine the contents of the data directory using the `ls -l` command:
```sh
cd nimbus-eth2
ls -l build/data/shared_mainnet_0
```
```sh
-rw-r--r-- 1 nimbus nimbus 234 Jul 19 18:18 beacon_node.enr
drwx------ 1 nimbus nimbus 22 Jul 19 18:18 db
drwx------ 1 nimbus nimbus 196 Jul 19 17:36 secrets
drwx------ 1 nimbus nimbus 250 Jul 19 18:18 validators
```
### `db`
2023-04-11 17:42:35 +02:00
The `db` folder contains historical chain data and information about the latest observed state of the chain.
If you remove the `db` folder, the beacon node will have to resync.
2022-07-21 20:19:47 +02:00
History pruning (fixes #4419) (#4445)
Introduce (optional) pruning of historical data - a pruned node will
continue to answer queries for historical data up to
`MIN_EPOCHS_FOR_BLOCK_REQUESTS` epochs, or roughly 5 months, capping
typical database usage at around 60-70gb.
To enable pruning, add `--history=prune` to the command line - on the
first start, old data will be cleared (which may take a while) - after
that, data is pruned continuously.
When pruning an existing database, the database will not shrink -
instead, the freed space is recycled as the node continues to run - to
free up space, perform a trusted node sync with a fresh database.
When switching on archive mode in a pruned node, history is retained
from that point onwards.
History pruning is scheduled to be enabled by default in a future
release.
In this PR, `minimal` mode from #4419 is not implemented meaning
retention periods for states and blocks are always the same - depending
on user demand, a future PR may implement `minimal` as well.
2023-01-07 11:02:15 +01:00
The growth of the database depends on the [history mode ](./history.md ).
2022-07-21 20:19:47 +02:00
### `secrets` and `validators`
2023-05-09 11:16:43 +03:00
These two folders contain your validator keys, as well as the passwords needed to unlock them when starting the beacon node. By default, the folders are nested directly under the selected data directory, but you can alter the location through the options `--validators-dir` and `--secrets-dir` .
2022-07-21 20:19:47 +02:00
2022-07-22 21:47:24 +02:00
!!! warning
2023-04-11 17:42:35 +02:00
Be careful not to copy the `secrets` and `validator` folders, leaving them in two locations!
Instead, always _move_ them to the new location.
Using the same validators with two nodes poses a significant slashing risk!
2022-07-21 20:19:47 +02:00
2023-05-09 11:16:43 +03:00
For each imported validator, the validators directory includes a sub-folder named after the 0x-prefixed hex-encoded public key of the validator. The per-validator directory contains either a [local keystore file ](https://eips.ethereum.org/EIPS/eip-2335 ) with the name `keystore.json` or [remote keystore file ](./web3signer.md ) with the name `remote_keystore.json` . It may also contain the following additional configuration files:
* `suggested_fee_recipient.hex` - a hex-encoded execution layer address that will receive the transaction fees from blocks produced by the particular validator.
* `suggested_gas_limit.json` - the suggested gas limit of the blocks produced by the particular validator.
For each imported validator with a local keystore, the secrets directory includes a file named after the 0x-prefixed hex-encoded public key of the validator. The contents of the file will be used as the password for unlocking the keystore. If a password file for a particular validator is missing, Nimbus obtains the password interactively from the user on start-up. If the `--non-interactive` option is specified, Nimbus considers a missing password file to be a fatal error and it will terminate with a non-zero exit code.
2022-07-21 20:19:47 +02:00
## Moving the data directory
You can move the data directory to another location or computer simply by moving its contents and updating the `--data-dir` option when starting the node.
## Permissions
2023-04-11 17:42:35 +02:00
To protect against key loss, Nimbus requires that files and directories be owned by the user running the application.
Furthermore, they should not be readable by others.
2022-07-21 20:19:47 +02:00
It may happen that the wrong permissions are applied, particularly when creating the directories manually.
The following errors are a sign of this:
- `Data folder has insecure ACL`
- `Data directory has insecure permissions`
- `File has insecure permissions`
Here is how to fix them.
2023-04-11 17:42:35 +02:00
=== "Linux / BSD / MacOS"
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
Run:
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
```sh
# Changing ownership to `user:group` for all files/directories in < data-dir > .
chown user:group -R < data-dir >
# Set permissions to (rwx------ 0700) for all directories starting from < data-dir >
find < data-dir > -type d -exec chmod 700 {} \;
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
# Set permissions to (rw------- 0600) for all files inside < data-dir > /validators
find < data-dir > /validators -type f -exec chmod 0600 {} \;
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
# Set permissions to (rw------- 0600) for all files inside < data-dir > /secrets
find < data-dir > /secrets -type f -exec chmod 0600 {} \;
```
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
In sum:
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
- Directories `<data-dir>` , `<data-dir>/validators` , `<data-dir>/secrets` **must** be owned by user and have `rwx------` or `0700` permissions set.
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
- Files stored inside `<data-dir>` , `<data-dir>/validators` , `/secrets` **must** be owned by user and have `rw------` or `0600` permission set.
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
=== "Windows"
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
From inside `Git Bash` , run:
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
```sh
# Set permissions for all the directories starting from < data-dir >
find < data-dir > -type d -exec icacls {} /inheritance:r /grant:r $USERDOMAIN\\$USERNAME:\(OI\)\(CI\)\(F\) \;
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
# Set permissions for all the files inside < data-dir > /validators
find < data-dir > /validators -type f -exec icacls {} /inheritance:r /grant:r $USERDOMAIN\\$USERNAME:\(F\) \;
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
# Set permissions for all the files inside < data-dir > /secrets
find < data-dir > /secrets -type f -exec icacls {} /inheritance:r /grant:r $USERDOMAIN\\$USERNAME:\(F\) \;
```
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
!!! note
Make sure you run the above from inside `Git Bash` , these commands will not work from inside the standard Windows Command Prompt.
If you don't already have a `Git Bash` shell, you'll need to install [Git for Windows ](https://gitforwindows.org/ ).
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
In sum:
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
- Directories `<data-dir>` , `<data-dir>/validators` , `<data-dir>/secrets` **must** be owned by user and have permissions set for the user only (OI)(CI)(F).
All inherited permissions should be removed.
2022-07-21 20:19:47 +02:00
2023-04-11 17:42:35 +02:00
- Files which are stored inside < data-dir > , < data-dir > /validators, < data-dir > /secrets **must** be owned by user and have permissions set for the user only (F).
All inherited permissions should be removed.