Архивиране на WordPress в PHP: скрипт за автоматично архивиране

by | WordPress

Ако вече сте открили сайт WordPress Ако сайтът ви е „счупен“ след актуализация и последното ви архивиране е на три седмици, знаете истинския проблем: не е WordPress, а вашата рутина за архивиране. WordPress 6.9.4 работи перфектно на PHP 8.1+, но никоя CMS не ви предпазва от случайно изтриване, пълен твърд диск, хакване или лошо импортиране.

Нуждата/проблемът със сървъра

Едно използваемо резервно копие на WordPress трябва да покрива Deux неща:

  • Базата данни (статии, страници, настройки, потребители, поръчки в WooCommerce и др.).
  • Файловете (wp-съдържание като приоритет: теми, плъгини, Качени(възможен кеш, mu-плъгини).

Проблемът произтича от два капана, които виждам постоянно в блоговете:

  • „Ръчното“ архивиране (изтеглен zip файл + ръчно SQL експортиране) никога не се прави в точния момент.
  • „Автоматичното“ архивиране се съхранява в публичния файл (напр.: /public_html/backups), следователно достъпен, ако някой познае URL адреса, или изтрит, ако сървърът спре да работи.

До края ще знаете как да настроите скрипт AUTOMATIQUE чрез SSH + cron, което:

  • експортира базата данни чрез WP-CLI (по-надежден от phpMyAdmin за автоматизация),
  • архивиране на критични файлове
  • компресира, регистрира, криптира (по избор),
  • направи един въртене (съхранява N резервни копия),
  • и се тества на сцена, преди да се докосне до продукцията.

Диви 5 / Elementor Avada: няма пряко въздействие. Скриптът запазва едни и същи папки, но имайте предвид, че тези конструктори понякога съхраняват ресурси в uploads и данни от базата данни: следователно трябва да ги архивирате Les Deux.

Бързо обобщение

  • Вие спестявате WP-съдържание + едно дъмп SQL генерирани от WP-CLI.
  • Вие съхранявате резервните копия извън уеб корена (Например, /home/USER/backups), със строги разрешения.
  • Използвате един Bash скрипт, с трупи et въртене.
  • Планирате чрез Cron (не чрез WP-Cron), за да се избегнат резервни копия, задействани произволно от посещения.
  • Тествате реставрацията върху постановка (винаги) и само тогава в продукцията.
  • Добавяте опция задистанционно изпращане (SSH/SFTP), ако искате да преживеете загубата на сървъра.

Преди да започнете (предварителни изисквания)

Необходим достъп:

  • SSH на сървъра (задължително), за да изпълнява команди и да инсталира cron.
  • WP-CLI Инсталирано е (често вече е налично на VPS/управлявани сървъри). В противен случай можете да го инсталирате.
  • Достъп до директорията на WordPress (път от типа /var/www/site ou /home/user/public_html).
  • По избор: Достъп до MySQL (ако искате да проверите импорта ръчно).

Архивирането е задължително преди всяка операция със сървъра: да, парадоксално е, но ще променяте разрешения, cron задачи и потенциално скриптове. Като минимум, направете копие на wp-config.php и експорт на база данни чрез текущия ви метод.

Препоръчителни версии (април 2026 г.):

  • WordPress: 6.9.4
  • PHP: 8.1 + (8.2/8.3 обикновено е по-добра, ако вашият хостинг доставчик я поддържа)
  • MySQL: 8+ или MariaDB 10.6+
  • Сървър: Nginx или Apache (и двата са подходящи)

Напомняне за сигурност: никога не съхранявайте некриптиран SQL дъмп в достъпна уеб папка. Дъмпът съдържа имейли, понякога адреси и хашиш пароли. В случай на изтичане, това е сериозен инцидент.

Полезни официални източници:

Стъпка 1: Определете реалистична стратегия за архивиране (файлове + база данни)

Преди да напишете какъвто и да е код, решете Quoi спестяваш и Колко дълго Вие пазите архивите. Една проста стратегия, подходяща за блогъри:

  • Quotidien база + wp-content (или поне wp-content/uploads (ако дискът ви е малък).
  • Задържане 7 дни (ежедневно), + 4 седмици (седмично), + 3 месеца (месечно), ако е възможно.

В това ръководство прилагаме „проста“ ротация: запазване на Последни 14 Ежедневни резервни копия. Лесно се поддържа и можете да го разширите по-късно.

Защо предпочитам wp-content към „пълния сайт“? Защото:

  • Ядрото на WordPress (wp-admin, wp-includes) се изтегля отново.
  • Конструкторите (Divi/Elementor/Avada) и вашето медийно съдържание живеят в wp-content.
  • Архивите са по-малки, следователно по-бързи и следователно се обработват по-често.

Стъпка 2: Подгответе директория за офлайн архивиране + разрешения

цел: КРЕЕ файл извън уеб коренаТипичен пример:

  • WordPress е вътре /var/www/mon-site
  • Резервни копия в /var/backups/mon-site (или /home/user/backups/mon-site (споделено)

Командата по-долу създава папката, задава собственик и заключва разрешенията. Адаптирайте потребителското име (www-data под Debian/Ubuntu, понякога nginx или вашият потребител в споделен хостинг).

# Créez un dossier de backup hors du webroot
sudo mkdir -p /var/backups/mon-site

# Donnez l'accès à l'utilisateur qui exécute PHP/cron (adaptez)
sudo chown -R www-data:www-data /var/backups/mon-site

# Permissions strictes : seul le propriétaire lit/écrit/exécute
sudo chmod 700 /var/backups/mon-site

Очакван резултат: папка, недостъпна от мрежата и не може да бъде изброена чрез HTTP. Ако сте на споделен хостинг без sudo, направете:

mkdir -p ~/backups/mon-site
chmod 700 ~/backups/mon-site

В този момент проверете дисковото пространство. Архивирането често се проваля „тихо“, защото дискът е пълен.

# Espace disque
df -h

# Taille du wp-content (pour estimer)
du -sh /var/www/mon-site/wp-content

Стъпка 3: Напишете скрипт за автоматично архивиране (Bash) с ротация

Ще създадем един изпълним Bash скрипт, който:

  • Намира се в папката на WordPress.
  • Извършва експортиране на база данни чрез WP-CLI.
  • архив wp-content + SQL дъмп,
  • изтрива резервни копия след определен брой,
  • пише дневник.

Защо Bash (а не PHP)? За архивиране на сървър, Bash е по-директен: достъп до системни инструменти (tar, gzip, find), обработка на грешки, изпълнение чрез cron. И избягвате зареждането на WordPress през HTTP (риск от изчакване).

Създайте файла /usr/local/bin/wp-backup-mon-site.sh (или ~/bin/... (в споделен хостинг). Командата по-долу отваря редактор (nano). Можете да използвате vim, ако предпочитате.

sudo nano /usr/local/bin/wp-backup-mon-site.sh

Поставете този пълен скрипт (коригирайте пътищата). Коментарите са на френски и обясняват изборите.

#!/usr/bin/env bash
set -euo pipefail

# ==============================
# Script de backup WordPress (WP 6.9.4+)
# - Dump SQL via WP-CLI
# - Archive wp-content + dump
# - Rotation (garde N backups)
# - Log d'exécution
# ==============================

# Chemin vers l'installation WordPress (dossier contenant wp-config.php)
WP_PATH="/var/www/mon-site"

# Dossier de destination des backups (hors webroot)
BACKUP_DIR="/var/backups/mon-site"

# Nombre de backups à conserver
KEEP_LAST=14

# Binaire WP-CLI (souvent "wp" si dans le PATH)
WP_BIN="/usr/local/bin/wp"

# Date pour nommer les fichiers
NOW="$(date +%F_%H-%M-%S)"

# Fichiers générés
DB_DUMP="${BACKUP_DIR}/db_${NOW}.sql"
ARCHIVE="${BACKUP_DIR}/backup_${NOW}.tar.gz"
LOG_FILE="${BACKUP_DIR}/backup.log"

# Fonction de log
log() {
  echo "[$(date +%F %T)] $*" | tee -a "${LOG_FILE}"
}

# Vérifications de base
if [[ ! -d "${WP_PATH}" ]]; then
  echo "WP_PATH introuvable: ${WP_PATH}" >&2
  exit 1
fi

if [[ ! -f "${WP_PATH}/wp-config.php" ]]; then
  echo "wp-config.php introuvable dans: ${WP_PATH}" >&2
  exit 1
fi

if [[ ! -d "${BACKUP_DIR}" ]]; then
  echo "BACKUP_DIR introuvable: ${BACKUP_DIR}" >&2
  exit 1
fi

if [[ ! -x "${WP_BIN}" ]]; then
  echo "WP-CLI introuvable/exécutable: ${WP_BIN}" >&2
  exit 1
fi

log "Début backup: WP_PATH=${WP_PATH} BACKUP_DIR=${BACKUP_DIR}"

# Se placer dans le dossier WordPress
cd "${WP_PATH}"

# 1) Export base de données (WP-CLI)
# --single-transaction limite les verrous (InnoDB)
# --quick réduit la mémoire côté client
log "Export base (WP-CLI) vers ${DB_DUMP}"
"${WP_BIN}" db export "${DB_DUMP}" --add-drop-table --single-transaction --quick

# 2) Archive des fichiers
# On sauvegarde wp-content + le dump SQL
# --warning=no-file-changed évite des warnings si des fichiers changent pendant l'archivage
log "Archivage wp-content + dump SQL vers ${ARCHIVE}"
tar --warning=no-file-changed -czf "${ARCHIVE}" 
  -C "${WP_PATH}" wp-content 
  -C "${BACKUP_DIR}" "$(basename "${DB_DUMP}")"

# 3) Optionnel : checksum pour vérifier l'intégrité
log "Génération checksum SHA-256"
sha256sum "${ARCHIVE}" >> "${BACKUP_DIR}/checksums.sha256"

# 4) Nettoyage : supprimer le dump SQL brut après intégration dans l'archive
log "Suppression du dump SQL brut ${DB_DUMP}"
rm -f "${DB_DUMP}"

# 5) Rotation : garder les N derniers backups
log "Rotation: conservation des ${KEEP_LAST} derniers backups"
ls -1t "${BACKUP_DIR}"/backup_*.tar.gz 2>/dev/null | tail -n +"$((KEEP_LAST+1))" | xargs -r rm -f

log "Backup terminé: ${ARCHIVE}"

Направете го изпълним:

sudo chmod 750 /usr/local/bin/wp-backup-mon-site.sh
sudo chown root:root /usr/local/bin/wp-backup-mon-site.sh

Практическа забележка: ако вашата cron задача се изпълнява под www-data (или вашият потребител), можете да поставите потребителя-собственик там. На малък VPS често предпочитам да стартирам архивирането като root (cron root), но да записвам в заключена папка. На споделен хостинг няма да имате root достъп: стартирайте всичко като ваш потребител.

Стъпка 4: Експортирайте базата данни правилно (WP-CLI) и проверете нейната цялост

WP-CLI е най-добрият ви съюзник за архивиране на WordPress, защото чете конфигурационните файлове (wp-config.phpи работи локално, без HTTP ограничения. Основните команди са:

  • wp db export експортиране на SQL
  • wp db import импортиране на SQL
  • wp db check проверка

Преди да настроите cron, тествайте ръчно скрипта (и прочетете лога). Изпълнете командата, след което проверете дали архивът е създаден.

# Exécution manuelle
sudo /usr/local/bin/wp-backup-mon-site.sh

# Vérifier la présence des fichiers
sudo ls -lh /var/backups/mon-site | tail -n 20

# Lire le log
sudo tail -n 50 /var/backups/mon-site/backup.log

Проверете целостта на архива:

# Tester l'archive (ne restaure rien, vérifie juste la structure gzip/tar)
gzip -t /var/backups/mon-site/backup_YYYY-MM-DD_HH-MM-SS.tar.gz

# Lister le contenu
tar -tzf /var/backups/mon-site/backup_YYYY-MM-DD_HH-MM-SS.tar.gz | head

Ако видите wp-content/ и файл db_....sqlТова е добър знак.

Стъпка 5: Планиране на изпълнението (cron) и регистриране

Не бъркайте:

  • WP-Cron : задейства се от посещения, не е надеждно за резервно копие на сървър.
  • cron система : задейства се във фиксирано време, надежден.

Ще планираме архивиране всяка вечер в 03:15. Преди да покажем cron реда, ето какво прави той:

  • изпълнява скрипта,
  • пренасочва стандартния изход и грешките към файл (в допълнение към вътрешния лог).
  • избягва изпращането на cron имейли, ако всичко работи правилно.

Редактирайте crontab файла (тук е за root; адаптирайте, ако използвате друг потребител):

sudo crontab -e

Добави:

# Backup WordPress quotidien à 03:15
15 3 * * * /usr/local/bin/wp-backup-mon-site.sh >> /var/backups/mon-site/cron.log 2>&1

На споделен хостинг (без sudo), използвайте:

crontab -e
15 3 * * * /home/VOTRE_USER/bin/wp-backup-mon-site.sh >> /home/VOTRE_USER/backups/mon-site/cron.log 2>&1

Съвет: Често съм виждал cron архиви да „не правят нищо“, просто защото cron няма същото. PATH отколкото вашата обвивка. Ето защо скриптът препраща /usr/local/bin/wp Изрично. Ако вашият WP-CLI се намира другаде, намерете го:

which wp
wp --info

Стъпка 6: Реставрация (подготовка, след това производство) без да бъдете хванати на капан

Непроверен архив е само хипотеза. Тествайте възстановяване на постановка (копие от сайта) преди деня, в който ви е необходимо.

6.1 Бърза подготовка на етапа

Най-простото решение: втори vhost (напр. staging.monsite.tld) сочейки към отделна папка и отделна база данни. От страна на кода/командата имате две опции:

  • Създайте нова инсталация на WordPress 6.9.4 и след това я възстановете.
  • Клонирайте файловете и създайте нова база данни, след което ги импортирайте.

Придържам се към сценария „нова инсталация + възстановяване“, който е по-чист.

6.2 Разархивиране на архива

Създайте целева папка (подготовка) и разархивирайте само това, от което се нуждаете. Тук ние възстановяваме wp-content и извличаме SQL дъмпа.

# Exemple : dossier staging
STAGING_PATH="/var/www/mon-site-staging"
ARCHIVE="/var/backups/mon-site/backup_YYYY-MM-DD_HH-MM-SS.tar.gz"

# Extraire
sudo tar -xzf "${ARCHIVE}" -C "${STAGING_PATH}"

# Vérifier que wp-content est bien en place
sudo ls -la "${STAGING_PATH}/wp-content" | head

Предупреждение: в зависимост от това как е структурирана вашата подготовка, може да извлечете wp-content на грешно ниво (често срещана грешка). Винаги проверявайте дървото на директориите след извличане.

6.3 Импортиране на базата данни

Намерете извлечения SQL файл (в този пример той е в архива в корена на папката за извличане). След това го импортирайте, използвайки WP-CLI.

# Se placer dans le staging (dossier contenant wp-config.php du staging)
cd /var/www/mon-site-staging

# Vérifier que WP-CLI "voit" bien WordPress
wp core version

# Import DB (adaptez le nom du fichier)
wp db import /var/www/mon-site-staging/db_YYYY-MM-DD_HH-MM-SS.sql

# Vérifier la base
wp db check

След импортиране често ще трябва да направите търсене-замяна URL адреси, ако сайтът за подготовка има различен домейн. WP-CLI се справя добре с това, но го правете внимателно (първо архивирайте данните си). Типична команда:

# Remplacer l'URL prod par l'URL staging (adaptez)
wp search-replace 'https://monsite.tld' 'https://staging.monsite.tld' --all-tables --precise --skip-columns=guid

Параметърът --skip-columns=guid Избягвайте да нарушавате GUID-тата на RSS публикациите. Това е добра практика, която винаги следвам.

Пълни конфигурационни файлове

Този раздел съдържа „готови за поставяне“ файлове, подходящи за архивиране: защита, PHP ограничения и пример за Nginx за блокиране на случайно излагане, ако все още съхранявате архиви в обслужвана папка (което не препоръчвам).

.htaccess (Apache): блокиране на папка за архивиране, ако нямате друг избор

В идеалния случай няма да ви е необходимо това (резервни копия извън webroot директорията). Ако вашият хостинг ви принуждава да съхранявате резервни копия в поддиректория на сайта, добавете .htaccess в този файл архивиране :

# Fichier: /chemin/site/backups/.htaccess
# Objectif: interdire tout accès HTTP aux archives et aux .sql
Require all denied

<FilesMatch ".(sql|gz|zip|tar|tgz)$">
  Require all denied
</FilesMatch>

nginx.conf: блокиране на достъпа до /backups/, ако е изложен

За Nginx, добавете блок в сървъра {} на сайта:

# Exemple à placer dans le server {} de votre vhost
location ^~ /backups/ {
  deny all;
  return 403;
}

wp-config.php: Принудително деактивиране на файловия редактор

Това не е „резервно копие“, но ограничава щетите в случай на компрометиран администраторски достъп. Добавете го към wp-config.php :

/** Désactive l'éditeur de fichiers dans l'admin (réduit le risque en cas de compromission) */
define('DISALLOW_FILE_EDIT', true);

Справка: wp-config.php (WordPress.org)

php.ini (или override): предотвратяване на изчакване по време на ресурсоемки операции

Вашият скрипт се изпълнява в CLI, така че до голяма степен зависи от ограниченията на CLI, но при някои хостинг планове WP-CLI може да наследи определени ограничения. Ето пример за разумни настройки:

; Exemple php.ini (adaptez selon votre hébergeur)
memory_limit = 512M
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M

Ако не сте сигурни къде да поставите това, не го насилвайте: на много сървъри се обработва глобално. Първо го тествайте.

проверка

Искате прости, повтаряеми контроли без графичен интерфейс.

1) Проверете дали cron работи

Изчакайте до насрочения час, след което:

# Voir les logs
sudo tail -n 100 /var/backups/mon-site/cron.log
sudo tail -n 100 /var/backups/mon-site/backup.log

Трябва да видите „Архивирането започва“, след това „Архивирането е завършено“.

2) Проверете въртенето

След няколко екзекуции:

ls -1 /var/backups/mon-site/backup_*.tar.gz | wc -l

Трябва да получите най-много числото, определено в KEEP_LAST.

3) Проверете целостта чрез контролна сума

cd /var/backups/mon-site
# Vérifie que les checksums correspondent (si vous ne conservez que les derniers, adaptez)
sha256sum -c checksums.sha256 2>/dev/null | tail -n 20

4) Проверете дали WP-CLI работи в неинтерактивен режим

Това е тест, който правя, когато cron се провали: cron има минимална среда.

sudo -u www-data /usr/local/bin/wp --info
sudo -u www-data /usr/local/bin/wp --path=/var/www/mon-site core version

Ако това не проработи

Когато автоматичното архивиране се провали, рядко е „WordPress“. Почти винаги се дължи на: път, разрешения, липсващ двоичен файл или липса на дисково пространство.

Диагноза стъпка по стъпка

1) Скриптът не се изпълнява

  • Проверете изпълнимия бит: ls -l /usr/local/bin/wp-backup-mon-site.sh
  • Проверете първия ред (шебанг): head -n 1 ...
  • Тествайте на живо: bash -x /usr/local/bin/wp-backup-mon-site.sh (режим на отстраняване на грешки)

2) WP-CLI се проваля през cron, но работи през SSH

  • Честа причина: WP_BIN неправилно или PATH различен.
  • Решение: Използвайте абсолютния път на wp (вече е направено в скрипта) и преминете --path=... ако е необходимо.
# Exemple si WP-CLI "ne trouve pas" WordPress
/usr/local/bin/wp --path=/var/www/mon-site db export /var/backups/mon-site/test.sql

3) „Разрешението е отказано“

  • Проверете собствеността и разрешенията за папката с резервно копие: namei -l /var/backups/mon-site
  • Проверете потребителя, който изпълнява cron: sudo crontab -l (ако е root) или crontab -l

4) Пълен диск

df -h
du -sh /var/backups/mon-site
du -sh /var/www/mon-site/wp-content/uploads

Диагностична диаграма (реалистични симптоми)

симптом Вероятна причина проверка Решение
Файлът cron.log остава празен Cron не е конфигуриран за правилния потребител crontab -l (потребител) и sudo crontab -l (Корен) Добавете задачата към правилния crontab
WP-CLI introuvable/exécutable WP_BIN неправилен или WP-CLI не е инсталиран which wp, wp --info Инсталирайте WP-CLI или коригирайте абсолютния път
Error: This does not seem to be a WordPress installation WP_PATH фалшив или лош текущ файл в cron ls -la $WP_PATH/wp-config.php фиксаж WP_PATH и/или употреба --path=
tar: Cannot open: Permission denied Недостатъчни права върху BACKUP_DIR ls -ld BACKUP_DIR chown/chmod адаптирано или стартирайте cron с правилния потребител
Много бавни резервни копия uploads Огромен, ограничен процесор, бавен входно-изходен режим du -sh uploads, top Изключване от кеша, превключване към инкрементален режим (rsync), увеличаване на прозореца за архивиране
Архивът е създаден, но не може да бъде възстановен Архивирането никога не е тествано, липсва дъмп, архивът е повреден tar -tzf, gzip -t Добавяне на контролна сума + тест за възстановяване при поставяне

Често срещани капани и грешки

Грешка Причина Решение
Копирайте скрипта в functions.php Объркване между „код на WordPress“ и „код на сървъра“ Архивирането на сървъра се извършва чрез SSH/cron, а не в темата (риск за сигурността + времеви ограничения).
Забравяне на точка и запетая... в Bash Частично копиране и поставяне, счупени кавички Улан bash -n script.sh et shellcheck ако е налична
Тестване директно в продукцията без съществуващо резервно копие Рутина „Ще видя по-късно“ Извършете поне едно ръчно архивиране, преди да разгърнете cron.
Резервни копия, съхранени в /public_html/backups По-просто „по това време“ Съхранявайте извън уеб корена; в противен случай блокирайте достъпа чрез Nginx/Apache + неразгадаеми имена
WP-CLI работи през SSH, но не и през cron Минимална cron среда (PATH) Използвайте абсолютен път до wp и дефинирайте WP_PATH
„Странни“ постоянни връзки след реставрация Негенерирани правила за пренаписване Улан wp rewrite flush --hard след реставрация (първо върху обработени повърхности)
Конфликт в кеша (непоследователни страници след възстановяване) Кеш на плъгините + кеш на сървъра + CDN Изчистване на кешовете (плъгин, Nginx fastcgi, CDN) след възстановяване
Стар урок, базиран на mysqldump с идентификатори в обикновен текст Копие на стари откъси Предпочитам wp db export (WordPress 6.9.4) и ограничаване на конфигурационните файлове

Сигурност на сървъра

Системата за архивиране може да се превърне в източник на изтичане на данни, ако се третира като обикновен zip файл.

1) Разрешения и местоположение

  • Архивите извън webroot (приоритет № 1).
  • Файл в 700, файлове в 600 ако е възможно.
  • Избягвайте да оставяте неща безредни .sql некомпресиран.

2) Криптиране (практичен вариант)

Ако е необходимо да прехвърлите/съхраните архива другаде (NAS, друг сървър), криптирайте го. Пример с OpenSSL (парола):

# Chiffre une archive (AES-256)
openssl enc -aes-256-cbc -salt -pbkdf2 
  -in /var/backups/mon-site/backup_YYYY.tar.gz 
  -out /var/backups/mon-site/backup_YYYY.tar.gz.enc

Риск: Ако загубите паролата, губите и резервното копие. Съхранявайте го в мениджър на пароли.

3) Дистанционно изпращане (оцеляване след повреда на сървъра)

„Истинският“ план за възстановяване след бедствие включва копие извън сървъра. Най-простият примерен код: rsync чрез SSH към друг сървър.

# Exemple: pousser les archives vers un serveur distant
# À faire après la création de l'archive, idéalement avec une clé SSH dédiée
rsync -av --delete /var/backups/mon-site/ backupuser@backup-host:/data/backups/mon-site/

4) Никога не излагайте логовете

Вашите лог файлове може да съдържат пътища, имена на файлове и друга информация, полезна за атакуващия. Съхранявайте ги на същото място като резервните ви копия, извън уеб кореновата директория.

ресурси

Често задавани въпроси

Мога ли да направя това архивиране „чрез код“ в плъгин за WordPress?

Технически да, но не го препоръчвам на начинаещи: стартирането на архиви и експортиране на бази данни чрез HTTP заявки ви излага на изтичане на времето и рискове за сигурността (някой може да задейства архивирането). Системна cron задача плюс SSH скрипт е по-надеждна.

Защо не направите резервно копие на целия WordPress (включително ядрото)?

Можете, но това значително увеличава размера на архива, което води до малка полза. Ядрото ще се преинсталира. wp-content + DB обхваща най-важното.

Съвместим ли е WP-CLI с WordPress 6.9.4?

Да, WP-CLI поддържа WordPress. Инсталирайте скорошна версия. Проверете с wp --info и тест wp core version.

Нямам достъп до SSH, какво да правя?

Без SSH няма да можете да извършите истинско автоматизирано архивиране от страна на сървъра, използвайки скриптове или cron задачи. Реалистичните ви алтернативи са надежден плъгин за архивиране или искане от вашия доставчик на хостинг услуги да активира SSH/cron.

Колко резервни копия трябва да запазя?

За блог: 14 публикации дневно са добра отправна точка. Ако публикувате често (или използвате WooCommerce), увеличете това и добавете отдалечено копие.

Как да изключа кеш папките в wp-content?

Можете да изключвате пътища в tar, но това е по-сложно. Кешът може да се регенерира, така че изключването му намалява размера. Пример (ще бъде адаптиран): използвайте --exclude='wp-content/cache' в командата tar.

Уебсайтът ми е огромен, tar/gzip са твърде бавни. Има ли някакви алтернативи?

Да: инкрементално архивиране от rsync (моментна снимка) и отделен дъмп на базата данни. Това често е, което качвам в медийни сайтове с масивни качвания.

След възстановяване, Elementor/Divi/Avada показва счупени оформления.

Типични причини: URL адресът не е заменен (търсене-замяна), кешът не е изчистен или генерирани ресурси, нуждаещи се от повторно генериране. wp search-replaceИзчистете кеша, след което регенерирайте CSS файловете чрез конструктора, ако е необходимо.

Мога ли да съхранявам резервните копия на същия сървър, но в различна папка?

Да, но това не предпазва от пълен срив на сървъра. Минимумът е „извън уеб корена“. Идеалният вариант е „извън сървъра“.

Как мога да съм сигурен, че резервното ми копие съдържа базата данни?

Избройте архива: tar -tzf backup_...tar.gz и проверете за наличието на db_....sqlСлед това, тествайте реставрацията на етап подготовка: това е единственият тест, който наистина има значение.

Статии

Коментирай

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани *

Този сайт използва Akismet за намаляване на спама. Научете как се обработват вашите коментарни данни.