Бэкап и восстановление Piwigo

MAATRIX

Галерея на Piwigo растёт незаметно: сначала пара альбомов с отпуска, потом архив за десять лет, тысячи фотографий, к которым привыкли обращаться как к готовому каталогу. Проблема в том, что бэкапят обычно сам сервер целиком «на всякий случай», а по факту у Piwigo три разных по природе актива — файлы фотографий, база данных и файл конфигурации с секретным ключом — и если из этой тройки потерять хоть один элемент, восстановление превращается в ребус. Ниже — рабочая схема бэкапа и восстановления, которую можно повторить руками за 15 минут и автоматизировать за час.

Что нужно бэкапить в Piwigo и почему

У Piwigo нет единого «файла проекта» — состояние галереи размазано по трём местам, и каждое ведёт себя по-своему при потере.

Практический вывод: кэш производных можно и нужно исключать из бэкапа — это экономит гигабайты и минуты каждой резервной копии, а восстановится он сам при первом открытии галереи (первая загрузка после восстановления будет чуть медленнее, пока Piwigo не пересоздаст миниатюры). А вот local/config.php бэкапить обязательно отдельно от остального кода — именно там креды к БД и секретный ключ, без которого после восстановления посыплются битые ссылки на превью и разлогинит всех пользователей.

Проверьте, где именно у вас лежит кэш, командой:

grep -R "derivative" /var/www/piwigo/local/config.php 2>/dev/null
ls -la /var/www/piwigo/_data 2>/dev/null

Если каталога _data нет — значит, ваша версия хранит превью прямо в альбомах, и тогда из архива с upload/ стоит исключать только служебные подпапки превью, а не всю директорию.

Ручной бэкап: mysqldump + tar

Сначала посмотрите реальные параметры подключения к базе — они в local/config.php:

grep -E "db_base|db_user|db_password|db_host" /var/www/piwigo/local/config.php

Дамп базы. Если таблицы движка InnoDB — снимайте дамп с --single-transaction, чтобы не блокировать сайт на время бэкапа; если остались таблицы MyISAM (частое наследие старых установок Piwigo) — потребуется кратковременная блокировка на чтение:

mysqldump -u piwigo_user -p \
  --single-transaction --routines --triggers \
  piwigo_db | gzip > /var/backups/piwigo/db_$(date +%F).sql.gz

Если не уверены, какой движок используют таблицы:

mysql -u piwigo_user -p -e "SELECT table_name, engine FROM information_schema.tables WHERE table_schema='piwigo_db';"

Архив файлов — фотографии, конфиг, кастомные плагины и темы, но без пересоздаваемого кэша:

tar -czf /var/backups/piwigo/files_$(date +%F).tar.gz \
  --exclude='_data' \
  --exclude='upload/*/thumb' \
  --exclude='upload/*/pwg_representative' \
  -C /var/www piwigo

Обязательно копируйте local/config.php вторым, независимым файлом — так проще при восстановлении сверить креды, не разворачивая весь архив:

cp /var/www/piwigo/local/config.php /var/backups/piwigo/config_$(date +%F).php

Скрипт автоматического бэкапа и cron

Ручной прогон полезен один раз, чтобы понять объём и время выполнения, но дальше это должно уйти в cron. Вот рабочий скрипт с ротацией старых копий:

#!/bin/bash
# /usr/local/bin/piwigo-backup.sh
set -euo pipefail

PIWIGO_DIR="/var/www/piwigo"
BACKUP_DIR="/var/backups/piwigo"
DATE=$(date +%F_%H%M)
RETENTION_DAYS=14

DB_USER=$(grep -oP "db_user'\s*,\s*'\K[^']+" "$PIWIGO_DIR/local/config.php")
DB_PASS=$(grep -oP "db_password'\s*,\s*'\K[^']+" "$PIWIGO_DIR/local/config.php")
DB_NAME=$(grep -oP "db_base'\s*,\s*'\K[^']+" "$PIWIGO_DIR/local/config.php")

mkdir -p "$BACKUP_DIR"

mysqldump -u "$DB_USER" -p"$DB_PASS" --single-transaction --routines --triggers "$DB_NAME" \
  | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

tar -czf "$BACKUP_DIR/files_$DATE.tar.gz" \
  --exclude='_data' \
  -C /var/www piwigo

cp "$PIWIGO_DIR/local/config.php" "$BACKUP_DIR/config_$DATE.php"

find "$BACKUP_DIR" -type f -mtime +"$RETENTION_DAYS" -delete

echo "$(date -Is) OK: db_$DATE.sql.gz, files_$DATE.tar.gz" >> "$BACKUP_DIR/backup.log"

chmod 700 /usr/local/bin/piwigo-backup.sh
crontab -e

Строка в crontab — бэкап каждую ночь в 03:15, когда сайт менее нагружен:

15 3 * * * /usr/local/bin/piwigo-backup.sh

Учтите объём: если галерея на десятки гигабайт RAW-фото, полный tar каждую ночь съедает и время, и место на диске. Разумная практика — полный архив файлов раз в неделю, а между ними бэкапить только базу (она весит несравнимо меньше) плюс инкрементальный перенос новых файлов через rsync в отдельное хранилище.

Восстановление Piwigo из бэкапа

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

1. Установите те же версии PHP и MySQL/MariaDB, что были на исходном сервере (или хотя бы совместимые — Piwigo чувствителен к минимальной версии PHP, актуальные релизы на 2026 год требуют PHP 8.1+).

1. Создайте пустую базу и пользователя:

mysql -u root -p -e "CREATE DATABASE piwigo_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p -e "CREATE USER 'piwigo_user'@'localhost' IDENTIFIED BY 'новый_пароль';"
mysql -u root -p -e "GRANT ALL ON piwigo_db.* TO 'piwigo_user'@'localhost';"

1. Восстановите дамп:

gunzip -c /var/backups/piwigo/db_2026-08-25.sql.gz | mysql -u piwigo_user -p piwigo_db

1. Разверните архив файлов в веб-корень:

tar -xzf /var/backups/piwigo/files_2026-08-25.tar.gz -C /var/www

1. Верните права на файлы веб-серверу:

chown -R www-data:www-data /var/www/piwigo
find /var/www/piwigo -type d -exec chmod 755 {} \;
find /var/www/piwigo -type f -exec chmod 644 {} \;

1. Восстановите local/config.php и проверьте в нём креды к базе — если пароль или имя базы изменились на новом сервере, впишите актуальные значения вручную, не полагаясь на файл из бэкапа один в один:

cp /var/backups/piwigo/config_2026-08-25.php /var/www/piwigo/local/config.php
nano /var/www/piwigo/local/config.php

1. Дайте Piwigo пересоздать кэш производных — либо просто откройте галерею в браузере (первая загрузка альбома будет медленнее), либо принудительно очистите то, что осталось от старого _data, чтобы не смешивать кэш с разных серверов:

rm -rf /var/www/piwigo/_data/i/*

После этого зайдите в админку Piwigo и проверьте раздел «Обслуживание» (Maintenance) — там есть проверка целостности базы и синхронизация файлов с записями в БД, полезно прогнать один раз сразу после восстановления.

Бэкап вне сервера

Резервная копия, которая лежит на том же диске, что и оригинал, страхует только от испорченной базы или неудачного обновления плагина — не от отказа диска, кражи сервера или блокировки аккаунта у хостера. Файлы бэкапа стоит сразу же уводить на другую машину или в объектное хранилище.

Для регулярной синхронизации подходит rsync по SSH на второй сервер:

rsync -avz --delete /var/backups/piwigo/ backup-user@second-server:/backups/piwigo/

Для полноценного версионированного бэкапа с дедупликацией и шифрованием лучше подойдёт restic или rclone до S3-совместимого хранилища — там уже есть встроенное шифрование и хранение снимков за разные даты без ручной ротации. Если раньше не настраивали такие инструменты, подробный разбор есть в статье про restic — принцип с Piwigo тот же: указываете каталог /var/backups/piwigo как источник и получаете зашифрованные версии по расписанию.

Отдельный сервер под архив бэкапов — практика, которая себя окупает при первом же серьёзном инциденте: если основной сервер выходит из строя целиком, бэкапы на нём же бесполезны. Разбор того, как подобрать и настроить машину именно под эту задачу, есть в статье про VPS для бэкапов и архива.

Частые ошибки и подводные камни

• Бэкап только базы данных. Метаданные без файлов бесполезны — Piwigo хранит пути и описания в БД, но сами изображения физически лежат в upload/. Без файлов восстановление даёт пустую структуру альбомов.
• Бэкап только файлов, без базы. Обратная ситуация — папка с тысячами файлов без БД превращается в свалку без названий, тегов и структуры альбомов, разбирать которую придётся вручную.
• Забытый local/config.php. Если восстановили файлы и базу, но не подложили правильный конфиг с актуальными db-кредами и секретным ключом — сайт либо не подключится к базе, либо разлогинит пользователей и покажет битые ссылки на превью.
• Дамп без --single-transaction на живом сайте. На таблицах InnoDB это создаёт риск несогласованного дампа при параллельной загрузке фото во время снятия бэкапа; для MyISAM корректнее --lock-tables.
• Не проверяют место на диске перед tar. Архив галереи на десятки гигабайт может не поместиться в /var/backups, если она на том же разделе, что и /var/www. Проверяйте df -h перед первым полным бэкапом и, если нужно, сразу пишите архив на смонтированный отдельный диск.
• Разные версии PHP/MySQL при восстановлении на другом сервере. Если исходная установка на PHP 7.4, а новый сервер — на PHP 8.3, дамп базы восстановится без проблем, но сам Piwigo может потребовать обновления через админку — учитывайте это заранее, не в момент простоя.
• Расхождение charset базы. Если исходная база была в utf8 (не utf8mb4), а новую создали с другой кодировкой по умолчанию — при импорте дампа могут «поплыть» названия альбомов с не-латинскими символами. Явно указывайте CHARACTER SET при создании базы под восстановление, совпадающий с оригиналом.

Смежная тема, если Piwigo стоит на том же сервере, что и сама база — общие грабли резервного копирования MySQL разобраны в статье про бэкап MySQL, а порядок действий при восстановлении конкретно базы данных — в статье про восстановление БД из бэкапа.

Частые вопросы