Любая база данных Odoo со временем становится единственным источником достоверной информации для бизнеса: в ней хранятся счета, складские остатки, исходные данные для расчёта зарплаты, история клиентов и подписанные документы. Её потеря или восстановление неполной копии может остановить работу на несколько дней. И всё же многие компании обнаруживают пробелы в резервном копировании только в тот день, когда оно им понадобилось.
В этой статье разобраны основы управления базами данных, резервного копирования и аварийного восстановления для Odoo 19 Enterprise с пояснениями, чем отличаются установки Community на собственном сервере. Она написана для владельцев бизнеса, финансовых директоров и руководителей ИТ, которым нужна ясная картина без изучения каждой технической страницы.
Об источниках: руководство основано на официальной документации Odoo для версии 19. Платформы размещения и их возможности развиваются, поэтому проверяйте каждый шаг в тестовой базе данных и сверяйте его с актуальной официальной документацией, прежде чем полагаться на него в рабочей среде.
Что содержит полная резервная копия Odoo
База данных Odoo — это не только база данных PostgreSQL. Вложения, такие как загруженные документы, изображения и другое двоичное содержимое, хранятся в виде файлов в так называемом хранилище файлов (filestore), а доступ к ним регулирует Odoo. Резервная копия, содержащая только дамп базы данных, восстановит ваши записи, но вложения будут отсутствовать.
В документации Odoo.sh указано, что резервные копии включают дамп базы данных, хранилище файлов (вложения и двоичные поля), журналы и сеансы. Это полезный ориентир того, как выглядит полная резервная копия при любом типе размещения.
- Дамп базы данных: все записи, конфигурация, пользователи, бухгалтерские проводки и настройки.
- Хранилище файлов: вложения и двоичные поля, например отсканированные счета поставщиков, изображения товаров и подписанные PDF-файлы.
- Собственный код: в Odoo.sh и на собственном сервере ваши собственные модули находятся в репозитории кода, который требует отдельной защиты.
- Конфигурация: на собственном сервере конфигурационный файл Odoo и настройки сервера также нужно документировать и надёжно хранить.
Проверяя резервную копию, всегда убеждайтесь, что в ней есть и дамп, и хранилище файлов. Отсутствие хранилища файлов — одна из самых частых причин, по которым восстановленная база данных поначалу выглядит нормально, а затем показывает битые изображения и отсутствующие документы.
Резервное копирование по типам размещения
Ответственность за резервное копирование зависит от того, где работает ваша база данных. Odoo Online и Odoo.sh размещаются Odoo и включают автоматическое резервное копирование, а при собственном сервере ответственность полностью лежит на вашей команде. Редакцию Community обычно размещают на собственном сервере, поэтому к ней относятся описанные ниже обязанности для собственного сервера.
Odoo Online: менеджер баз данных
Для Odoo Online в официальной документации указано, что резервные копии баз данных создаются ежедневно в соответствии с SLA Odoo Cloud Hosting. Чтобы платформа делала резервные копии, ничего планировать не нужно.
Менеджер баз данных, в который вы входите как администратор базы данных, предлагает пункт «Управление» с основными действиями, необходимыми для резервного копирования и тестирования.
- «Скачать резервную копию» создаёт ZIP-файл базы данных, который можно хранить в собственном архиве.
- Если кнопка «Скачать резервную копию» неактивна, база данных слишком велика для менеджера, и нужно обратиться в службу поддержки Odoo за другим способом скачивания.
- «Дублировать» создаёт копию базы данных; параметр «Для тестирования» включён по умолчанию и отключает внешние действия, такие как письма, платежи и заказы на доставку.
- «Удалить» мгновенно удаляет базу данных для всех пользователей, и это действие нельзя отменить, поэтому сначала скачайте резервную копию.
Согласно документации, копии в Odoo Online удаляются через 15 дней, а у каждой базы данных может быть не более пяти копий. Рассматривайте копии как недолговечные тестовые среды, а не как стратегию резервного копирования.
Odoo.sh: автоматические и ручные резервные копии
В Odoo.sh база данных production автоматически копируется каждый день. В документации указано, что хранятся семь ежедневных, четыре еженедельных и три ежемесячных резервных копии, причём ежемесячные копии находятся на выделенных серверах резервного копирования. Для восстановления или скачивания этих ежемесячных копий нужно обратиться в службу поддержки Odoo.
Ветки staging и разработки автоматически не копируются. Для production и staging можно создавать резервные копии вручную, чтобы зафиксировать конкретное состояние, например перед рискованным изменением конфигурации. Они доступны в течение трёх дней, а в документации упоминается ограничение в пять ручных резервных копий в день. Для баз данных разработки ручные резервные копии создавать нельзя.
Odoo.sh также автоматически создаёт резервную копию с пометкой Update, когда слитый коммит меняет версии модулей или связанные зависимости Python. Если слияние их не меняет, резервная копия не создаётся, поэтому перед значительными изменениями в production делайте резервную копию вручную.
- Используйте вкладку «Резервные копии» ветки production, чтобы просматривать, скачивать или восстанавливать резервные копии.
- Восстанавливайте резервную копию production в ветку staging, когда нужно протестировать изменения на реальных данных.
- С помощью функции «Импорт базы данных» загружайте архивы из стандартного менеджера баз данных, менеджера баз данных Odoo Online, вкладки «Резервные копии» или пункта сборки «Скачать дамп БД».
Собственный сервер: за всё отвечает ваша команда
На собственном сервере ничего не копируется, пока вы это не настроите. Официальное руководство по развёртыванию говорит прямо: настройте ежедневное резервное копирование баз данных и хранилища файлов и копируйте их на удалённый архивный сервер, недоступный с самого сервера Odoo.
То же руководство предупреждает, что веб-менеджер баз данных предназначен для разработки и демонстраций и не рассчитан на рабочее использование. Настоятельно рекомендуется отключать его на любых системах, доступных из интернета, а рабочие операции, такие как автоматическое резервное копирование, должен выполнять системный администратор.
- Защитите экраны управления базами данных надёжным, случайно сгенерированным мастер-паролем, заданным в конфигурационном файле, и никогда не оставляйте значение по умолчанию.
- Отключите вывод списка баз данных на серверах, доступных из интернета, и используйте фильтр баз данных, чтобы каждое имя хоста соответствовало нужной базе данных.
- Запускайте пользователя PostgreSQL для Odoo без прав суперпользователя, как того требует документация по развёртыванию.
- Копируйте базу данных и хранилище файлов вместе, чтобы они оставались согласованными друг с другом.
Перед крупными изменениями, например переходом с Community на Enterprise, официальная документация первым шагом называет резервное копирование базы данных Community. Следуйте той же привычке перед любым обновлением, установкой модуля или импортом данных.
Безопасное дублирование баз данных: нейтрализация
Тестирование на копии production — самый безопасный способ опробовать новые процессы, импорт или обновления, но неосторожно сделанная копия может отправить клиентам реальные письма или провести реальные платежи. Odoo решает эту задачу с помощью нейтрализованных баз данных, которые документация определяет как нерабочие базы данных, в которых отключён ряд параметров.
Тестовые базы данных всегда нейтрализованы, включая резервные копии, дубликаты, а также базы данных staging и разработки в Odoo.sh. Перечень отключаемого в документации прямо назван неполным и включает следующее.
- Запланированные действия, например автоматическое выставление счетов по подпискам и массовые рассылки.
- Исходящую почту, которая в staging Odoo.sh перехватывается перехватчиком почты вместо отправки.
- Синхронизацию с банком, платёжных провайдеров и способы доставки.
- Токены IAP и видимость сайта для поисковых систем.
Красный баннер в верхней части экрана отмечает нейтрализованную базу данных, чтобы пользователи сразу видели, что находятся не в рабочей среде. Научите команду проверять наличие этого баннера, прежде чем что-либо вводить, и никогда не снимайте нейтрализацию с копии, если не понимаете полностью последствий.
Срок хранения, внешние копии, RPO и RTO
Резервные копии платформы — надёжная страховка, но грамотная политика предполагает и независимые копии под вашим контролем. Для размещённых баз данных периодически скачивайте полную резервную копию и храните её в отдельном месте с контролем доступа. Для собственных серверов внешние копии не просто желательны, а обязательны.
Два простых показателя помогают определить необходимый уровень защиты. Целевая точка восстановления (Recovery Point Objective, RPO) — это объём последних данных, потерю которых вы можете себе позволить; ежедневное резервное копирование означает, что можно потерять до одного дня работы. Целевое время восстановления (Recovery Time Objective, RTO) — это время, в течение которого бизнес может работать без системы, пока её восстанавливают.
Согласуйте эти показатели с руководством, а затем проверьте, соответствует ли им ваша текущая настройка. Если потеря заказов на продажу за целый день неприемлема, одного ежедневного резервного копирования недостаточно, и стоит обсудить более частые снимки или другие меры с вашим хостинг-провайдером или ИТ-командой.
Тестирование восстановления и практический контрольный список
Резервная копия подтверждена только тогда, когда её удалось восстановить. Запланируйте регулярные тесты восстановления, восстанавливайте копию в нейтрализованную тестовую среду и проверяйте, что пользователи могут войти, последние записи на месте, а вложения открываются корректно. Замеряйте время процесса, чтобы знать своё реальное RTO.
- Уточните, какой тип размещения вы используете и кто отвечает за резервное копирование.
- Убедитесь, что резервные копии включают и дамп базы данных, и хранилище файлов.
- Храните независимую скачанную копию в отдельном защищённом месте.
- Делайте резервную копию вручную перед обновлениями, крупным импортом или серьёзными изменениями конфигурации.
- Используйте для любого тестирования нейтрализованные копии или ветки staging.
- Регулярно восстанавливайте резервную копию в тестовую среду и фиксируйте результаты.
- Задокументируйте целевые показатели RPO и RTO и пересматривайте их ежегодно.
- На собственном сервере отключите публичный менеджер баз данных и защитите мастер-пароль.
Чем может помочь 1CBMS
1CBMS разрабатывает и проверяет процедуры резервного копирования и восстановления для проектов Odoo 19 в Египте и Ираке — в Odoo Online, Odoo.sh и на собственных серверах. Мы можем провести аудит текущей настройки, определить вместе с вашим руководством реалистичные показатели RPO и RTO, настроить нейтрализованные тестовые среды и провести с вашей командой задокументированный тест восстановления, чтобы восстановление было отрепетированной процедурой, а не авралом.