# Redis Data Migration: Moving Data with RDB, AOF, replicaof

> Redis data migration between servers: RDB snapshots, the AOF log, and live replicaof replication. Covers commands, data-loss risks, and cluster migration steps.

## When to migrate Redis and which method to choose

Redis gets migrated when you switch hosting providers, upgrade a server, or move from a shared plan to a VDS. The right method depends on whether you can pause the application for a few minutes and how much data the database holds.

There are three working options: an RDB snapshot, an AOF log, and live replication via `replicaof`. For a database under 1 GB, an RDB snapshot works fine. For databases with stricter durability requirements, use AOF. If downtime is not acceptable, migrate through replication.

## Migrating with an RDB snapshot

RDB is a binary dump of the entire database into a single file, `dump.rdb`. This method works if you can pause writes for 1-2 minutes.

On the old server, force a snapshot save and copy the file:

```
redis-cli -h 127.0.0.1 -p 6379 SAVE
scp /var/lib/redis/dump.rdb root@newserver:/var/lib/redis/dump.rdb
```

Redis on the new server must be stopped while the file is being copied, otherwise the process will overwrite it with its own snapshot on the next save. The file path is set by the `dir` and `dbfilename` directives in `redis.conf`.

## Migrating with the AOF log

AOF logs every data-changing command to a file, `appendonly.aof`. Migrating through AOF loses less data than RDB, because the log can be synced to disk every second.

Enable AOF on the old server in advance, wait for a rewrite, and copy the data directory:

```
redis-cli CONFIG SET appendonly yes
redis-cli BGREWRITEAOF
rsync -avz /var/lib/redis/appendonlydir/ root@newserver:/var/lib/redis/appendonlydir/
```

After copying, set `appendonly yes` in `redis.conf` on the new server and start the service — Redis will rebuild its state by replaying the log.

## Live migration with replicaof

The `replicaof` command (called `slaveof` in older versions) turns the new server into a replica of the old one. Data copies automatically, with no application downtime.

```
redis-cli -h newserver -p 6379 REPLICAOF oldserver 6379
redis-cli -h newserver -p 6379 INFO replication
```

Wait for the `master_link_status:up` line and matching `master_repl_offset` values on both sides. Then switch the application to the new address and disable replication with `REPLICAOF NO ONE`.

## Migrating a Redis Cluster

In cluster mode, you cannot simply copy a single `dump.rdb` — data is split across 16384 hash slots between nodes. Add new nodes to the cluster with `redis-cli --cluster add-node`, then redistribute slots with `redis-cli --cluster reshard`.

| Parameter | RDB | AOF | replicaof |
| --- | --- | --- | --- |
| Downtime | 1-2 minutes | 1-2 minutes | near-zero |
| Data loss risk | medium | low | minimal |
| Suitable for a cluster | no | no | yes |

## Verifying data after migration

Compare key counts and control values on both servers:

```
redis-cli -h oldserver DBSIZE
redis-cli -h newserver DBSIZE
redis-cli -h newserver INFO keyspace
```

Check the TTL of expiring keys — when migrating through RDB or AOF, the relative time-to-live of a key is preserved correctly. The full procedure for a final site check is described in the [post-migration checklist](https://www.zevshost.net/en/kb/migratsia-proverka-posle/).

## Summary: Redis migration checklist

- Decide on the acceptable downtime and choose RDB, AOF, or replicaof.
- Record the Redis version — migrating between 6.x and 7.x works fine, but check capabilities in advance.
- Migrate the `redis.conf` file separately instead of relying on default values.
- Compare DBSIZE and key counters on the old and new server.
- Update the connection address in the application and take the old server out of the load only after verification.

If you are also migrating a [MySQL database](https://www.zevshost.net/en/kb/perenesti-bazu-dannykh/) or a document store like [MongoDB](https://www.zevshost.net/en/kb/migratsia-mongodb/) alongside Redis, plan the migration window around the slowest component.

---

Source: https://www.zevshost.net/en/kb/migratsia-redis-dannyh/