Развертывание и настройка Alfresco Community для хранения документов: пошаговое руководство 2026

Alfresco Community Edition - открытая ECM-платформа для хранения документов: содержимое лежит в файловом contentstore, метаданные, версии и права в реляционной базе, полнотекстовый поиск обслуживает Solr. Пользовательский интерфейс - отдельное веб-приложение Alfresco Share, которое разворачивается рядом с репозиторием на том же сервере приложений. Лицензия свободная, поддержка вендора в поставку не входит, релизы выходят реже, чем в коммерческой Alfresco Content Services. Для организации на 50-500 сотрудников возможностей хватает: версионность, права по группам, поиск по содержимому, рабочие процессы, доступ по WebDAV и CMIS, REST API.

Руководство рассчитано на DevOps-инженеров и системных администраторов, которые ставят Alfresco Community на Ubuntu 22.04/24.04 или Debian 12 вместе с PostgreSQL 15, Tomcat 9 и OpenJDK 17. Вы пройдёте полный цикл: подготовка сервера, установка, подключение каталога LDAP или Active Directory, настройка хранилища, резервное копирование, тюнинг под нагрузку и разбор сбоев. Все шаги проверены на чистой виртуальной машине, но продакшен с них не начинается: сначала тестовый стенд, потом перенос конфигурации на боевой узел.

Что такое Alfresco Community и кому подходит это руководство

Какие версии Alfresco Community, Java, PostgreSQL и Tomcat актуальны в 2026

Рабочая связка для Community Edition в 2026 году: Alfresco Community 23.x (23.2 или более свежий минорный релиз), OpenJDK 17 LTS, PostgreSQL 15, Tomcat 9.0.x. Java 11 в новых релизах не поддерживается: код собран под class file version 61+, и на старой JVM Tomcat не распакует alfresco.war. PostgreSQL 13 тоже не лучший выбор, ветка 15 проверена вендором и получает обновления безопасности.

Tomcat берите только девятой ветки. Десятая и одиннадцатая перешли на пространство имён jakarta.*, а Alfresco Community 23.x собран на javax.servlet. Попытка развернуть WAR-файлы в Tomcat 10 заканчивается ошибкой ClassNotFoundException для javax.servlet.ServletContext уже на этапе деплоя. Перед установкой сверьте матрицу совместимости на официальном портале Alfresco, в разделе Supported Platforms: минорные релизы обновляются, и набор патчей для 23.4 отличается от 23.2. Практическое правило: берите последний минорный релиз Community, получивший хотя бы один патч, и не смешивайте компоненты из разных мажорных линеек.

Минимальные требования к серверу и подготовка инфраструктуры

Тестовый стенд: 4 vCPU, 8 ГБ RAM, 100 ГБ диска. Этого хватает, чтобы поднять репозиторий, Share и Solr, загрузить несколько тысяч документов и проверить вход через LDAP. Продакшен для 100 одновременных пользователей начинается с 8 vCPU и 16 ГБ RAM; при contentstore больше 500 ГБ и активной индексации планируйте 32 ГБ RAM и NVMe-диски.

Порядок подготовки на чистой Ubuntu 24.04 или Debian 12:

• обновите систему: sudo apt update && sudo apt full-upgrade -y;
• поставьте Java 17: sudo apt install -y openjdk-17-jdk, затем проверьте java -version (ожидается 17.0.x);
• создайте системного пользователя: sudo adduser --system --home /opt/alfresco --shell /bin/bash alfresco;
• настройте синхронизацию времени через chrony или systemd-timesyncd: расхождение часов больше минуты ломает Kerberos и подпись LDAP-запросов;
• откройте порты 8080 (HTTP) и 8443 (HTTPS) для Share и репозитория, а 8983 оставьте только для localhost, это Solr;
• выставьте лимиты в /etc/security/limits.conf для пользователя alfresco: nofile 65536, nproc 4096.

Для теста PostgreSQL, Tomcat и Solr живут на одной машине. Для продакшена базу выносят на отдельный узел: Alfresco создаёт заметный объём случайного ввода-вывода при загрузке документов и индексации, и соседство с СУБД съедает кэш файловой системы. Если разворачиваете стенд в облаке, берите инстанс с локальными NVMe-дисками и возможностью менять конфигурацию без пересборки, например Timeweb Cloud с готовыми VDS и хранилищем.

Планируете переводить парк на отечественные ОС, тогда изучите заранее пошаговое руководство по миграции на Альт Сервер: аудит совместимости и перенос PostgreSQL там разобраны отдельно, и часть шагов пригодится при смене платформы под Alfresco.

Установка Alfresco Community на Ubuntu/Debian: пошагово

Дальше идёт последовательность, которая приводит к работающему стенду. Шаги можно выполнять по отдельности, но порядок менять не стоит: установщик Alfresco проверяет доступность БД и Java ещё до распаковки.

1. Обновите систему и поставьте зависимости: openjdk-17-jdk, unzip, curl, fontconfig, libice6, libsm6, libxext6, libxrender1, libxt6.
2. Установите PostgreSQL 15 и создайте базу alfresco.
3. Скачайте дистрибутив Alfresco Community (файл alfresco-community-installer-*.bin или zip-архив) с официального сайта Alfresco.
4. Запустите установщик или распакуйте архив вручную в /opt/alfresco.
5. Пропишите подключение к PostgreSQL в alfresco-global.properties.
6. Разместите alfresco.war и share.war в webapps Tomcat 9.
7. Настройте setenv.sh и запустите Tomcat от пользователя alfresco.
8. Проверьте catalina.out и alfresco.log на ошибки старта.

Интерактивный установщик спрашивает путь установки, каталог данных, параметры БД и пароль администратора, а затем раскладывает Tomcat и Solr по /opt/alfresco. При ручном развёртывании структура та же: /opt/alfresco/tomcat - сервер приложений, /opt/alfresco/alf_data - данные, /opt/alfresco/alfresco-search-services - Solr.

Настройка PostgreSQL для Alfresco Community

Создание пользователя и базы под ролью postgres:

sudo -u postgres psql
CREATE USER alfresco WITH PASSWORD 'SlozhnyjParol2026';
CREATE DATABASE alfresco WITH OWNER alfresco ENCODING 'UTF8' LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8' TEMPLATE template0;
GRANT ALL PRIVILEGES ON DATABASE alfresco TO alfresco;
\q

Кодировка UTF8 обязательна: база в другой кодировке даёт ошибки при работе с кириллическими именами файлов. В /etc/postgresql/15/main/pg_hba.conf добавьте строки local all alfresco md5 и host all alfresco 127.0.0.1/32 md5, после чего перечитайте конфигурацию: sudo systemctl reload postgresql. Проверка подключения: psql -h 127.0.0.1 -U alfresco -d alfresco -c "select current_database(), version();"

Параметры подключения в /opt/alfresco/tomcat/shared/classes/alfresco-global.properties:

db.driver=org.postgresql.Driver
db.url=jdbc:postgresql://127.0.0.1:5432/alfresco
db.username=alfresco
db.password=SlozhnyjParol2026

Если Tomcat ставите вручную, положите драйвер postgresql-42.x.jar в /opt/alfresco/tomcat/lib, установщик делает это сам. Пароль без символов # и % избавляет от экранирования в properties-файле.

Установка и настройка Tomcat для Alfresco

Tomcat из репозитория Ubuntu (пакет tomcat9) годится для тестов, но удобнее сервер из дистрибутива Alfresco: его конфигурация уже содержит нужные параметры, а каталог shared/classes указывает на alfresco-global.properties. Ключевые моменты:

• webapps: alfresco.war и share.war копируются в /opt/alfresco/tomcat/webapps, распаковка занимает 3-10 минут;
• владелец: весь /opt/alfresco принадлежит пользователю alfresco, Tomcat запускается от него же, не от root;
• setenv.sh в /opt/alfresco/tomcat/bin: export JAVA_OPTS="-Xms2g -Xmx4g -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -Djava.awt.headless=true -Dalfresco.home=/opt/alfresco";
• server.xml: если порт 8080 занят, меняйте connector port, а вместе с ним проверьте shutdown port 8005 и AJP 8009;
• таймауты: на первом деплое поднимите connectionTimeout до 60000 мс, иначе запросы к утяжелённому контексту отваливаются;
• systemd: юнит с User=alfresco, WorkingDirectory=/opt/alfresco/tomcat, Restart=on-failure, LimitNOFILE=65536.

Проверка запуска: sudo -u alfresco /opt/alfresco/tomcat/bin/startup.sh, затем tail -f /opt/alfresco/tomcat/logs/catalina.out. Старт репозитория занимает 3-6 минут и завершается строкой о запуске контекста /alfresco без исключений.

Настройка аутентификации через LDAP/Active Directory

Alfresco Community умеет проверять пароль напрямую в каталоге и синхронизировать пользователей с группами. Первая часть отвечает за вход, вторая создаёт в репозитории учётные записи и соответствия групп. Обе настраиваются в alfresco-global.properties. Базовая аутентификация:

ldap.authentication.active=true
ldap.authentication.java.naming.provider.url=ldap://ad.example.com:389
ldap.authentication.java.naming.security.authentication=simple
ldap.authentication.java.naming.security.principal=CN=alfresco,OU=Service,DC=example,DC=com
ldap.authentication.java.naming.security.credentials=ParolSluzhby
ldap.authentication.userNameFormat=%s@example.com

Синхронизация включается отдельно:

ldap.synchronization.active=true
ldap.synchronization.java.naming.security.principal=CN=alfresco,OU=Service,DC=example,DC=com
ldap.synchronization.java.naming.security.credentials=ParolSluzhby
ldap.synchronization.userSearchBase=OU=Users,DC=example,DC=com
ldap.synchronization.groupSearchBase=OU=Groups,DC=example,DC=com
ldap.synchronization.queryBatchSize=1000

Для Active Directory добавьте сопоставление атрибутов, иначе в репозитории появятся пустые имена и логины вида CN=:

ldap.synchronization.userIdAttributeName=sAMAccountName
ldap.synchronization.userFirstNameAttributeName=givenName
ldap.synchronization.userLastNameAttributeName=sn
ldap.synchronization.userEmailAttributeName=mail
ldap.synchronization.groupType=GROUP
ldap.synchronization.userSearchFilter=(objectClass=person)

Для OpenLDAP идентификатор обычно uid, а фильтр выглядит как (objectClass=inetOrgPerson). Автосоздание учётных записей при первом входе включает свойство synchronization.autoCreatePeopleOnLogin=true.

LDAPS настраивается сменой URL на ldaps://dc01.example.com:636 и импортом сертификата удостоверяющего центра в truststore JVM: keytool -importcert -keystore /opt/alfresco/tomcat/lib/truststore.jks -alias corp-ca -file corp-ca.crt. Без этого Tomcat отвергает соединение с ошибкой PKIX path building failed. Пароли и DN служебной учётной записи храните в отдельном файле с правами 600 и подключайте через include, чтобы они не попали в бэкап вместе с общим конфигом.

Синхронизация пользователей и групп из LDAP

Синхронизацией управляет планировщик Alfresco: задание ldap-sync запускается по расписанию, стандартный интервал 15 минут, а вручную его удобно вызывать из Share через Администрирование, раздел Directory Management, кнопка Synchronize. Первый прогон на каталоге с 20 000 пользователей идёт 10-40 минут, репозиторий в это время отвечает, но нагрузка на БД заметно растёт. Для крупных каталогов:

• сузьте область поиска до конкретных OU: обход всего домена читает лишние ветки и грузит контроллеры;
• держите queryBatchSize в пределах 500-1000, чтобы контроллер домена не обрывал соединение по лимиту возвращаемых записей;
• проверьте фильтры через ldapsearch до правки конфига: фильтр (objectClass=person) находит людей, а (objectClass=user) в AD захватывает и компьютеры;
• учтите, что вложенные группы AD требуют корректного groupTypeAttributeName, иначе структура синхронизируется плоской, без наследования прав.

Если синхронизация не находит никого, в большинстве случаев виноват фильтр, база поиска или служебная учётная запись без прав чтения нужных OU. Смотрите не результат в Share, а строки LDAP в alfresco.log: там видно число найденных записей и ошибки привязки.

Конфигурация файлового хранилища документов

Контент Alfresco хранит в отдельном дереве каталогов. Точка монтирования задаётся свойством dir.root, по умолчанию /opt/alfresco/alf_data. Внутри лежат contentstore (бинарные объекты), contentstore.deleted (корзина для файлов, удалённых мимо репозитория), а также служебные каталоги: keystore, backups, cached content.

dir.root=/opt/alfresco/alf_data
dir.contentstore=${dir.root}/contentstore
dir.contentstore.deleted=${dir.root}/contentstore.deleted

Три варианта размещения. Локальный диск или отдельный массив: самый быстрый и предсказуемый путь для одного узла и объёма до 1 ТБ. NFS: подходит для отказоустойчивого узла хранения, но требует внимания к блокировкам и совпадению UID. S3-совместимое объектное хранилище: подключается через коннектор (alfresco-s3-connector) и требует проверки совместимости с версией 23.x, а свойства задаются группой content.store.url, content.store.accessKey, content.store.secretKey, content.store.bucketName, content.store.region.

Смена dir.root на работающей системе: остановите Tomcat, перенесите дерево целиком с сохранением атрибутов (rsync -aHAX), обновите свойство, запустите Tomcat и проверьте документ через поиск, а не только открытием по ссылке. Если метаданные и контент разъехались, поиск документ вернёт, а открытие даст ошибку чтения содержимого.

Права доступа и монтирование хранилища

Каталог /opt/alfresco/alf_data принадлежит пользователю alfresco: каталоги 750, файлы 640. Команды: chown -R alfresco:alfresco /opt/alfresco/alf_data, затем chmod -R 750 /opt/alfresco/alf_data и find /opt/alfresco/alf_data -type f -exec chmod 640 {} \;. umask 027 для пользователя alfresco не даёт появляться файлам, доступным посторонним.

SELinux и AppArmor мешают записи чаще, чем кажется. Признак: Tomcat стартует, документ загружается через интерфейс, но в alfresco.log появляется java.io.FileNotFoundException с пометкой Permission denied при формально верных правах на диске. Диагностика: dmesg | grep -i denied и ausearch -m avc -ts recent для SELinux, journalctl -k | grep apparmor для AppArmor. Для SELinux помогает semanage fcontext -a -t httpd_sys_rw_content_t "/opt/alfresco/alf_data(/.*)?" и restorecon -Rv /opt/alfresco/alf_data. Запись в сетевой каталог проверяйте от имени сервисного пользователя: sudo -u alfresco touch /mnt/alfdata/test.

Для локального хранения выбирайте XFS или ext4 с опцией noatime, отдельный раздел под alf_data и ещё один под БД. Для NFS берите версию 4.1 и выше, опции монтирования rw,hard,intr,noatime и убедитесь, что UID пользователя alfresco совпадает с владельцем каталога на сервере хранения. Если идентификаторы различаются, документы сохранятся с чужим владельцем, и после перезапуска Tomcat потеряет доступ к части файлов.

Резервное копирование и восстановление Alfresco Community

В Alfresco два равноправных источника данных: база с метаданными, версиями и правами и contentstore с самими файлами. Порядок восстановления не важен, важна согласованность: дамп БД и дерево alf_data должны относиться к одному моменту времени. Копия только базы даёт список документов без содержимого, копия только alf_data превращается в набор бинарников, которые репозиторий не видит.

Индекс Solr в бэкап класть не обязательно: его пересобирают полной переиндексацией, а на крупных репозиториях он занимает десятки гигабайт. Конфигурацию сохранять нужно: alfresco-global.properties, server.xml, setenv.sh, keystore, каталог shared/classes.

Расписание и глубину хранения фиксируйте в регламенте: для СЭД типичны RPO 1-24 часа и RTO 2-8 часов, а для документов с юридической значимостью берите правило 3-2-1 (три копии, два носителя, одна вне площадки). Как оформить такой документ, задать ротацию и проверить восстановление, разобрано в материале о регламенте резервного копирования и проверке восстановления.

Сценарий холодного резервного копирования

1. Остановите Tomcat: sudo systemctl stop alfresco.
2. Убедитесь, что процессы Java завершились: pgrep -u alfresco java.
3. Снимите дамп базы: sudo -u postgres pg_dump -F c -f /backup/alfresco-$(date +%F).dump alfresco.
4. Скопируйте контент: rsync -aHAX --delete /opt/alfresco/alf_data/ /backup/alf_data/ (данные уже не меняются, поэтому --delete безопасен).
5. Скопируйте конфиги: alfresco-global.properties, tomcat/conf/server.xml, tomcat/bin/setenv.sh, каталог keystore.
6. Запустите Tomcat: sudo systemctl start alfresco.

Такой бэкап даёт простой, зато целостность гарантирована. На репозитории с 200 ГБ контента окно занимает 20-60 минут, значительную часть времени съедает чтение contentstore с диска.

Горячее копирование и порядок восстановления

pg_dump снимается на работающей базе: PostgreSQL отдаёт согласованный снимок транзакций. Проблема в contentstore: файлы, загруженные во время копирования, попадут в дамп БД, но не в архив, а удалённые останутся в архиве. Рабочие варианты: снапшот LVM или ZFS одновременно для тома с базой и тома с alf_data с последующим дампом с клона; pg_dump плюс снапшот contentstore с шагом в несколько секунд и меткой времени в журнале; инкрементальные копии файловой системы (restic, Borg) с той же меткой, что и дамп БД. Встроенного режима quiesce в Community нет, останавливать запись на уровне приложения не получится.

Восстановление после сбоя:

1. Остановите Alfresco: sudo systemctl stop alfresco.
2. Переименуйте текущую базу, не удаляйте: psql -c "ALTER DATABASE alfresco RENAME TO alfresco_broken;", затем создайте новую: CREATE DATABASE alfresco WITH OWNER alfresco ENCODING 'UTF8';
3. Восстановите данные: sudo -u postgres pg_restore -d alfresco --no-owner /backup/alfresco-2026-09-15.dump.
4. Верните контент: rsync -aHAX /backup/alf_data/ /opt/alfresco/alf_data/.
5. Выставьте владельца: chown -R alfresco:alfresco /opt/alfresco/alf_data.
6. Запустите Tomcat и дождитесь сообщения о старте контекста /alfresco.
7. Проверьте alfresco.log и откройте несколько документов, у которых есть история версий.

Главное правило: не смешивайте базу и контент из разных точек восстановления. Если пострадала только БД, а alf_data на месте, восстанавливайте базу, и наоборот. После восстановления запустите полную переиндексацию Solr, иначе поиск будет отдавать часть результатов или ругаться на отсутствующие узлы. Порядок отката и планирование окна обслуживания при смене версии описаны в руководстве по обновлению информационных систем в 2026 году.

Оптимизация производительности Alfresco Community

Тюнинг начинается со снятия метрик, а не с правки конфигов: включите GC-логи JVM, статистику запросов БД через pg_stat_statements, замеры времени ответа Solr и счётчики Tomcat. Без цифр рост heap и shared_buffers даёт удлинение пауз сборки мусора и нулевой прирост скорости.

Ориентир для 100 одновременных пользователей: 8 vCPU, 16 ГБ RAM, из которых 6-8 ГБ отдаётся под heap Tomcat и 2 ГБ под Solr, остальное делится между ОС и PostgreSQL. Индекс поиска и база конкурируют за дисковый ввод-вывод, поэтому NVMe или SSD обязательны, а HDD под alf_data превращает поиск в ожидание.

Настройка JVM и Tomcat

Содержимое /opt/alfresco/tomcat/bin/setenv.sh:

export JAVA_OPTS="-Xms8g -Xmx8g -XX:MaxMetaspaceSize=1g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/alfresco/logs -Djava.awt.headless=true -Dalfresco.home=/opt/alfresco"

• Xms и Xmx держите одинаковыми: репозиторий под нагрузкой быстро занимает heap, и постоянное расширение области даёт лишние сборки мусора;
• heap не должен превышать 50% RAM узла, иначе ядру не останется места под кэш файловой системы и начнётся свопинг;
• MaxMetaspaceSize 512 МБ хватает базовой поставке, с AMP-модулями оставьте 1 ГБ;
• одновременно настройте heap Solr: переменная SOLR_HEAP в скрипте alfresco-search-services, 2 ГБ для репозиториев до миллиона документов;
• в server.xml поднимите maxThreads до 200 и acceptCount до 100, а connectionTimeout держите в районе 20000 мс: короткий таймаут обрывает загрузку больших файлов.

Эффект проверяйте по GC-логам: если после увеличения heap время паузы выросло с 200 мс до 2 секунд, вернитесь к прежним значениям и ищите утечку или тяжёлые запросы.

Тюнинг PostgreSQL для Alfresco

Базовый набор параметров в postgresql.conf для узла с 16 ГБ RAM и отдельным диском под базу:

shared_buffers = 4GB
work_mem = 64MB
maintenance_work_mem = 512MB
effective_cache_size = 12GB
random_page_cost = 1.1
checkpoint_completion_target = 0.9
max_connections = 100
wal_compression = on

• shared_buffers держите в пределах 25% RAM узла, для выделенного сервера базы допустимо 40%;
• random_page_cost = 1.1 задаёт планировщику верную оценку SSD, иначе он избегает индексов и уходит в последовательное чтение;
• max_connections согласуйте с размером пула соединений Alfresco: сотни соединений хватает большинству инсталляций Community, лишние съедают память;
• часть параметров читается только при старте, поэтому после правки нужен перезапуск: sudo systemctl restart postgresql;
• на репозиториях с миллионами записей смотрите в сторону партиционирования таблиц аудита (alf_audit_*) и настройки autovacuum под нагруженные таблицы.

Отдельная строка расходов - загрузка документов. Импорт 100 000 файлов формирует миллионы строк в аудите: растяните его по времени, включите на этот период более агрессивный autovacuum и не запускайте одновременно полную переиндексацию.

Типовые ошибки при развёртывании и способы их устранения

Где смотреть логи и как их читать

Три источника дают почти полную картину:

• /opt/alfresco/tomcat/logs/catalina.out: старт Tomcat, развёртывание WAR, ошибки JVM и подключения к базе. Лог репозитория alfresco.log в сборке установщика лежит рядом, в /opt/alfresco/tomcat/logs/; в ручных сборках его пишут в /opt/alfresco/alf_data/logs/alfresco.log. Ищите ключи ERROR, SEVERE, Connection refused, Authentication failed.
• Логи Solr: /opt/alfresco/alfresco-search-services/logs/solr.log, ключевые слова no servers, CoreAdmin, index.
• PostgreSQL: /var/log/postgresql/postgresql-15-main.log, ключевые слова FATAL, deadlock, could not receive data.

Быстрые команды: grep -iE "ERROR|SEVERE" /opt/alfresco/tomcat/logs/catalina.out | tail -50, grep -i "connection refused" /opt/alfresco/tomcat/logs/alfresco.log, grep -i FATAL /var/log/postgresql/postgresql-15-main.log.

Разбор примера: при старте появляется Unable to connect to database: Connection refused, хотя psql подключается вручную. Причина обычно в том, что db.url указывает на localhost, а PostgreSQL слушает только сокет в /var/run/postgresql. Лечится заменой адреса на 127.0.0.1 и строкой host в pg_hba.conf.

Предупреждения WARN при первом запуске не игнорируйте: часть из них про права, кодировку или устаревшие параметры превращается в отказавшие задачи по расписанию через несколько дней.

Проверка работоспособности и первые шаги в Alfresco

Откройте http://server:8080/share и войдите под admin. Служебный вход и REST API доступны по адресу http://server:8080/alfresco. Первое действие - смена пароля администратора в разделе Администрирование, Пользователи. Второе - страница System Information в Admin Console: там видно версии Java и БД, свободное место в contentstore и состояние подсистем.

Базовый smoke-тест после установки

1. Share открывается, вход под admin проходит.
2. Создайте сайт и папку, загрузите документ размером 10-50 МБ.
3. Проверьте версионность: загрузите вторую версию и сравните историю.
4. Проверьте поиск: найдите документ по фразе из содержимого, а не по имени файла. Так подтверждается, что Solr индексирует контент.
5. Войдите под доменной учётной записью из LDAP и убедитесь, что права пришли из группы.
6. Проверьте подключение по CMIS или WebDAV из файлового менеджера, если планируете интеграции.

Успешный smoke-тест не подтверждает производительность под нагрузкой. Перед массовой загрузкой прогоните 5-10% ожидаемого объёма и посмотрите на время отклика, рост базы и загрузку диска.

Дальше настройте HTTPS: коннектор 8443 в server.xml или обратный прокси с сертификатом. Параллельно включите резервное копирование и мониторинг ключевых метрик: heap JVM, очереди задач, размер contentstore, лаг синхронизации LDAP. Шаблоны для описания таких процедур внутри команды собраны в руководстве по построению базы знаний для IT-специалистов: структура GUIDE и PROCEDURE хорошо ложится на этот сценарий развёртывания.

Завершающий шаг - протестировать восстановление на отдельном стенде. Развёртывание Alfresco Community можно считать законченным не тогда, когда открывается Share, а когда вы возвращаете репозиторий из резервной копии за час, с проверенными документами и сохранённой историей версий.