Резервная копия сайта — одна из тех задач, о которых обычно вспоминают после сбоя сервера, неудачного обновления или случайного удаления файлов. При этом полноценную систему backup можно организовать без сложной инфраструктуры: достаточно небольшого скрипта, cron и облачного хранилища.
В этой статье разберём, как автоматизировать резервное копирование сайта в S3-совместимое объектное хранилище и Яндекс Диск, какие данные нужно сохранять, как делать архивы, проверять результат и удалять старые копии.
Примеры рассчитаны прежде всего на Linux-сервер с SSH-доступом. Команды можно адаптировать под Ubuntu/Debian, CentOS/AlmaLinux и другие Unix-подобные системы.
Зачем автоматизировать backup
Ручное копирование имеет несколько очевидных проблем:
- его легко забыть;
- непонятно, действительно ли предыдущая копия пригодна для восстановления;
- локальная копия пропадёт вместе с сервером при серьёзной аварии;
- со временем накопится большое количество архивов;
- при каждом backup приходится выполнять одни и те же операции.
Автоматизация превращает резервное копирование в регулярный процесс:
Сайт
│
├── файлы
│
└── база данных
│
▼
backup.sh
│
├── архив файлов
├── дамп БД
└── проверка
│
▼
Облачное хранилище
├── S3
└── Яндекс Диск
Главная идея: резервная копия должна находиться отдельно от сервера, который она защищает.
Если хранить backup только в /backup на том же VPS, то выход из строя диска, удаление файлов или компрометация сервера могут уничтожить и сайт, и его резервные копии.
Что именно нужно сохранять
Полноценный backup сайта обычно состоит минимум из двух частей:
- файлов сайта;
- базы данных.
Например, для сайта на PHP/MySQL это может выглядеть так:
/var/www/example.com/
├── public/
├── app/
├── config/
├── uploads/
└── ...
MySQL
└── example_db
Сохранить только каталог сайта недостаточно.
В базе данных могут находиться:
- пользователи;
- заказы;
- товары;
- настройки CMS;
- статьи;
- комментарии;
- данные интернет-магазина;
- содержимое форм;
- служебные таблицы.
И наоборот: сохранить только SQL-дамп недостаточно, если сайт содержит загруженные изображения, документы или другие файлы.
Поэтому разумная схема:
backup/
├── files.tar.gz
└── database.sql.gz
или один общий архив:
example.com-2026-08-26_03-00.tar.gz
Однако на практике удобнее часто хранить файлы и базу отдельно. Это позволяет восстановить, например, только БД, не распаковывая несколько гигабайт файлов сайта.
Какой способ хранения выбрать
Для автоматических backup наиболее интересны два варианта:
| Критерий | S3 / S3-compatible | Яндекс Диск |
|---|---|---|
| Тип хранилища | Объектное | Файловое |
| Интеграция со скриптами | Отличная | Хорошая |
| CLI-инструменты | AWS CLI и аналоги | WebDAV / REST API |
| Версионирование | Да | Зависит от способа работы |
| Lifecycle-политики | Да | Ограниченнее |
| Удобство для больших объёмов backup | Высокое | Среднее |
| Подходит для production | Да | Да, при правильной настройке |
| Простота для небольшого проекта | Средняя | Высокая |
Для профессиональной инфраструктуры чаще стоит выбирать S3 или S3-compatible storage. Для небольших сайтов и проектов может быть удобно использовать Яндекс Диск.
Важно не путать Яндекс Диск с S3-совместимым объектным хранилищем Яндекс Object Storage. Это разные сервисы и разные модели работы.
Яндекс предоставляет REST API для Диска, а WebDAV позволяет работать с ним как с файловой системой.
Вариант 1. Резервное копирование в S3
S3 — объектное хранилище, изначально разработанное Amazon. Сегодня существует множество S3-compatible сервисов, поэтому одна и та же концепция применяется не только к Amazon S3.
Для командной строки удобно использовать AWS CLI.
Команда:
aws s3 sync /var/www/example.com s3://my-backup-bucket/example.com/
синхронизирует локальный каталог с S3. AWS CLI поддерживает sync, фильтрацию, --dryrun, --delete, работу с endpoint и другие параметры.
Но для backup сайта простого sync не всегда достаточно.
Почему sync — не идеальный backup
Представим:
День 1:
site/
├── index.php
├── config.php
└── image.jpg
День 2:
image.jpg удалён
Если использовать:
aws s3 sync site/ s3://bucket/site/ --delete
то удаление может быть отражено и в хранилище.
Для обычной синхронизации это правильно.
Для backup — потенциально опасно.
Нам часто нужны отдельные снимки состояния сайта, например:
backups/
├── 2026-08-24/
├── 2026-08-25/
├── 2026-08-26/
└── ...
Тогда удаление файла на сервере не уничтожает его автоматически во вчерашней резервной копии.
Подготовка AWS CLI
На сервере устанавливаем AWS CLI.
После установки проверяем:
aws --version
Далее задаём credentials:
aws configure
CLI попросит:
AWS Access Key ID
AWS Secret Access Key
Default region name
Default output format
Для production лучше не использовать ключи с максимальными правами.
Создайте отдельную учётную запись или IAM-политику только для backup.
Например, логика разрешений может быть такой:
backup-user
├── ListBucket
├── PutObject
└── GetObject
Если скрипту не нужно удалять резервные копии, не стоит выдавать ему право DeleteObject.
Это важный принцип безопасности: backup-скрипт должен иметь минимально необходимые права.
Создаём архив сайта
Допустим, сайт расположен здесь:
/var/www/example.com
Создадим переменные:
SITE_DIR="/var/www/example.com"
BACKUP_DIR="/var/backups/example.com"
DATE=$(date +"%Y-%m-%d_%H-%M-%S")
Архив:
tar -czf \
"$BACKUP_DIR/site-$DATE.tar.gz" \
-C "$SITE_DIR" .
Получим:
site-2026-08-26_03-00-00.tar.gz
Флаг -z включает gzip-сжатие.
Резервная копия MySQL
Для MySQL/MariaDB можно использовать mysqldump.
Пример:
mysqldump \
--single-transaction \
--routines \
--triggers \
example_db | gzip > \
"$BACKUP_DIR/database-$DATE.sql.gz"
--single-transaction особенно полезен для InnoDB: дамп можно получить без длительной блокировки обычных операций записи.
Для production-системы конкретные параметры стоит подбирать с учётом версии MySQL/MariaDB, размера базы и используемых таблиц.
Полный Bash-скрипт для S3
Ниже — базовый вариант, который:
- создаёт каталог для backup;
- архивирует файлы сайта;
- создаёт дамп базы;
- загружает оба файла в S3;
- удаляет локальные архивы старше заданного срока.
#!/usr/bin/env bash
set -euo pipefail
SITE_DIR="/var/www/example.com"
BACKUP_DIR="/var/backups/example.com"
DB_NAME="example_db"
S3_BUCKET="s3://my-backup-bucket"
S3_PREFIX="example.com"
RETENTION_DAYS=7
DATE=$(date +"%Y-%m-%d_%H-%M-%S")
mkdir -p "$BACKUP_DIR"
echo "[$(date)] Backup started"
echo "Creating site archive..."
tar -czf \
"$BACKUP_DIR/site-$DATE.tar.gz" \
-C "$SITE_DIR" .
echo "Creating database dump..."
mysqldump \
--single-transaction \
--routines \
--triggers \
"$DB_NAME" \
| gzip > "$BACKUP_DIR/database-$DATE.sql.gz"
echo "Uploading files to S3..."
aws s3 cp \
"$BACKUP_DIR/site-$DATE.tar.gz" \
"$S3_BUCKET/$S3_PREFIX/"
aws s3 cp \
"$BACKUP_DIR/database-$DATE.sql.gz" \
"$S3_BUCKET/$S3_PREFIX/"
echo "Cleaning old local backups..."
find "$BACKUP_DIR" \
-type f \
-mtime +"$RETENTION_DAYS" \
-delete
echo "[$(date)] Backup completed successfully"
AWS CLI поддерживает как отдельные cp, так и s3 sync; для больших наборов файлов sync может быть удобнее, а для versioned backup-архивов — загрузка конкретных файлов.
Добавляем проверку backup
Очень распространённая ошибка — считать backup успешным только потому, что скрипт завершился.
Хорошая система должна проверять хотя бы:
- завершилась ли команда дампа;
- создан ли архив;
- имеет ли архив ненулевой размер;
- успешно ли прошла загрузка;
- существует ли объект в облаке.
Например:
if [ ! -s "$BACKUP_DIR/database-$DATE.sql.gz" ]; then
echo "ERROR: database backup is empty"
exit 1
fi
Для проверки архива:
tar -tzf "$BACKUP_DIR/site-$DATE.tar.gz" > /dev/null
Если архив повреждён, tar вернёт ошибку.
Можно также проверить объект после загрузки:
aws s3 ls \
"$S3_BUCKET/$S3_PREFIX/site-$DATE.tar.gz"
Ещё лучше: контрольная сумма
Для дополнительной проверки можно создать SHA-256:
sha256sum \
"$BACKUP_DIR/site-$DATE.tar.gz" \
"$BACKUP_DIR/database-$DATE.sql.gz" \
> "$BACKUP_DIR/checksums-$DATE.sha256"
После загрузки в S3 этот файл также отправляется в облако:
aws s3 cp \
"$BACKUP_DIR/checksums-$DATE.sha256" \
"$S3_BUCKET/$S3_PREFIX/"
Теперь при восстановлении можно проверить:
sha256sum -c checksums-2026-08-26_03-00-00.sha256
Версионирование S3
Для backup особенно полезна функция S3 Versioning.
При включённом versioning несколько вариантов одного объекта сохраняются в bucket. Если объект был случайно перезаписан или удалён, предыдущую версию можно восстановить.
Это дополнительный уровень защиты:
S3 bucket
│
├── backup.tar.gz
│ ├── version A
│ ├── version B
│ └── version C
│
└── database.sql.gz
├── version A
└── version B
Но versioning не означает, что backup автоматически становится «вечным».
Каждая версия занимает место, а значит, растёт стоимость хранения. AWS отдельно указывает, что каждая версия объекта хранится как полноценный объект, а не как diff.
Поэтому versioning стоит комбинировать с lifecycle-политиками.
Автоматическое удаление старых копий в S3
Например, можно установить правило:
0–30 дней → стандартное хранение
30–90 дней → более дешёвый класс
90+ дней → удалить
S3 Lifecycle позволяет автоматически переводить объекты между классами хранения, архивировать их или удалять после заданного периода.
При использовании versioning нужно отдельно учитывать старые версии объектов: lifecycle может управлять и noncurrent versions.
Это позволяет реализовать нормальную политику хранения:
Каждый день:
↓
ежедневные backup
Храним:
7 последних дневных
4 недельных
12 месячных
Старые:
удаляем автоматически
Вариант 2. Резервное копирование на Яндекс Диск
Яндекс Диск можно использовать для хранения backup через API.
У Яндекс Диска есть REST API, предназначенный для работы с файлами из веб-сервисов, а также WebDAV API.
WebDAV позволяет обращаться к Диску как к файловой системе:
webdav.yandex.ru
и использовать сторонние программы и библиотеки, поддерживающие WebDAV.
При этом в 2026 году есть важное ограничение: согласно актуальной документации Яндекса, с 22 июня 2026 года доступ к WebDAV требует тарифа Яндекс 360.
Поэтому перед внедрением WebDAV в коммерческий проект обязательно проверьте актуальные условия конкретного аккаунта.
Подключение Яндекс Диска через WebDAV
В документации Яндекс рекомендует использовать отдельный пароль приложения, а не основной пароль аккаунта. Подключение выполняется через HTTPS/WebDAV; для серверного сценария это существенно безопаснее, чем хранить основной пароль пользователя.
Пример точки подключения:
https://webdav.yandex.ru
Для Linux можно использовать WebDAV-клиент или специализированную программу синхронизации.
Например, после подключения удалённый каталог может быть доступен локально:
/mnt/yandex-backup/
Тогда загрузка архива становится обычным копированием:
cp \
/var/backups/example.com/site-2026-08-26.tar.gz \
/mnt/yandex-backup/example.com/
Но для production лучше использовать специализированный механизм синхронизации или REST API, а не строить критически важный backup-процесс вокруг ручного монтирования файловой системы.
Работа с Яндекс Диском через REST API
Если нужна полноценная интеграция, можно использовать REST API.
Общая схема:
backup.sh
│
├── создаёт архив
│
├── получает OAuth-токен
│
└── отправляет файл
│
▼
Яндекс Диск API
REST API Яндекс Диска требует OAuth-токен для доступа к пользовательским данным.
Принципиально загрузка выглядит следующим образом:
curl -X GET \
-H "Authorization: OAuth $YANDEX_TOKEN" \
"https://cloud-api.yandex.net/v1/disk/resources/upload?path=/backups/site.tar.gz&overwrite=true"
API возвращает URL для загрузки файла. После этого файл отправляется по полученному адресу.
Упрощённый Python-вариант:
import os
import requests
TOKEN = os.environ["YANDEX_TOKEN"]
FILE_PATH = "/var/backups/example.com/site.tar.gz"
remote_path = "/backups/site.tar.gz"
headers = {
"Authorization": f"OAuth {TOKEN}"
}
response = requests.get(
"https://cloud-api.yandex.net/v1/disk/resources/upload",
headers=headers,
params={
"path": remote_path,
"overwrite": "true"
}
)
response.raise_for_status()
upload_url = response.json()["href"]
with open(FILE_PATH, "rb") as file:
upload = requests.put(
upload_url,
data=file
)
upload.raise_for_status()
print("Backup uploaded successfully")
Для production-кода стоит добавить обработку сетевых ошибок, повторные попытки, таймауты и проверку результата.
S3 или Яндекс Диск: что выбрать?
S3 лучше, если нужен production backup
S3 особенно удобен, когда:
- сайтов много;
- backup выполняется автоматически;
- нужен большой объём хранения;
- нужны lifecycle-политики;
- требуется versioning;
- нужно разграничить права доступа;
- backup должен быть частью серверной инфраструктуры.
Архитектура:
100 сайтов
│
├── backup #1 ──┐
├── backup #2 ──┤
├── backup #3 ──┤
└── backup #N ──┘
↓
S3 bucket
Это хорошо масштабируется.
Яндекс Диск удобен для небольших проектов
Он может быть рациональным выбором, когда:
- сайтов немного;
- объём backup небольшой;
- команда уже использует Яндекс 360;
- нужен простой доступ к архивам;
- не требуются сложные object-storage политики.
Но WebDAV имеет ограничения и организационные особенности, поэтому для серьёзной серверной инфраструктуры стоит рассматривать API или специализированное объектное хранилище.
Как настроить cron
После того как скрипт работает вручную, его можно запускать автоматически.
Например:
chmod +x /usr/local/bin/backup-example.sh
Открываем cron:
crontab -e
И добавляем:
0 3 * * * /usr/local/bin/backup-example.sh >> /var/log/backup-example.log 2>&1
Теперь backup будет запускаться ежедневно в 03:00.
Можно выбрать другой интервал:
# каждый день в 03:00
0 3 * * * /usr/local/bin/backup-example.sh
# каждые 6 часов
0 */6 * * * /usr/local/bin/backup-example.sh
# каждый понедельник в 04:00
0 4 * * 1 /usr/local/bin/backup-example.sh
Для большинства корпоративных сайтов ежедневного backup достаточно. Для интернет-магазина или сервиса с большим количеством изменений может потребоваться более частое копирование.
Не храните пароли прямо в скрипте
Плохой вариант:
PASSWORD="my-super-secret-password"
или:
YANDEX_TOKEN="..."
в самом скрипте.
Почему это опасно:
- файл может попасть в Git;
- другой пользователь сервера может его прочитать;
- пароль окажется в резервной копии;
- секрет будет сложнее заменить.
Лучше использовать:
export YANDEX_TOKEN="..."
или защищённый конфигурационный файл:
/etc/example-backup.env
с правами:
chmod 600 /etc/example-backup.env
Например:
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
S3_BUCKET=s3://...
И загружать его:
source /etc/example-backup.env
Ещё лучше — использовать специализированное хранилище секретов или IAM-механизм, если инфраструктура это позволяет.
Не включайте backup в backup
Представим:
/var/www/example.com
/var/backups/example.com
Если каталог /var/backups находится внутри дерева, которое архивируется, можно случайно получить:
backup
└── backup
└── backup
└── ...
Поэтому backup-каталог должен находиться за пределами директории сайта.
Например:
/var/www/example.com
/var/backups/example.com
или вообще на отдельном диске.
Что исключать из архива
Не всегда нужно копировать всё подряд.
Например, можно исключить:
cache/
tmp/
logs/
node_modules/
.git/
Пример:
tar -czf "$ARCHIVE" \
--exclude="$SITE_DIR/cache" \
--exclude="$SITE_DIR/tmp" \
--exclude="$SITE_DIR/.git" \
-C "$SITE_DIR" .
Однако исключать нужно осторожно.
Например, uploads/ часто содержит пользовательские файлы и поэтому является критически важной частью backup.
Перед настройкой исключений полезно разделить данные на категории:
| Каталог | Backup |
|---|---|
uploads/ | Да |
config/ | Да |
| исходный код | Да |
.git/ | Обычно нет |
| cache | Обычно нет |
| temporary files | Нет |
| логи | По необходимости |
node_modules/ | Обычно нет |
Главное правило: не исключайте каталог только потому, что он кажется большим. Сначала убедитесь, что его можно полностью восстановить из другого источника.
Защита backup от удаления злоумышленником
Если сервер будет взломан, злоумышленник потенциально может получить доступ и к credentials для backup.
Тогда сценарий может выглядеть так:
Атака на сервер
↓
получение credentials
↓
удаление сайта
↓
удаление backup
Поэтому credentials должны быть ограничены.
Для S3 желательно:
- отдельный bucket;
- отдельный IAM user/role;
- минимальные права;
- запрет публичного доступа;
- versioning;
- lifecycle;
- отдельные credentials для разных проектов;
- по возможности дополнительная защита удаления.
Для критически важных систем полезно применять несвязанные между собой уровни хранения.
Например:
Production server
│
├──────────► S3 backup
│
└──────────► второй backup
│
└── отдельная учётная запись
Правило 3-2-1
Для важных сайтов стоит ориентироваться на классическое правило 3-2-1:
3 копии данных
2 разных типа/носителя
1 копия — вне основного сервера
Например:
Основной сайт
│
├── локальный backup
│
├── S3
│
└── второй независимый storage
Для особенно критичных проектов можно пойти дальше и использовать:
3-2-1-1-0
где дополнительные элементы означают наличие offline/immutable-копии и отсутствие ошибок после проверки backup.
Самая важная часть: тест восстановления
Backup, который никогда не проверяли восстановлением, нельзя считать надёжным.
Представим:
backup.sh → SUCCESS
Но внутри:
database.sql.gz → 0 bytes
или:
archive.tar.gz → повреждён
Формально скрипт мог закончиться без ошибок, но восстановить сайт будет невозможно.
Поэтому периодически нужно выполнять тестовый restore.
Например:
mkdir /tmp/restore-test
tar -xzf site-backup.tar.gz \
-C /tmp/restore-test
Для базы:
gunzip database.sql.gz
После этого можно импортировать её в тестовую БД:
mysql restore_test < database.sql
И проверить:
✓ архив распаковывается
✓ все необходимые файлы присутствуют
✓ SQL импортируется
✓ сайт запускается
✓ подключения к БД работают
✓ пользовательские файлы доступны
Это уже полноценная проверка disaster recovery.
Пример production-сценария
Допустим, у веб-студии есть 30 сайтов клиентов.
Для каждого сайта используется:
/var/www/client-a.ru
/var/www/client-b.ru
/var/www/client-c.ru
Backup запускается каждую ночь:
03:00
↓
создать DB dump
↓
создать архив файлов
↓
проверить архив
↓
создать SHA-256
↓
загрузить в S3
↓
проверить наличие объектов
↓
удалить локальные копии старше 3 дней
В S3:
backups/
├── client-a.ru/
│ ├── 2026-08-24/
│ ├── 2026-08-25/
│ └── 2026-08-26/
│
├── client-b.ru/
│ ├── 2026-08-24/
│ ├── 2026-08-25/
│ └── 2026-08-26/
│
└── client-c.ru/
├── 2026-08-24/
├── 2026-08-25/
└── 2026-08-26/
Такую структуру гораздо проще обслуживать, чем набор файлов:
backup1.tar.gz
backup2.tar.gz
backup3.tar.gz
...
Ежедневные и еженедельные backup
Можно использовать разные политики.
Например:
Ежедневно:
7 копий
Еженедельно:
4 копии
Ежемесячно:
12 копий
В результате:
2026-08-26 daily
2026-08-25 daily
2026-08-24 daily
...
2026-W34 weekly
2026-W33 weekly
2026-W32 weekly
...
2026-08 monthly
2026-07 monthly
2026-06 monthly
...
Это называется retention policy — политика хранения резервных копий.
Она позволяет не хранить бесконечное количество файлов и одновременно иметь возможность восстановиться не только из вчерашнего состояния.
Что делать при восстановлении сайта
Хороший backup-скрипт должен иметь обратную процедуру.
Например:
1. Создать новый сервер
↓
2. Установить веб-сервер
↓
3. Получить backup из S3
↓
4. Распаковать файлы
↓
5. Создать БД
↓
6. Импортировать SQL
↓
7. Настроить config
↓
8. Проверить сайт
↓
9. Переключить DNS
Получается, что backup — это не просто команда:
tar -czf backup.tar.gz ...
Это часть более широкой процедуры disaster recovery.
Типичные ошибки
1. Backup хранится на том же сервере
Server
├── website
└── backup
При полном отказе сервера теряется всё.
Лучше:
Server ─────► Cloud storage
2. Сохраняются только файлы
Без БД сайт может быть фактически бесполезен.
Всегда определяйте полный состав данных, необходимых для восстановления.
3. Сохраняется только база
Обратная ситуация: БД есть, но отсутствуют:
uploads/
images/
documents/
config/
Результат — неполный сайт.
4. Backup создаётся, но не проверяется
Добавьте:
tar -tzf backup.tar.gz > /dev/null
и проверку размера файлов.
5. Нет тестового восстановления
Хотя бы раз в несколько месяцев выполняйте restore на тестовом сервере.
6. Credentials имеют слишком много прав
Не используйте административный ключ для backup.
Принцип:
backup script
↓
минимальные права
7. Используется --delete без понимания последствий
Для обычной синхронизации:
aws s3 sync site/ s3://bucket/site/ --delete
может быть вполне уместно.
Для исторических backup это может быть опасно.
Сначала определите, нужна ли вам синхронизация текущего состояния или набор независимых снимков.
Что выбрать веб-студии
Если задача — просто защитить небольшой сайт клиента, можно использовать:
cron
↓
Bash
↓
tar + mysqldump
↓
Яндекс Диск / S3
Если веб-студия обслуживает десятки или сотни проектов, лучше сразу строить более системную архитектуру:
┌── S3
│
Sites ──► Backup ───┼── monitoring
│
└── logs
│
▼
notifications
При этом желательно централизовать:
- расписание;
- retention;
- credentials;
- логи;
- уведомления;
- контроль успешности;
- тестовое восстановление.
Практический минимальный стандарт
Для обычного корпоративного сайта можно принять следующий стандарт:
Каждый день:
✓ backup файлов
✓ backup базы
✓ gzip
✓ SHA-256
✓ загрузка в отдельное облако
✓ проверка результата
Хранение:
7 ежедневных копий
4 недельных
12 месячных
Безопасность:
✓ отдельные credentials
✓ минимальные права
✓ приватное хранилище
✓ HTTPS
✓ отсутствие секретов в Git
Контроль:
✓ логирование
✓ уведомление об ошибке
✓ периодический restore
Итог
Автоматическое резервное копирование сайта можно реализовать достаточно простым набором инструментов:
cron
+
Bash/Python
+
tar
+
mysqldump
+
S3 / Яндекс Диск
Но надёжная система backup — это не просто загрузка .tar.gz в облако.
Правильная схема должна учитывать:
- что именно копируется — файлы и база;
- куда копируется — отдельно от production-сервера;
- как часто — в соответствии с допустимой потерей данных;
- сколько хранится — retention policy;
- как защищены credentials;
- как проверяется целостность;
- как выполняется восстановление.
Для большинства production-сценариев S3 или S3-compatible storage удобнее благодаря объектной модели, versioning и lifecycle-механизмам. S3 Versioning позволяет сохранять предыдущие версии объектов, а Lifecycle — автоматически управлять их хранением и удалением.
Яндекс Диск может быть удобным вариантом для небольших проектов, особенно если инфраструктура уже построена вокруг Яндекс 360. Для автоматизации следует учитывать доступные API и актуальные условия WebDAV; документация Яндекса указывает, что с 22 июня 2026 года WebDAV требует тариф Яндекс 360.
Главный принцип: резервная копия считается созданной не тогда, когда скрипт написал Backup completed, а тогда, когда из неё действительно можно восстановить работающий сайт.
Для веб-студии это особенно важно: автоматизированный backup снижает риск простоя, защищает данные клиентов и превращает восстановление после аварии из экстренной ручной операции в понятную техническую процедуру.
