Резкое сокращение резервных копий данных привело к сбоям при их восстановлении, из-за чего сайт перестал нормально функционировать. К счастью, в хранилище Amazon S3 удалось найти исторические данные, иначе убытки были бы невосполнимы.
3.3.0.beta2-dev fc76622b56: данных резервной копии меньше, и их нельзя восстановить в обычном режиме
Были ли в этот период какие-либо изменения настроек, которые могли повлиять на то, включались ли загрузки в ваши резервные копии?
Выполнено обновление, применена тема, добавлен кастомный плагин для темы (кастомный CSS). Пользователи могут отключить выбор цветовых схем. Используются файлы data.yml и web_only.yml. После восстановления данных объёмом 262 МБ, текущий размер резервной копии составляет всего 154 МБ. Вероятно, в этих резервных данных уже есть проблемы.
Вы перешли на двухконтейнерную конфигурацию в тот момент или использовали её всегда?
Каковы, вероятно, возможные причины, если так продолжать использовать?
Я попытался восстановить мою последнюю резервную копию пару дней назад, но загрузка на мою панель управления была отклонена. На секунду мне показалось, что резервная копия потеряна, поэтому я попытался загрузить её ещё раз через FTP, и что вы думаете? Восстановление прошло успешно! Но это произошло снова, и я хотел бы узнать причину.
Боюсь, я больше знаком со стандартной установкой и не уверен, есть ли у двухконтейнерной конфигурации какие-либо особенности, которые могут быть здесь важны.
Давайте перенесу этот вопрос в канал #installation и посмотрим, сможем ли мы привлечь более опытных участников. 
(@pfaffman 
)
Ранее использовалась стандартная установка, но у неё есть проблема: при каждом изменении файла app.yml мой сайт становится недоступным. Если же использовать файлы data.yml и web_only.yml, можно вносить изменения в web_only.yml без влияния на доступность сайта. Есть ли аналогичная функция в стандартной установке и как именно её использовать?
Нет. Единственное отличие в том, что при пересборке обновляются только части Rails и Nginx. База данных и Redis остаются без изменений. Они меняются редко, поэтому их не нужно пересобирать. Всё работает точно так же. Вы прекрасно это понимаете. (Единственное усложнение возникает при обновлении PostgreSQL или Redis, что происходит примерно раз в год, хотя были случаи обновлений базы данных из-за требований плагина ИИ. Так что, если вы не использовали плагин ИИ, у вас всё будет в порядке, но если использовали, то без пересборки контейнера с данными вы столкнётесь с запутанными ошибками базы данных.)
Мне кажется, они перенесли файлы на S3, поэтому локальные загрузки не включены. Это согласуется с их утверждением, что они смогли восстановить данные из S3. Или, возможно, они удалили некоторые посты с загрузками, поэтому эти файлы не попали в последующие резервные копии.
Также показалось, что они выполнили восстановление, но не дождались его полного завершения.
Действительно использовался плагин ИИ. На что следует обратить внимание, чтобы резервные данные оставались пригодными для использования? Как нам следует реагировать на подобные проблемы?
Это означает, что проблем нет, пока data.yml не пересобрано, или необходимо использовать app.yml, или такая проблема существует как в схеме data.yml с web_only, так и в схеме app.yml
Проблема в том, что при создании резервной копии версия контейнера, собранного из файла data.yml, не поддерживалась, а база данных была обновлена. Если выполнить обновление через пересборку data.yml, то даже при крупном обновлении базы данных проблем не возникнет, и последующее восстановление резервной копии пройдет без сбоев. Как мне узнать, что в вашей базе данных внесены существенные изменения?
@sober, в качестве заметки о процессе: тем, кто читает или хочет помочь, будет гораздо проще, если вы добавите перевод на английский в свои сообщения. Не могли бы вы отредактировать сообщение и включить перевод? 
Теперь я понимаю, что проблема заключалась в крупном обновлении базы данных, которое вызвало проблемы с резервным копированием.
Что ж, я подожду подтверждения, потому что не знаю, не сломает ли это что-то здесь.
Я хочу обновить только версию beta2, а не beta2-dev, так как боюсь, что dev-версия нестабильна. Недавнее резервное копирование данных не удалось восстановить нормально, что почти привело к потере данных. Я использовал раннюю резервную копию, но данные всё равно были потеряны на некоторое время.
Это не так, это просто недавнее изменение в системе версионирования. Технически, вы даже не должны видеть метки -dev.