Экспертиза Redis нужна, когда спор зависит от значения и типа ключей, TTL, вытеснения, снимка памяти RDB или журнала дозаписи AOF, репликации, Sentinel, Redis Cluster, сбоя, производительности либо миграции. Специалист устанавливает версию и режим размещения, топологию, логическую базу или хеш-слоты, правила сохранения на диск и fsync, политику maxmemory, модули, состояние репликации и связь команд с приложением. Это направление экспертизы баз данных и СУБД.
Предварительно можно определить, какие вопросы проверяемы по сохранившимся источникам. Для первого обращения достаточно конфигурации, перечня файлов RDB и AOF, снимков и резервных копий, топологии, журналов и времени события. Если сохранение на диск было отключено, нужный ключ истёк или был вытеснен, AOF переписан, а аудит приложения отсутствует, прежнее значение может быть невозможно установить по сохранившимся источникам. Такая оценка помогает до полной работы сохранить оставшиеся файлы и уточнить достижимый результат.
Если система ваша или вы действуете с согласия её владельца, первым делом выясните, сохраняется ли база на диск. Это показывает INFO persistence, а при доступной команде настроек — CONFIG GET save и CONFIG GET appendonly. Если файлы RDB и AOF на диске уже есть, сначала скопируйте их: новый снимок перезапишет прежний dump.rdb, а он и есть состояние до происшествия.
Отдельно о том, что будет, если ответить не удастся. Задачу, по которой уже из присланных материалов видно, что вывода не получится, мы просто не берём в работу и говорим об этом сразу. Это не обещание положительного вывода: отказ на входе означает лишь, что невозможность видна уже из перечня материалов. Если же невозможность выясняется по итогам полноценного исследования, это результат, а не пустой счёт: заключение объясняет, почему ответа нет и чего именно не хватило. В споре такой вывод часто закрывает вопрос: обоснованный ответ, что спорного интервала нет ни в снимке памяти, ни в журнале дозаписи, показывает суду границы имеющихся источников. Назначать ли после этого дополнительную или повторную экспертизу, решает назначивший её орган. Бывает и частичная невозможность: тогда указывают, на какие вопросы ответ получен, а на какие нет и по какой причине.
Кто снимает копию, решают по объекту. Иногда это делает сам заказчик или его администратор по согласованному плану; иногда — наш специалист, удалённо или с выездом, как отдельная консультация; иногда фиксация входит в саму экспертизу. Выбор зависит от сложности системы, доступности и трудоёмкости: файлы RDB и AOF снимают по-разному на одиночном сервере и на нагруженном кластере. Если инфраструктурой управляет другая сторона, порядок доступа определяет суд, и фиксацию проводят с участием эксперта.
Если сохранение отключено, данные существуют только в памяти, и снимок нужен — иначе любой перезапуск уничтожит объект целиком. Но перед командой проверьте, переживёт ли её сервер: фоновое сохранение порождает копию процесса и на нагруженной базе способно занять вдвое больше памяти, а при нехватке — привести к аварийному завершению. Посмотрите свободную память узла, свободное место под каталогом сохранения и значение stop-writes-on-bgsave-error: при неудачном сохранении сервер по умолчанию перестаёт принимать запись. Если запаса нет, снимок делают с реплики, а не с основного узла. Если спорная система принадлежит другой стороне, не запускайте ничего: фиксацию проводят по определению суда с участием эксперта.
До копирования не перезапускайте единственный экземпляр, не запускайте BGREWRITEAOF, переключение ролей, перераспределение слотов, FLUSHDB/FLUSHALL и исправление AOF: redis-check-aof --fix отбрасывает не «хвост», а всё от повреждённого места до конца файла. Сохраните RDB и весь многофайловый каталог AOF с манифестом, конфигурацию и журнал сервера, зафиксируйте роли, смещения репликации, состояние кластера, время и часовой пояс. Перезапись AOF Redis запускает сам, когда файл заметно вырастает, и копия, снятая во время перезаписи, окажется непригодной. Поэтому перед копированием каталога перезапись подавляют штатным способом: обнуляют порог автоматической перезаписи, убеждаются по INFO persistence, что перезапись не идёт, копируют файлы и возвращают прежнее значение. Обе команды изменения настроек записывают в протокол. Выполняет это владелец системы или уполномоченный им администратор; если система принадлежит другой стороне, доказательство сохраняют через суд.
Не выполняйте диагностические команды, меняющие сроки хранения или счётчики, без протокола. Если для согласованного снимка используют CLIENT PAUSE ... WRITE, помните, что это остановка записи в боевой системе: задавайте конечный таймаут, чтобы пауза снялась сама, и согласуйте окно с владельцем — Redis обычно стоит в горячем пути приложения, и пауза в десятки секунд вызывает лавину таймаутов у клиентов. В управляемых сервисах доступа к живым файлам на узле нет, а часть команд недоступна. Зато у ряда провайдеров резервную копию можно выгрузить наружу обычным файлом RDB — это и есть предпочтительный объект, потому что его можно хэшировать, передать и разобрать автономно, в отличие от точки восстановления внутри сервиса. Фиксируют идентификатор задания выгрузки, время, регион и контрольную сумму. Что именно доступно, зависит от продукта и тарифа; недоступность части источников эксперт указывает как ограничение вывода.
Что является объектом исследования Redis
Redis хранит рабочий набор данных преимущественно в памяти, а сохранение на диск может использовать RDB, AOF, их сочетание или быть полностью отключено. Одиночный сервер, основной узел (primary) с репликами, Sentinel и Redis Cluster имеют разную топологию. Управляемые сервисы Redis и Redis Software добавляют собственные резервные копии, аудит и источники панели управления; конкретный продукт и версия должны быть установлены.
В зависимости от задачи исследование может охватывать:
- имена ключей, логические базы или слоты кластера, типы и значения данных, TTL и кодировку;
- снимки RDB и их метаданные, манифест AOF, базовые и добавочные файлы;
- настройки сохранения на диск, точки сохранения,
appendfsync, перезапись AOF и результаты последнего сохранения; maxmemory, политику вытеснения, счётчики истёкших и вытесненных ключей, уведомления пространства ключей;- идентификаторы и смещения репликации, буфер истории, роли, состояние Sentinel, узлы и слоты Cluster, эпохи конфигурации;
- пользователей и правила ACL, ACL LOG, SLOWLOG, монитор задержек, журналы сервера и сохранённые результаты INFO и MONITOR;
- модули, журналы приложения, очереди, сеансы и бизнес-смысл ключей.
Один dump.rdb описывает набор данных на момент снимка, а не обязательно момент инцидента. Текущий работающий экземпляр уже изменяется из-за клиентов, истечения TTL и фоновой работы. Поэтому каждое состояние привязывают к способу и времени получения.
Что может и чего не может установить эксперт
При достаточных материалах можно определить состав ключей и значения в RDB/AOF либо в документированном срезе работающего экземпляра, параметры TTL, последовательность сохранившихся команд записи, настройки сохранения на диск и вытеснения, состояние репликации и причины отказа. Срез называют согласованным только при подтверждённом способе фиксации единого момента; результаты нескольких источников сопоставляют по общей временной шкале.
При достаточных материалах эксперт может установить:
- какие ключи, типы, значения и сроки действия содержатся в конкретном RDB или воспроизводимом AOF;
- какие команды записи сохранились в AOF после последнего базового файла и перезаписи;
- допускают ли политика сохранения и зафиксированный сбой потерю определённого интервала записей;
- имеются ли признаки истечения TTL, нехватки памяти, вытеснения, FLUSH или удаления приложением;
- как менялись роли, смещения репликации, переключения и принадлежность слотов;
- что отражают ACL LOG, SLOWLOG, монитор задержек, журналы сервера и приложения;
- полностью ли перенесены ключи, значения, типы и TTL.
Redis по умолчанию не хранит вечную историю всех команд и пользователей. SLOWLOG включает только медленные с точки зрения выполнения команды, имеет ограниченный размер и исключает сетевой ввод-вывод. ACL LOG ориентирован на нарушения аутентификации и авторизации, а не на все успешные действия. MONITOR показывает поток с момента запуска и влияет на производительность. IP, имя клиента или пользователь ACL не обязательно идентифицируют физическое лицо.
Материалы для исследования
Файлы собирают до перезапуска и перезаписи AOF. Для каждого объекта фиксируют исходный узел и путь, средство получения и его версию, дату, время и часовой пояс, размер и SHA-256 завершённой мастер-копии. Мастер-копию сохраняют неизменной, исследование ведут на рабочей копии; после каждой передачи повторно проверяют SHA-256 и записывают отправителя, получателя, время и носитель. В Redis 7 и новее AOF может состоять из манифеста, базовых и добавочных файлов в одном каталоге; выборочное копирование одного файла неполно.
В комплект обычно включают:
- все снимки и резервные копии RDB, метаданные их создания;
- полный каталог AOF, манифест, базовые и добавочные файлы, а также старые копии до перезаписи;
redis.conf, параметры командной строки, подключаемые файлы, файл ACL и конфигурацию модулей;- сохранённые разделы INFO: server, persistence, stats, memory, replication, commandstats, keyspace и cluster;
- ROLE, идентификаторы и смещения репликации, буфер истории, конфигурацию и состояние Sentinel, CLUSTER NODES/SLOTS и события переключения;
- журналы сервера, ACL LOG, SLOWLOG, данные задержек, журналы подписчика на уведомления ключей и внешнего мониторинга;
- журналы приложения, прокси, IdP, оркестратора и сети, версию клиентской библиотеки и правила повторных попыток;
- правила именования и шаблоны ключей, сериализацию, план миграции, SLA и спорный период.
Команды на работающей системе могут менять счётчики, косвенные служебные структуры, журналы или нагрузку. Полный KEYS * на крупном рабочем экземпляре способен блокировать обслуживание; стратегию сбора выбирают с учётом риска и документируют. Последовательные SCAN, DUMP или чтения ключей не дают изоляции снимка: при одновременных записях ключи и значения могут появляться, исчезать или меняться между шагами, поэтому такой результат нельзя называть состоянием на единый момент.
Согласованный срез получают выбранным и заранее описанным способом: краткой документированной приостановкой записей, штатным снимком управляемого сервиса либо контролируемым созданием RDB после сохранения уже существующих RDB/AOF. Для совместимых версий одним из вариантов служит CLIENT PAUSE ... WRITE на всех основных узлах с последующим CLIENT UNPAUSE. Для паузы указывают средство и версию, подтверждают её на всех узлах, учитывают поведение истечения срока ключей и вытеснения именно в этой версии и фиксируют общий подтверждённый интервал. BGSAVE создаёт новое производное состояние данных и меняет служебное состояние, поэтому фиксируют команду, время, журнал и влияние. Для Redis Cluster охватывают все основные узлы и все хеш-слоты. Если записи не остановлены, для каждого узла фиксируют начало и конец выгрузки, топологию, смещения репликации и параллельные изменения и формулируют интервальный, а не точечный вывод. Исходные RDB, AOF и выгрузку оперативного состояния хранят раздельно, каждый объект получает собственный SHA-256.
Передача копии, в которой есть сведения о людях или охраняемая законом тайна, требует законного основания. По назначенной экспертизе объекты поступают от назначившего органа; вне процесса — от обладателя сведений и в объёме, необходимом для ответа на поставленные вопросы. Обезличивание при этом обсуждают не как уступку, а как способ передать меньше, чем есть. Эксперт не разглашает сведения, ставшие известными ему в связи с исследованием, а рабочие копии удаляет по окончании работы.
RDB и AOF: разные источники и границы исследования
RDB — компактный снимок набора данных на определённый момент, создаваемый по правилам сохранения или команде. Между снимками изменения на диск в RDB не попадают; при аварии возможна потеря интервала после последней успешной копии. Файл можно исследовать отдельно, но его время проверяют по внутренним метаданным, журналу и процессу резервного копирования, а не только по времени файловой системы.
AOF записывает команды изменения данных для последующего воспроизведения. Устойчивость зависит от appendfsync: always, everysec и no дают разные окна риска. При перезапуске и одновременном RDB+AOF Redis использует AOF как более полный источник. Повреждённый или оборванный хвост исследуют до redis-check-aof --fix, поскольку исправление отбрасывает часть файла.
Перезапись AOF создаёт минимизированное представление текущего набора данных вместо сохранения всех прежних команд. После неё факт и последовательность давно выполненных операций могут исчезнуть, хотя конечное значение сохранится. Поэтому AOF полезен для истории только в пределах фактически уцелевших базовых и добавочных файлов и не является неизменяемым аудитом.
Загрузка старого RDB или воспроизведение AOF в текущем времени способны немедленно удалить ключи, абсолютный срок действия которых уже истёк. Поэтому сначала выполняют автономный разбор, фиксируют сохранённые абсолютные моменты истечения и только затем при необходимости запускают рабочую копию в изолированной среде с документированным контрольным временем.
TTL, истечение срока и вытеснение
Ключ может исчезнуть из-за явных DEL/UNLINK, истечения TTL, вытеснения по maxmemory, FLUSH, перезаписи, загрузки нового набора данных, переключения ролей либо логики модуля. Истечение обрабатывается пассивно при доступе и активно фоновой выборкой, поэтому физический момент удаления может отличаться от расчётного момента TTL.
Различить эти причины по одному AOF нельзя: истечение срока и вытеснение сервер записывает в журнал такой же командой удаления, как и обычное удаление приложением. Само по себе наличие в AOF записи об удалении ключа не говорит о том, что ключ удалил человек или программа. Разделяют эти случаи только сопоставлением с настройками сроков и памяти, с журналом сервера и с поведением приложения — и если таких источников нет, ответ остаётся вероятным.
Отдельно учитывают, что записи AOF по умолчанию не содержат времени: параметр aof-timestamp-enabled появился в Redis 7.0 и по умолчанию выключен, а имени клиента или пользователя в журнале нет вовсе. Поэтому время события по AOF определяют не из самого файла, а через сопоставление с журналом сервера, метриками, снимками RDB и внешними источниками.
Вытеснение зависит от maxmemory и политики, например LRU, LFU или случайного выбора для всех либо только ключей с TTL. Счётчики INFO показывают агрегаты после запуска, но не называют каждый ключ. Уведомления пространства ключей помогают только если были включены и подписчик сохранил события; сами уведомления не являются сохраняемым журналом. Причину устанавливают по конфигурации, AOF, журналам, метрикам и приложению, а при недостатке данных оставляют альтернативы.
Репликация, Sentinel и Cluster
Репликация Redis по умолчанию асинхронна. Основной узел передаёт поток команд, а реплика отслеживает идентификатор и смещение репликации; буфер истории позволяет частичную повторную синхронизацию. При переключении роли признанная приложением запись могла не успеть попасть на реплику, назначенную основным узлом. WAIT повышает вероятность доставки на заданное число реплик, но не превращает Redis в строго согласованное хранилище и не заменяет сохранение на диск.
Sentinel наблюдает экземпляры и координирует переключение ролей. Исследуют кворум, эпохи, выбор ведущего, выбранную реплику и переконфигурацию. Redis Cluster распределяет пространство ключей по хеш-слотам; проверяют идентификаторы узлов, эпохи конфигурации, перемещения слотов, состояния миграции и импорта, переключения и служебную сеть кластера. Реплика и соседний узел не являются независимой резервной копией: пустой или ошибочно изменённый основной узел может распространить состояние.
Диагностика, аудит и производительность
Журнал сервера и INFO описывают запуск, сохранение на диск, репликацию, память и счётчики. SLOWLOG хранит ограниченный список команд, чьё время выполнения сервером превысило порог, без сетевого времени. Монитор задержек фиксирует выбранные события с ограниченной историей и обычно выключен по умолчанию. ACL LOG сообщает об отказах аутентификации, авторизации и некоторых событиях безопасности.
MONITOR передаёт выполняемые команды только с момента подключения и создаёт существенную нагрузку, поэтому его нельзя бездумно включать в рабочей среде. Для причины задержки сопоставляют commandstats, SLOWLOG, крупные ключи, фрагментацию памяти, создание дочернего процесса, fsync и перезапись RDB/AOF, вытеснение, CPU, ввод-вывод, сеть и пулы приложения. Текущий снимок не доказывает прошлое состояние без сохранённого мониторинга. Замедления и отказы сами по себе исследует экспертиза производительности и сбоев СУБД.
Как проверить миграцию Redis
Сопоставляют не только количество ключей, но и логические базы или слоты, имена и двоичное представление ключей, типы и значения данных, TTL с допустимым уменьшением, потоки и группы потребителей, оценки упорядоченных множеств, порядок списков, содержимое множеств и хешей, HyperLogLog, битовые карты, геоданные и значения модулей.
Фиксируют версии источника и приёмника, снимок и момент переключения, схему репликации или двойной записи, сериализатор, отклонённые ключи, повторные попытки и записи после переключения. Отдельно проверяют ACL, сценарии и функции, модули, публикацию/подписку и поведение клиента: сообщения Pub/Sub не входят в набор данных RDB/AOF. MIGRATE, репликация и восстановление по-разному обрабатывают TTL и замену существующего ключа; эти различия включают в критерии. Когда предметом спора становится сам перенос, а не устройство базы, задачу закрывает экспертиза миграции баз данных.
Примеры вопросов на экспертизу
При судебной экспертизе окончательный круг вопросов определяет суд, а в иных предусмотренных законом процедурах — орган или лицо, назначившие экспертизу. Вопросы о виновности, умысле, правовой квалификации события, нарушении договора и ответственности разрешает суд или иной уполномоченный орган. Эксперт отвечает на поставленные вопросы в пределах специальных знаний и представленных материалов; о неясности вопроса, выходе за пределы компетенции или недостаточности материалов он в установленном порядке сообщает суду, органу или лицу, назначившим экспертизу.
До назначения стороны могут использовать приведённые ниже формулировки как предложения о технических вопросах. Для Redis полезно указать экземпляр или кластер, логическую базу или слоты, ключ или шаблон, период, часовой пояс и технический критерий. Например, можно предложить исследовать, отражают ли AOF и журналы удаление ключа X и с какими техническими идентификаторами связана команда, либо какое состояние ключей по шаблону P воспроизводится из RDB Z и полного каталога AOF. Дополнительные примеры:
- Какие ключи, типы, значения и TTL содержатся в представленном RDB?
- Какие команды изменения данных и состояния воспроизводятся из представленного AOF?
- Каковы границы времени RDB и какой интервал изменений мог быть утрачен при сбое?
- Какова последовательность команд в представленном AOF и с какими внешними источниками её можно соотнести по времени?
- Имеются ли признаки DEL, FLUSH, истечения TTL или вытеснения применительно к указанным ключам?
- Как менялись роли, идентификаторы и смещения репликации при переключении?
- Соответствовали ли настройки сохранения данных установленным требованиям к надёжности?
- Какие события безопасности отражены в ACL LOG и журналах сервера?
- Какие факторы вызвали зафиксированный скачок задержки?
- Корректно ли распределены хеш-слоты и отсутствуют ли подтверждаемые потери при их перераспределении?
- Полностью ли перенесены ключи, значения, типы, TTL и служебное состояние?
Результат и стоимость
Исследование включает раздельную фиксацию исходных RDB, AOF и состояния работающей системы, проверку SHA-256, разбор RDB/AOF на рабочей копии, восстановление изолированного экземпляра, анализ топологии, журналов и контекста приложения. Результатом может быть консультация, внесудебное исследование, судебная экспертиза или рецензия. Ориентир по стоимости — от 100 000 ₽, срок — от 10 рабочих дней; влияют объём, топология, режим сохранения на диск, модули, повреждение и вопросы.
Если судебная экспертиза уже назначена, назначенный по делу эксперт не принимает от одной стороны напрямую дополнительные файлы RDB, AOF и журналы и не даёт ей частную оценку по существу поручения: вопросы, доступ и новые материалы идут через назначившего субъекта. Это не исключает обращения стороны к другому, не назначенному по делу специалисту — за консультацией или рецензией по законно полученным материалам. Предшествующую содержательную работу специалиста для одной стороны раскрывают при рассмотрении его кандидатуры; допустимость назначения и возможный отвод решает уполномоченный субъект с учётом мнения участников. Чтобы снизить риски, роли консультанта стороны и кандидата в судебные эксперты целесообразно разделять. Готовое чужое заключение проверяет рецензия на заключение экспертизы баз данных и СУБД.
Проведение экспертизы по уголовному делу
Судебная экспертиза по уголовному делу производится государственными судебными экспертами и иными экспертами из числа лиц, обладающих специальными знаниями.
Негосударственными судебно-экспертными учреждениями постановление Пленума Верховного Суда Российской Федерации от 21 декабря 2010 г. № 28 «О судебной экспертизе по уголовным делам» признаёт некоммерческие организации, созданные в соответствии с Гражданским кодексом Российской Федерации и Федеральным законом «О некоммерческих организациях» и осуществляющие судебно-экспертную деятельность в соответствии с принятыми ими уставами.
По сведениям организации, проведение судебных экспертиз предусмотрено её уставом (см. действующую редакцию в разделе «Документы организации»). Это само по себе не означает автоматического поручения любой экспертизы. Возможность поручить конкретное исследование определяет назначающий орган с учётом предмета дела, квалификации эксперта, оснований для отвода и действующего перечня экспертиз, выполняемых только государственными судебно-экспертными организациями.
