{ "schema_version": 2, "id": "operate/oss_and_stack/management/persistence", "title": "Redis persistence", "url": "https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/", "summary": "How Redis writes data to disk", "aliases": [ "/management/persistence/", "/manual/persistence/" ], "tags": [ "docs", "operate", "stack", "oss" ], "last_updated": "2026-09-30T13:16:11-07:00", "page_type": "content", "content_hash": "91b7955d45c6f9c9355b6938bfb7452918513c15170ad407db1b65e21cf58e3d", "sections": [ { "id": "overview", "title": "Overview", "role": "overview", "text": "Persistence refers to the writing of data to durable storage, such as a solid-state disk (SSD). Redis provides a range of persistence options. These include:\n\n* **RDB** (Redis Database): RDB persistence performs point-in-time snapshots of your dataset at specified intervals.\n* **AOF** (Append Only File): AOF persistence logs every write operation received by the server. These operations can then be replayed again at server startup, reconstructing the original dataset. Commands are logged using the same format as the Redis protocol itself.\n* **No persistence**: You can disable persistence completely. This is sometimes used when caching.\n* **RDB + AOF**: You can also combine both AOF and RDB in the same instance.\n\nIf you'd rather not think about the tradeoffs between these different persistence strategies, you may want to consider [Redis Software's persistence options](https://redis.io/docs/latest/operate/rs/databases/configure/database-persistence), which can be pre-configured using a UI.\n\nTo learn more about how to evaluate your Redis persistence strategy, read on." }, { "id": "rdb-advantages", "title": "RDB advantages", "role": "content", "text": "* RDB is a very compact single-file point-in-time representation of your Redis data. RDB files are perfect for backups. For instance you may want to archive your RDB files every hour for the latest 24 hours, and to save an RDB snapshot every day for 30 days. This allows you to easily restore different versions of the data set in case of disasters.\n* RDB is very good for disaster recovery, being a single compact file that can be transferred to far data centers, or onto Amazon S3 (possibly encrypted).\n* RDB maximizes Redis performances since the only work the Redis parent process needs to do in order to persist is forking a child that will do all the rest. The parent process will never perform disk I/O or alike.\n* RDB allows faster restarts with big datasets compared to AOF.\n* On replicas, RDB supports [partial resynchronizations after restarts and failovers](https://redis.io/docs/latest/operate/oss_and_stack/management/replication#partial-resynchronizations-after-restarts-and-failovers)." }, { "id": "rdb-disadvantages", "title": "RDB disadvantages", "role": "content", "text": "* RDB is NOT good if you need to minimize the chance of data loss in case Redis stops working (for example after a power outage). You can configure different *save points* where an RDB is produced (for instance after at least five minutes and 100 writes against the data set, you can have multiple save points). However you'll usually create an RDB snapshot every five minutes or more, so in case of Redis stopping working without a correct shutdown for any reason you should be prepared to lose the latest minutes of data.\n* RDB needs to fork() often in order to persist on disk using a child process. fork() can be time consuming if the dataset is big, and may result in Redis stopping serving clients for some milliseconds or even for one second if the dataset is very big and the CPU performance is not great. AOF also needs to fork() but less frequently and you can tune how often you want to rewrite your logs without any trade-off on durability." }, { "id": "aof-advantages", "title": "AOF advantages", "role": "content", "text": "* Using AOF Redis is much more durable: you can have different fsync policies: no fsync at all, fsync every second, fsync at every query. With the default policy of fsync every second, write performance is still great. fsync is performed using a background thread and the main thread will try hard to perform writes when no fsync is in progress, so you can only lose one second worth of writes.\n* The AOF log is an append-only log, so there are no seeks, nor corruption problems if there is a power outage. Even if the log ends with a half-written command for some reason (disk full or other reasons) the redis-check-aof tool is able to fix it easily.\n* Redis is able to automatically rewrite the AOF in background when it gets too big. The rewrite is completely safe as while Redis continues appending to the old file, a completely new one is produced with the minimal set of operations needed to create the current data set, and once this second file is ready Redis switches the two and starts appending to the new one.\n* AOF contains a log of all the operations one after the other in an easy to understand and parse format. You can even easily export an AOF file. For instance even if you've accidentally flushed everything using the [`FLUSHALL`](https://redis.io/docs/latest/commands/flushall) command, as long as no rewrite of the log was performed in the meantime, you can still save your data set just by stopping the server, removing the latest command, and restarting Redis again." }, { "id": "aof-disadvantages", "title": "AOF disadvantages", "role": "content", "text": "* AOF files are usually bigger than the equivalent RDB files for the same dataset.\n* AOF can be slower than RDB depending on the exact fsync policy. In general with fsync set to *every second* performance is still very high, and with fsync disabled it should be exactly as fast as RDB even under high load. Still RDB is able to provide more guarantees about the maximum latency even in the case of a huge write load.\n\n**Redis < 7.0**\n\n* AOF can use a lot of memory if there are writes to the database during a rewrite (these are buffered in memory and written to the new AOF at the end).\n* All write commands that arrive during rewrite are written to disk twice.\n* Redis could freeze writing and fsyncing these write commands to the new AOF file at the end of the rewrite.\n \nOk, so what should I use?\n---\n\nThe general indication you should use both persistence methods is if\nyou want a degree of data safety comparable to what PostgreSQL can provide you.\n\nIf you care a lot about your data, but still can live with a few minutes of\ndata loss in case of disasters, you can simply use RDB alone.\n\nThere are many users using AOF alone, but we discourage it since to have an\nRDB snapshot from time to time is a great idea for doing database backups,\nfor faster restarts, and in the event of bugs in the AOF engine.\n\nThe following sections will illustrate a few more details about the two persistence models." }, { "id": "snapshotting", "title": "Snapshotting", "role": "content", "text": "By default Redis saves snapshots of the dataset on disk, in a binary\nfile called `dump.rdb`. You can configure Redis to have it save the\ndataset every N seconds if there are at least M changes in the dataset,\nor you can manually call the [`SAVE`](https://redis.io/docs/latest/commands/save) or [`BGSAVE`](https://redis.io/docs/latest/commands/bgsave) commands.\n\nFor example, this configuration will make Redis automatically dump the\ndataset to disk every 60 seconds if at least 1000 keys changed:\n\n save 60 1000\n\nThis strategy is known as _snapshotting_." }, { "id": "how-it-works", "title": "How it works", "role": "content", "text": "Whenever Redis needs to dump the dataset to disk, this is what happens:\n\n* Redis [forks](http://linux.die.net/man/2/fork). We now have a child\nand a parent process.\n\n* The child starts to write the dataset to a temporary RDB file.\n\n* When the child is done writing the new RDB file, it replaces the old\none.\n\nThis method allows Redis to benefit from copy-on-write semantics." }, { "id": "append-only-file", "title": "Append-only file", "role": "content", "text": "Snapshotting is not very durable. If your computer running Redis stops,\nyour power line fails, or you accidentally `kill -9` your instance, the\nlatest data written to Redis will be lost. While this may not be a big\ndeal for some applications, there are use cases for full durability, and\nin these cases Redis snapshotting alone is not a viable option.\n\nThe _append-only file_ is an alternative, fully-durable strategy for\nRedis. It became available in version 1.1.\n\nYou can turn on the AOF in your configuration file:\n\n appendonly yes\n\nFrom now on, every time Redis receives a command that changes the\ndataset (e.g. [`SET`](https://redis.io/docs/latest/commands/set)) it will append it to the AOF. When you restart\nRedis it will re-play the AOF to rebuild the state.\n\nSince Redis 7.0.0, Redis uses a multi part AOF mechanism.\nThat is, the original single AOF file is split into base file (at most one) and incremental files (there may be more than one).\nThe base file represents an initial (RDB or AOF format) snapshot of the data present when the AOF is [rewritten](#log-rewriting).\nThe incremental files contains incremental changes since the last base AOF file was created. All these files are put in a separate directory and are tracked by a manifest file." }, { "id": "log-rewriting", "title": "Log rewriting", "role": "content", "text": "The AOF gets bigger and bigger as write operations are\nperformed. For example, if you are incrementing a counter 100 times,\nyou'll end up with a single key in your dataset containing the final\nvalue, but 100 entries in your AOF. 99 of those entries are not needed\nto rebuild the current state.\n\nThe rewrite is completely safe.\nWhile Redis continues appending to the old file,\na completely new one is produced with the minimal set of operations needed to create the current data set,\nand once this second file is ready Redis switches the two and starts appending to the new one.\n\nSo Redis supports an interesting feature: it is able to rebuild the AOF\nin the background without interrupting service to clients. Whenever\nyou issue a [`BGREWRITEAOF`](https://redis.io/docs/latest/commands/bgrewriteaof), Redis will write the shortest sequence of\ncommands needed to rebuild the current dataset in memory. If you're\nusing the AOF with Redis 2.2 you'll need to run [`BGREWRITEAOF`](https://redis.io/docs/latest/commands/bgrewriteaof) from time to\ntime. Since Redis 2.4 is able to trigger log rewriting automatically (see the\nexample configuration file for more information).\n\nSince Redis 7.0.0, when an AOF rewrite is scheduled, the Redis parent process opens a new incremental AOF file to continue writing.\nThe child process executes the rewrite logic and generates a new base AOF.\nRedis will use a temporary manifest file to track the newly generated base file and incremental file.\nWhen they are ready, Redis will perform an atomic replacement operation to make this temporary manifest file take effect.\nIn order to avoid the problem of creating many incremental files in case of repeated failures and retries of an AOF rewrite,\nRedis introduces an AOF rewrite limiting mechanism to ensure that failed AOF rewrites are retried at a slower and slower rate." }, { "id": "how-durable-is-the-append-only-file", "title": "How durable is the append only file?", "role": "content", "text": "You can configure how many times Redis will\n[`fsync`](http://linux.die.net/man/2/fsync) data on disk. There are\nthree options:\n\n* `appendfsync always`: `fsync` every time new commands are appended to the AOF. Very very slow, very safe. Note that the commands are appended to the AOF after a batch of commands from multiple clients or a pipeline are executed, so it means a single write and a single fsync (before sending the replies).\n* `appendfsync everysec`: `fsync` every second. Fast enough (since version 2.4 likely to be as fast as snapshotting), and you may lose 1 second of data if there is a disaster.\n* `appendfsync no`: Never `fsync`, just put your data in the hands of the Operating System. The faster and less safe method. Normally Linux will flush data every 30 seconds with this configuration, but it's up to the kernel's exact tuning.\n\nThe suggested (and default) policy is to `fsync` every second. It is\nboth fast and relatively safe. The `always` policy is very slow in\npractice, but it supports group commit, so if there are multiple parallel\nwrites Redis will try to perform a single `fsync` operation." }, { "id": "what-should-i-do-if-my-aof-gets-truncated", "title": "What should I do if my AOF gets truncated?", "role": "content", "text": "It is possible the server crashed while writing the AOF file, or the\nvolume where the AOF file is stored was full at the time of writing. When this happens the\nAOF still contains consistent data representing a given point-in-time version\nof the dataset (that may be old up to one second with the default AOF fsync\npolicy), but the last command in the AOF could be truncated.\nThe latest major versions of Redis will be able to load the AOF anyway, just\ndiscarding the last non well formed command in the file. In this case the\nserver will emit a log like the following:\n\n[code example]\n\nYou can change the default configuration to force Redis to stop in such\ncases if you want, but the default configuration is to continue regardless of\nthe fact the last command in the file is not well-formed, in order to guarantee\navailability after a restart.\n\nOlder versions of Redis may not recover, and may require the following steps:\n\n* Make a backup copy of your AOF file.\n* Fix the original file using the `redis-check-aof` tool that ships with Redis:\n\n $ redis-check-aof --fix \n\n* Optionally use `diff -u` to check what is the difference between two files.\n* Restart the server with the fixed file." }, { "id": "what-should-i-do-if-my-aof-gets-corrupted", "title": "What should I do if my AOF gets corrupted?", "role": "content", "text": "If the AOF file is not just truncated, but corrupted with invalid byte\nsequences in the middle, things are more complex. Redis will complain\nat startup and will abort:\n\n[code example]\n\nThe best thing to do is to run the `redis-check-aof` utility, initially without\nthe `--fix` option, then understand the problem, jump to the given\noffset in the file, and see if it is possible to manually repair the file:\nThe AOF uses the same format of the Redis protocol and is quite simple to fix\nmanually. Otherwise it is possible to let the utility fix the file for us, but\nin that case all the AOF portion from the invalid part to the end of the\nfile may be discarded, leading to a massive amount of data loss if the\ncorruption happened to be in the initial part of the file." }, { "id": "how-it-works-1", "title": "How it works", "role": "content", "text": "Log rewriting uses the same copy-on-write trick already in use for\nsnapshotting. This is how it works:\n\n**Redis >= 7.0**\n\n* Redis [forks](http://linux.die.net/man/2/fork), so now we have a child\nand a parent process.\n\n* The child starts writing the new base AOF in a temporary file.\n\n* The parent opens a new increments AOF file to continue writing updates.\n If the rewriting fails, the old base and increment files (if there are any) plus this newly opened increment file represent the complete updated dataset,\n so we are safe.\n \n* When the child is done rewriting the base file, the parent gets a signal,\nand uses the newly opened increment file and child generated base file to build a temp manifest,\nand persist it.\n\n* Profit! Now Redis does an atomic exchange of the manifest files so that the result of this AOF rewrite takes effect. Redis also cleans up the old base file and any unused increment files.\n\n**Redis < 7.0**\n\n* Redis [forks](http://linux.die.net/man/2/fork), so now we have a child\nand a parent process.\n\n* The child starts writing the new AOF in a temporary file.\n\n* The parent accumulates all the new changes in an in-memory buffer (but\nat the same time it writes the new changes in the old append-only file,\nso if the rewriting fails, we are safe).\n\n* When the child is done rewriting the file, the parent gets a signal,\nand appends the in-memory buffer at the end of the file generated by the\nchild.\n\n* Now Redis atomically renames the new file into the old one,\nand starts appending new data into the new file." }, { "id": "how-i-can-switch-to-aof-if-im-currently-using-dumprdb-snapshots", "title": "How I can switch to AOF, if I'm currently using dump.rdb snapshots?", "role": "content", "text": "If you want to enable AOF in a server that is currently using RDB snapshots, you need to convert the data by enabling AOF via CONFIG command on the live server first.\n\n**IMPORTANT:** not following this procedure (e.g. just changing the config and restarting the server) can result in data loss!\n\n**Redis >= 2.2**\n\nPreparations:\n\n* Make a backup of your latest dump.rdb file.\n* Transfer this backup to a safe place.\n\nSwitch to AOF on live database:\n\n* Enable AOF: `redis-cli config set appendonly yes`\n* Optionally disable RDB: `redis-cli config set save \"\"`\n* Make sure writes are appended to the append only file correctly.\n* **IMPORTANT:** Update your `redis.conf` (potentially through [`CONFIG REWRITE`](https://redis.io/docs/latest/commands/config-rewrite)) and ensure that it matches the configuration above.\n If you forget this step, when you restart the server, the configuration changes will be lost and the server will start again with the old configuration, resulting in a loss of your data.\n\nNext time you restart the server:\n\n* Before restarting the server, wait for AOF rewrite to finish persisting the data.\n You can do that by watching `INFO persistence`, waiting for `aof_rewrite_in_progress` and `aof_rewrite_scheduled` to be `0`, and validating that `aof_last_bgrewrite_status` is `ok`.\n* After restarting the server, check that your database contains the same number of keys it contained previously.\n\n**Redis 2.0**\n\n* Make a backup of your latest dump.rdb file.\n* Transfer this backup into a safe place.\n* Stop all the writes against the database!\n* Issue a `redis-cli BGREWRITEAOF`. This will create the append only file.\n* Stop the server when Redis finished generating the AOF dump.\n* Edit redis.conf end enable append only file persistence.\n* Restart the server.\n* Make sure that your database contains the same number of keys it contained before the switch.\n* Make sure that writes are appended to the append only file correctly." }, { "id": "interactions-between-aof-and-rdb-persistence", "title": "Interactions between AOF and RDB persistence", "role": "content", "text": "Redis >= 2.4 makes sure to avoid triggering an AOF rewrite when an RDB\nsnapshotting operation is already in progress, or allowing a [`BGSAVE`](https://redis.io/docs/latest/commands/bgsave) while the\nAOF rewrite is in progress. This prevents two Redis background processes\nfrom doing heavy disk I/O at the same time.\n\nWhen snapshotting is in progress and the user explicitly requests a log\nrewrite operation using [`BGREWRITEAOF`](https://redis.io/docs/latest/commands/bgrewriteaof) the server will reply with an OK\nstatus code telling the user the operation is scheduled, and the rewrite\nwill start once the snapshotting is completed.\n\nIn the case both AOF and RDB persistence are enabled and Redis restarts the\nAOF file will be used to reconstruct the original dataset since it is\nguaranteed to be the most complete." }, { "id": "backing-up-redis-data", "title": "Backing up Redis data", "role": "content", "text": "Before starting this section, make sure to read the following sentence: **Make Sure to Backup Your Database**. Disks break, instances in the cloud disappear, and so forth: no backups means huge risk of data disappearing into /dev/null.\n\nRedis is very data backup friendly since you can copy RDB files while the\ndatabase is running: the RDB is never modified once produced, and while it\ngets produced it uses a temporary name and is renamed into its final destination\natomically using rename(2) only when the new snapshot is complete.\n\nThis means that copying the RDB file is completely safe while the server is\nrunning. This is what we suggest:\n\n* Create a cron job in your server creating hourly snapshots of the RDB file in one directory, and daily snapshots in a different directory.\n* Every time the cron script runs, make sure to call the `find` command to make sure too old snapshots are deleted: for instance you can take hourly snapshots for the latest 48 hours, and daily snapshots for one or two months. Make sure to name the snapshots with date and time information.\n* At least one time every day make sure to transfer an RDB snapshot *outside your data center* or at least *outside the physical machine* running your Redis instance." }, { "id": "backing-up-aof-persistence", "title": "Backing up AOF persistence", "role": "content", "text": "If you run a Redis instance with only AOF persistence enabled, you can still perform backups.\nSince Redis 7.0.0, AOF files are split into multiple files which reside in a single directory determined by the `appenddirname` configuration.\nDuring normal operation all you need to do is copy/tar the files in this directory to achieve a backup. However, if this is done during a [rewrite](#log-rewriting), you might end up with an invalid backup.\nTo work around this you must disable AOF rewrites during the backup:\n\n1. Turn off automatic rewrites with
\n [`CONFIG SET`](https://redis.io/docs/latest/commands/config-set) `auto-aof-rewrite-percentage 0`
\n Make sure you don't manually start a rewrite (using [`BGREWRITEAOF`](https://redis.io/docs/latest/commands/bgrewriteaof)) during this time.\n2. Check there's no current rewrite in progress using
\n [`INFO`](https://redis.io/docs/latest/commands/info) `persistence`
\n and verifying `aof_rewrite_in_progress` is 0. If it's 1, then you'll need to wait for the rewrite to complete.\n3. Now you can safely copy the files in the `appenddirname` directory.\n4. Re-enable rewrites when done:
\n [`CONFIG SET`](https://redis.io/docs/latest/commands/config-set) `auto-aof-rewrite-percentage `\n\n**Note:** If you want to minimize the time AOF rewrites are disabled you may create hard links to the files in `appenddirname` (in step 3 above) and then re-enable rewrites (step 4) after the hard links are created.\nNow you can copy/tar the hardlinks and delete them when done. This works because Redis guarantees that it\nonly appends to files in this directory, or completely replaces them if necessary, so the content should be\nconsistent at any given point in time.\n\n\n**Note:** If you want to handle the case of the server being restarted during the backup and make sure no rewrite will automatically start after the restart you can change step 1 above to also persist the updated configuration via [`CONFIG REWRITE`](https://redis.io/docs/latest/commands/config-rewrite).\nJust make sure to re-enable automatic rewrites when done (step 4) and persist it with another [`CONFIG REWRITE`](https://redis.io/docs/latest/commands/config-rewrite).\n\nPrior to version 7.0.0 backing up the AOF file can be done simply by copying the aof file (like backing up the RDB snapshot). The file may lack the final part\nbut Redis will still be able to load it (see the previous sections about [truncated AOF files](#what-should-i-do-if-my-aof-gets-truncated))." }, { "id": "online-backups-with-the-backup-command-family", "title": "Online backups with the BACKUP command family", "role": "content", "text": "Since Redis 8.10.0, the [`BACKUP`](https://redis.io/docs/latest/commands/backup) command family produces a self-contained, restorable backup without stopping writes or manually managing AOF rewrites. A backup reuses the [multi-part AOF](#append-only-file) format, so it is an MP-AOF–compatible artifact set consisting of three files:\n\n* **BASE** — a point-in-time snapshot (`appendonly.aof.N.base.rdb`).\n* **INCR** — the incremental writes appended after the snapshot (`appendonly.aof.N.incr.aof`).\n* **Manifest** — a standalone manifest describing the file set (`appendonly.aof.manifest`).\n\nBecause backup creation is separated from backup finalization, a control plane can stagger [`BACKUP START`](https://redis.io/docs/latest/commands/backup-start) across the nodes of a cluster so that they do not all `fork` at the same time. Each node produces its BASE independently, keeps appending to its INCR, and is later frozen with [`BACKUP SEAL`](https://redis.io/docs/latest/commands/backup-seal). A restore loads `BASE + INCR`, so the restored dataset reflects the state at the seal boundary, not merely the earlier BASE snapshot.\n\nThe typical workflow on a node is:\n\n1. [`BACKUP START`](https://redis.io/docs/latest/commands/backup-start) — open a backup window and produce a fresh BASE snapshot. This works whether or not AOF persistence is enabled.\n2. [`BACKUP LIST`](https://redis.io/docs/latest/commands/backup-list) — get the absolute paths of the immutable files pinned so far. The data plane can begin copying the BASE file while Redis keeps accumulating INCR data.\n3. [`BACKUP SEAL`](https://redis.io/docs/latest/commands/backup-seal) — freeze the backup, hard-linking the INCR and writing the manifest. After sealing, `BACKUP LIST` also includes the INCR and manifest files.\n4. Copy the sealed files reported by `BACKUP LIST` to your backup storage.\n5. [`BACKUP CLEANUP`](https://redis.io/docs/latest/commands/backup-cleanup) — remove the sealed files and release the pinned artifacts after the copy is complete.\n\nUse [`BACKUP STATUS`](https://redis.io/docs/latest/commands/backup-status) at any point to inspect the current backup state, and [`BACKUP ABORT`](https://redis.io/docs/latest/commands/backup-abort) to cancel a backup that has not been sealed yet.\n\nThe backup files are written to the directory named by the `backupdirname` configuration setting (default `backupdir`), resolved under the Redis working directory `dir`. `backupdirname` is a startup-only setting. The `backup-sealed-ttl` setting controls how long, in seconds, Redis keeps a sealed backup before cleaning it up automatically; a value of `0` (the default) disables automatic cleanup so the files remain pinned until `BACKUP CLEANUP` is called.\n\n#### Restoring a backup\n\nTo restore a backup, use the startup-only `preload-file` configuration setting, which loads a specific file or manifest during server startup. It is specified as `:`, where `` is either `aof` or `rdb`. To restore a sealed backup, point it at the manifest:\n\n[code example]\n\nYou can also preload a single RDB file:\n\n[code example]\n\nWhen `preload-file` is set, Redis loads only the specified file or manifest and its associated files. It skips the normal `appenddirname` and `dump.rdb` loading, even if AOF or RDB persistence is enabled. If the preload target is missing or cannot be loaded, startup aborts. After the preload finishes, Redis continues with its normally configured persistence mode." }, { "id": "disaster-recovery", "title": "Disaster recovery", "role": "content", "text": "Disaster recovery in the context of Redis is basically the same story as\nbackups, plus the ability to transfer those backups in many different external\ndata centers. This way data is secured even in the case of some catastrophic\nevent affecting the main data center where Redis is running and producing its\nsnapshots.\n\nWe'll review the most interesting disaster recovery techniques\nthat don't have too high costs.\n\n* Amazon S3 and other similar services are a good way for implementing your disaster recovery system. Simply transfer your daily or hourly RDB snapshot to S3 in an encrypted form. You can encrypt your data using `gpg -c` (in symmetric encryption mode). Make sure to store your password in many different safe places (for instance give a copy to the most important people of your organization). It is recommended to use multiple storage services for improved data safety.\n* Transfer your snapshots using SCP (part of SSH) to far servers. This is a fairly simple and safe route: get a small VPS in a place that is very far from you, install ssh there, and generate a ssh client key without passphrase, then add it in the `authorized_keys` file of your small VPS. You are ready to transfer backups in an automated fashion. Get at least two VPS in two different providers\nfor best results.\n\nIt is important to understand that this system can easily fail if not\nimplemented in the right way. At least, make absolutely sure that after the\ntransfer is completed you are able to verify the file size (that should match\nthe one of the file you copied) and possibly the SHA1 digest, if you are using\na VPS.\n\nYou also need some kind of independent alert system if the transfer of fresh\nbackups is not working for some reason." } ], "examples": [ { "id": "what-should-i-do-if-my-aof-gets-truncated-ex0", "language": "plaintext", "code": "* Reading RDB preamble from AOF file...\n* Reading the remaining AOF tail...\n# !!! Warning: short read while loading the AOF file !!!\n# !!! Truncating the AOF at offset 439 !!!\n# AOF loaded anyway because aof-load-truncated is enabled", "section_id": "what-should-i-do-if-my-aof-gets-truncated" }, { "id": "what-should-i-do-if-my-aof-gets-corrupted-ex0", "language": "plaintext", "code": "* Reading the remaining AOF tail...\n# Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix ", "section_id": "what-should-i-do-if-my-aof-gets-corrupted" }, { "id": "online-backups-with-the-backup-command-family-ex0", "language": "conf", "code": "preload-file aof:/tmp/restore-backup/appendonly.aof.manifest", "section_id": "online-backups-with-the-backup-command-family" }, { "id": "online-backups-with-the-backup-command-family-ex1", "language": "conf", "code": "preload-file rdb:/tmp/backup-to-recover.rdb", "section_id": "online-backups-with-the-backup-command-family" } ] }