Redis Cluster: Node Backup & Restore

[benlaplanche]

Backups currently happen on a per node basis, so care has to be taken to ensure they do not all run BGSAVE/SAVE at the same time for performance.

Scripting also has to be in place to manually extract the RDB files and copy them away somewhere.

You also need to backup the nodes.conf file to have a chance of doing a restore.

It would be great if this was able to be triggered in a central manner.

Restore is also tricky in that it requires knowledge of the cluster topology. It sounds like you have to recreate the cluster exactly as it was to be able to restore (read drop in) the RDB files you backed up previously.

[antirez]

This is planned. The idea is to have, more or less, redis-trib able to do the following:

1. Get the N RDB files from the master.
2. Create a nodes representation in a text file that is part of the backup.
3. Ability to restore it into a new cluster, like part of create but --from-backup.

Basically the backup will be a directory, not a file.

Would be great to have it now, but no time, but, this does not need to wait for v2. We'll get it in the course of Redis 3.0.x.

[benlaplanche]

Sounds good and the prioritization for a later release makes sense.

@tsaleh

[antirez]

Fortunately for this specific feature we don't need to wait for the next release, since it is in the tools space, so there will be no need to touch Redis Cluster itself to start to provide support for backups. Given that's an operational big concern hopefully this will be addressed in the course of 3.0.x by back porting the feature from 3.2.0, however currently no exact scheduling.

[chester89]

what about AOF files? will this proposal consider them too?

[karthimohan]

@antirez Just wondering if Redis Cluster Backup feature is available now or do you have any approximate time frame on when this will be ready for Production use?

[vuliad]

I wonder if this feature will be released in the near future?

[reneklacan]

@antirez ping

[darklrd]

+1

[otherpirate]

+1

[cyberelfo]

+1

[s-aravind-flipkart]

+1

[vuliad]

+1

[rivieiraa]

+1

[tungdam]

+1

[StefansArya]

I think we can easily dump & zip all the cluster data to do a backup, and put the data back then restart the cluster to restore it. We will need a script to automate it..

[vuliad]

I think we can easily dump & zip all the cluster data to do a backup, and put the data back then restart the cluster to restore it. We will need a script to automate it..

Such backup without downtime will be inconsistent.

[StefansArya]

Just backup from the slave, not the master

[vuliad]

Just backup from the slave, not the master

It's about sharding and point-in-time snapshots across multiple nodes.