Как зарезервировать Docker-контейнер Redis (2026)
Хотите копию Redis, которая действительно восстановится? Снимите дамп командой `redis-cli SAVE # then capture the resulting dump.rdb` изнутри контейнера вместо копирования /data. SAVE/BGSAVE форкает point-in-time RDB-снимок на диск: вы резервируете готовый dump.rdb (плюс AOF, если включён), а не летучее состояние в памяти. Затем Dockstash передаёт дамп restic для зашифрованных, дедуплицированных внешних снимков.
Что находит Dockstash
| Найденные переменные окружения | REDIS_PASSWORD, REDIS_ARGS |
|---|---|
| Порт по умолчанию | 6379 |
| Живые пути данных (никогда не копируются вживую) | /data, /data/dump.rdb, /data/appendonly.aof |
| Примеры образов | redis:7-alpine, redis:7, redis:6, redis |
Резервируем Redis с Dockstash, шаг за шагом
Создайте аккаунт Dockstash и откройте панель
Зарегистрируйтесь бесплатно на app.dockstash.com/register. Одноразовый мастер настройки спросит ваш VPS для хранения (машину, где будут лежать зашифрованные резервные копии) и сгенерирует пароль шифрования — сразу сохраните его в менеджере паролей: он показывается ровно один раз.
Добавьте Docker-проект, в котором работает Redis
На экране Projects Dockstash автоматически находит каждую папку Compose-проекта на сервере (по умолчанию под /var/www). Выберите проект с вашим сервисом Redis. Пока ничего не резервируется — вы лишь указываете Dockstash, где живёт проект.
Проверьте, что Redis распознан
Откройте проект и вкладку Plan. Dockstash читает docker-compose.yml, распознаёт образ redis и добавляет слой базы с правильной стратегией «сохранить и захватить» — плюс имя контейнера и найденные переменные (REDIS_PASSWORD, REDIS_ARGS). Файлы, базы и конфиги прокси можно переключать перед сохранением.
Опционально: проверьте снимок вручную
Если хотите доказательство до автоматизации, запустите то же сохранение, что и Dockstash: redis-cli BGSAVE в контейнере. Redis отвечает «Background saving started», форкается и пишет point-in-time dump.rdb в /data. Именно этот завершённый RDB-файл — а не живое состояние в памяти — и резервируется.
docker exec <redis-container> redis-cli BGSAVEПодтвердите место хранения
Резервные копии хранятся как зашифрованные снимки restic на вашем собственном VPS для хранения, по SSH. Если вы прошли мастер настройки, всё уже настроено; хост, пользователя, порт или SSH-ключ можно изменить в любой момент в Settings → Storage.
Настройте расписание резервного копирования
Во вкладке Schedule выберите ежедневно, еженедельно или собственный cron (валидируется при вводе). Для Redis как основного хранилища (очереди, сессии) ежедневно — разумный минимум, ежечасно — обычная практика. Добавьте еженедельный prune с политикой хранения.
Запустите первую копию сейчас
Нажмите Backup Now. Dockstash запустит фоновое сохранение, дождётся готового dump.rdb и зарезервирует его — вместе с appendonly.aof, если включена AOF-персистентность — прямо в restic. Живой вывод смотрите в панели логов.
Убедитесь, что снимок существует
По завершении запуска карточка проекта показывает новое время последней копии, число снимков и размер репозитория. Откройте экран Snapshots: точка восстановления появится на таймлайне — это ваше доказательство, что копия дошла до внешнего хранилища.
Команда дампа
redis-cli SAVE # then capture the resulting dump.rdbКоманда восстановления
place dump.rdb in the data dir and start redis-serverSAVE/BGSAVE форкает point-in-time RDB-снимок на диск: вы резервируете готовый dump.rdb (плюс AOF, если включён), а не летучее состояние в памяти.
Восстановите копию Redis и докажите, что она работает
Резервная копия Redis становится настоящей только после восстановления. Восстановления Dockstash по умолчанию не перезаписывают живой инстанс — сначала в новое место, проверка данных, затем осознанное продвижение.
Выберите точку восстановления
Откройте Snapshots, выберите проект и просмотрите таймлайн. Каждая строка содержит полный point-in-time dump.rdb (плюс AOF, если включён) и файлы проекта того же запуска.
Восстановите в новое место
Нажмите Restore и оставьте режим по умолчанию «Restore to new location». Введите имя проекта для подтверждения — осознанное действие с набором текста. Дамп и файлы попадут в выбранный целевой путь, не трогая живой проект.
Проверьте восстановленные данные
Положите восстановленный dump.rdb в каталог данных тестового контейнера Redis и запустите его — Redis загружает RDB при старте. Выполните redis-cli PING: должен прийти PONG; затем выборочно проверьте ключи приложения через DBSIZE и несколько GET.
docker exec <redis-container> redis-cli PINGПродвигайте, когда всё проверено
Когда восстановленные данные проверены, переключите на них приложение (или повторите восстановление в режиме «Overwrite existing» — явный опт-ин). Ещё лучше: пусть еженедельная тренировка восстановления делает это доказательство автоматически, чтобы восстановление никогда не было вашей первой репетицией.
Каких ловушек избегать
- Копирование dump.rdb во время перезаписи даёт усечённый файл; сначала запустите SAVE (или BGSAVE), потом резервируйте готовый RDB.
- Если включена AOF-персистентность, резервируйте и файлы appendonly.aof — RDB в одиночку может отставать от последних записей.
- Восстановление Redis требует остановленного или перезапущенного сервера для загрузки RDB; горячая подмена dump.rdb в работающем инстансе невозможна.
Типичные проблемы резервирования Redis
- Симптом
- Восстановленный dump.rdb не загружается: «Short read or OOM loading DB» или ошибка усечённого файла.
- Причина
- RDB скопировали, пока Redis его ещё переписывал — захват посреди перезаписи даёт частичный файл.
- Решение
- Всегда запускайте SAVE или BGSAVE и дожидайтесь конца, прежде чем захватывать dump.rdb. Dockstash делает именно так: запускает сохранение, ждёт завершения, резервирует готовый файл.
- Симптом
- Восстановление успешно, но свежайшие записи отсутствуют.
- Причина
- Включена AOF-персистентность, и appendonly.aof содержал записи новее RDB-снимка — RDB в одиночку отстаёт.
- Решение
- Резервируйте оба файла. Dockstash захватывает /data/dump.rdb и appendonly.aof вместе в одном запуске.
- Симптом
- Вы положили восстановленный dump.rdb в /data, но работающий Redis всё ещё отдаёт старые данные.
- Причина
- Redis читает RDB только при старте — горячая подмена невозможна. А при включённом appendonly Redis грузит AOF при старте и полностью игнорирует RDB.
- Решение
- Остановите контейнер, положите восстановленный dump.rdb (и AOF, если восстановили) в каталог данных, затем запустите снова. Если восстановили только RDB в AOF-конфигурацию — временно поставьте appendonly no на первый старт, потом верните.
- Симптом
- BGSAVE падает с «Can't save in background: fork: Cannot allocate memory».
- Причина
- Форк, нужный фоновому сохранению, отклонён эвристиками overcommit памяти ядра — на хосте с большим набором данных Redis.
- Решение
- Установите vm.overcommit_memory=1 на Docker-хосте (sysctl) — настройка, которую сам Redis рекомендует при старте. Форк использует copy-on-write и не требует полной второй копии данных.
Сделайте это в один клик с Dockstash
Dockstash выполняет ровно тот дамп, что выше, передаёт его restic вовне и автоматически проверяет восстановление тренировкой — без скриптов на поддержке.
Последнее обновление: July 2026
Часто задаваемые вопросы
Стоит ли вообще резервировать Redis?
Зависит от использования. Чистый кэш восстановится сам. Основное хранилище (очереди, сессии, sorted sets) — да: резервируйте RDB, и AOF, если включён.
SAVE или BGSAVE — что использует Dockstash?
BGSAVE форкается и снимает в фоне без блокировки; SAVE блокирует до конца. Dockstash предпочитает фоновое сохранение и резервирует готовый dump.rdb.
А что с AOF (append-only file)?
Если appendonly включён, AOF содержит свежайшие записи, которых RDB может ещё не отражать. Dockstash захватывает /data/dump.rdb и appendonly.aof, чтобы свежие данные не терялись.
Можно ли копировать dump.rdb при работающем Redis?
Только после завершённого SAVE/BGSAVE. Копирование во время перезаписи может схватить частичный файл. Dockstash запускает сохранение и ждёт завершения.
Как часто резервировать Redis?
Подстройте расписание под содержимое. Для очередей и сессий обычен ежечасный график; для медленных данных хватает ежедневного. На Free копии вручную (Backup Now); Pro — до ежечасных, Business — любой cron.
Где на самом деле живут резервные копии?
На вашем собственном VPS для хранения, как зашифрованные снимки restic, отправляемые по SSH. Dockstash никогда не держит ваши данные в чужом облаке — вы указываете машину под вашим контролем, а репозиторий зашифрован паролем, который есть только у вас.
Как узнать, что копия Redis действительно восстанавливается?
Запланируйте тренировку восстановления. Dockstash восстановит последний снимок в изолированную область, сверит каждый файл по байтам и проверит захваченный дамп — затем поставит значок «прошло/провалено». Еженедельная тренировка — всегда свежее доказательство.