.png)
Всякий раз, когда несколько пользователей взаимодействуют с установкой Nextcloud, существует вероятность ошибки. Потенциально член семьи может удалить старую фотографию или коллега может случайно отметить задачу или событие в календаре, что приведет к проблемам для других пользователей.
Когда доступны полные снимки файловой системы или резервные копии всего каталога Nextcloud, их можно использовать для восстановления старого состояния всего сервера. Это нормально в случае полного сбоя системы.
Однако это становится проблемой, если проблема замечена только через некоторое время, а за это время пользователи изменили другие данные. Тогда необходимо сделать выбор между спасением старых данных и уничтожением всего прогресса или сохранением текущего состояния.
TheДокументация Nextcloudописывает только способ восстановления всей установки.
Есть ли способ более разумного автоматического резервного копирования всех данных Nextcloud (файлов, сообщений, календарей, задач и т. д.), чтобы их можно было восстановить независимо? (Может быть, даже в режиме онлайн?)
решение1
Восстановление онлайн-состояния действительно потребует полного резервного копирования диска (что, конечно, можно сделать постепенно).
Конечно, вещи, которые на самом деле изменяются посредством взаимодействия с пользователем, это
- база данных (содержащая всю информацию о пользователе, метаданные файлов, разрешения…)
- хранилище данных
- сам nextcloud (так как он может быть обновлен).
Мы можем «решить» проблему 3, просто требуя полного резервного копирования всех трех данных каждый раз при резервном копировании Nextcloud (форматы баз данных могут быть несовместимы с предыдущими версиями).
В типичной контейнерной установке Nextcloud у вас будет два или три контейнера:
- контейнер базы данных «DB», который необходимо запустить первым (обычно это запуск postgresql)
- контейнер, на котором фактически запущен nextcloud "NC", который подключается к базе данных в DB и имеет каталог данных, смонтированный как внешний том "V"
- (обратный прокси-сервер, позволяющий легко скрыть nextcloud за HTTPS и отделить обработку SSL-сертификатов от контейнера nextcloud)
Теперь обычное резервное копирование будет состоять из
- остановка nextcloud или, по крайней мере, заморозка NC, или остановка NC вообще
- создание резервной копии V (что можно сделать легко и постепенно – любая современная утилита резервного копирования справится с этим),
- указание вашей базе данных сделать резервную копию (
pg_backup_start), что запустит резервное копирование в согласованном состоянии (база данных гарантирует, что новые операции не повлияют на состояние, для которого выполняется резервное копирование) - сразу после начала 3-го шага, чтобы восстановить функциональность, перезапустите nextcloud (или разморозьте, или перезапустите NC)
- заставить базу данных записать дамп в файл (
pg_backup_stop); убедитесь, что вы знаете, какая резервная копия данных принадлежит к какой резервной копии базы данных (должно быть ясно по времени и дате)
Как правило, поскольку фактический контейнер nextcloud в любом случае не будет очень большим, поскольку он не содержит ни самих данных, ни базы данных, имеет смысл просто сохранить его вместе с резервными копиями данных и базы данных.
Восстановление можно выполнить на совершенно другой (виртуальной) машине, развернув копию контейнера базы данных, восстановив резервную копию базы данных, в то же время распаковав резервную копию данных, а затем, после запуска базы данных, запустить контейнер nextcloud со смонтированными данными.
На самом деле, поскольку среды выполнения контейнеров (Podman, а также Docker) позволяют вам создавать независимые сети, вы можете иметь столько серверов баз данных, которые работают параллельно, сколько вам нужно; вместе с файловой системой, которую вы используете для тома данных, которая поддерживает моментальные снимки (ZFS, BTRFS и такие вещи, как моментальные снимки LVM + тонкое резервирование XFS, bcachefs…), вы можете исследовать старое состояние параллельно с вашим текущим состоянием, без их вмешательства.
решение2
Календарь, сообщения и т.д.
В теориидамп базы данных должен создавать записи календаря и т. д. с одним или несколькими запросами INSERT.
Вам нужно будет только найти правильные INSERT и попытаться повторно вставить их в текущую базу данных. (Я бы сделал резервную копию текущего состояния, прежде чем пробовать это)
По моему мнению, корзины и версии предлагают пользователям хорошие варианты восстановления данных.
Файлы и мусорная корзина
По умолчанию корзина активирована. Когда пользователь удаляет файл, он отправляется в корзину. Вы можете указать возраст хранения файлов в корзине config/config.phpс помощью записи: trashbin_retention_obligation' => 'auto, 128',(подробности см. в руководстве). Однако, если доступное пространство/квота пользователя опускается ниже 50%, она может быть очищена раньше, или если администрирование запущено occ trashbin:expire;occ trashbin:cleanupвручную. (или по выбору пользователя)
Я не пользуюсь календарем, возможно, удаленные записи календаря также попадают в корзину и могут быть восстановлены — я не знаю.
Файлы и версии
Еще одна вещь — это «версия nextcloud app», которая добавляет возможность восстановить более старую версию файла. Возраст можно задать с помощью 'versions_retention_obligation' => 'auto, 128',. config.phpВключите его в разделе nextcloud apps. Я не использовал это приложение, должно быть как теневые копии.
Восстановление отдельных файлов
Пока вы не используете шифрование и используете только локальные учетные записи, пользовательские данные хранятся в каталоге nextcloud/data/username. Если вы подключены к Active Directory / OpenLDAP, каталог — это nextcloud/data/uuidUUID, который может быть разрешен в базе данных. ( SELECT ldap_dn FROM oc_ldap_user_mapping WHERE owncloud_name='$U_ID')
Файлы можно восстановить вручную из резервной копии пользовательского каталога и скопировать в текущий каталог пользовательских данных. Обязательно просканируйте все файлы с помощью occ files:scanпосле этого.
Если шифрование включено - :) удачи.