If the new server and the old server have the same CPU architecture, copying the files is definitely the fastest.
If they are the same, copy the following directories:
Pay some attention to permissions. The directories and files you copy must maintain their permissions and ownership. This may be a bit tricky, because users and groups may have a different UIDs and GUIDs on the target system.
The above will move the data, but the new netdata will have its own machine guid, so it will be a new netdata for cloud, replication and streaming, etc. If you need to completely replace the old netdata with the new one, you will also have to copy
/var/lib/netdata. But be careful. The old and the new netdata installation should never run at the same time, or strange things will happen. So, if you plan to delete the old netdata installation, copy
/var/lib/netdata too, but make sure the old netdata will never start after you do so.
If the CPU architectures are not the same, then replication is the only way to move forward. There are a few limitations you should know about:
- Both the old and the new netdata should be able to run concurrently.
- Replication only replicates tier 0, the high resolution data. The other tiers are re-generated from tier 0. But this means you can replicate for as long as tier 0 on the old netdata has data.
- Replication replicates only metrics (charts and nodes) that are currently being collected. If you have archived metrics (charts and nodes that are no longer being collected), they will not be replicated. This also means that if the old netdata is a parent for other nodes, these other nodes need to be connected to it (to the old netdata) to trigger replication of their data.
- The default replication period is 1 day (86400 seconds). You will need to change that in
netdata.conf of the new netdata installation to cover as much as you want. It is ok if it is bigger than your tier 0 retention. So, you can set it to a month (2592000 seconds) or even more.
- Replication will need bandwidth between your old and new netdata servers. If they are in separate cloud providers, this may have some indirect cost, due to the amount of traffic these servers will exchange.
Replication is pretty fast, but it will take time and resources, as both the old and the new netdata need to unpack and repack every single metric collected.
If you have really a lot of data, you can also increase the replication threads on the old netdata. This will make it go faster. Generally, every thread is usually able to send about 1-2 million points per second. The more threads you add the faster it will go. But on the receiver side, you will benefit from such increased speed only when there are multiple nodes in your data (the receiver has always 1 thread per node). Do not over-do it with the number of threads. Generally you should not gain more speed by adding more than 10 replication threads on the old netdata.
If you increase the number of threads, you have to know that netdata replication can saturate the link between the old and the new netdata. So, depending on your setup, it may not be good to increase the number of threads too much.
Replication calculates the % of completion on both the sending and the receiving sides. On the sending side, it is located in Netdata Monitoring, workers replication sender (chart
netdata.workers_replication_value_completion). On the receiving side it is located in Netdata Monitoring, workers streaming receive (chart