ROLLBACK POLICY

1. ПЕРЕД ИЗМЕНЕНИЕМ
   → Создать контрольную точку (backup)
   → Запомнить состояние: "это работает"

2. ДЕЛАТЬ ИЗМЕНЕНИЕ
   → Одно изменение за раз
   → Проверка после каждого шага

3. ЕСЛИ СЛОМАЛОСЬ
   → СТОП! Не пытаться починить
   → Откат к контрольной точке
   → Повторить с другим подходом

4. НИКОГДА
   → Не менять ядро (Drupal core, Laravel core, etc.)
   → Не накручивать fix поверх fix
   → Не продолжать если не работает

Формат: {тип}_{дата}_{время}_{статус}.{ext}

drupal-vanilla-20260210-110019.tar.gz       ← L3: Чистая установка
modules-before-deploy-20260213-143022.tar.gz ← L1: Перед деплоем
db-before-migration-20260213-143505.sql.gz   ← L2: Перед миграцией БД

БЫЛО:
1. Пытались установить модули → ошибка
2. Пытались починить core → сломали ещё больше
3. Пытались workaround → не помогло

ПРАВИЛЬНО:
1. СТОП! Откат к vanilla
2. Восстановить чистое ядро
3. Установить модули заново
4. Если не работает → искать причину в модулях, НЕ в ядре

ПЕРЕД началом:
  ✓ Есть ванилла (чистая установка)?
  ✓ Есть backup текущего состояния?
  ✓ Знаем как откатиться?

ЕСЛИ что-то пошло не так:
  1. ОТКАТ к последней рабочей точке
  2. Проверка: "это работает?"
  3. Повторить изменение по-другому

НЕ ДЕЛАТЬ:
  ✗ Править ядро фреймворка
  ✗ "Починить" vendor/ файлы
  ✗ Накручивать костыли

ДИАГНОСТИКА:
1. Это точно ядро сломано?
   → Проверить на vanilla
2. Ядро из коробки работает?
   → Да: проблема в наших изменениях
   → Нет: проблема в установке

ЕСЛИ ЯДРО СЛОМАНО:
→ Откат к vanilla
→ НЕ ЧИНИТЬ на месте!

1. Создать backup (L1 + L2)
2. Деплой
3. Проверка работоспособности
4. Если сломалось:
   → Откат к backup
   → НЕ пытаться чинить на prod

{project}/
├── arh/                    ← L1: Архив модулей
│   ├── modules/
│   │   └── 2026-02-13-143022/
│   └── sql/                ← L2: Дампы БД
│       └── 2026-02-13-143505.sql.gz

~/
├── vanilla-{date}.tar.gz              ← L3: Чистая установка
├── backups/                            ← L2: Текущие backup
│   ├── before_deploy_{timestamp}.tar.gz
│   └── db_{timestamp}.sql.gz

$INFRA/backups/
├── {project}/
│   └── {YYYY-MM}/
│       ├── vanilla-20260210.tar.gz    ← L3
│       └── weekly-20260213.tar.gz     ← L4

#!/bin/bash
# deploy/backup.sh

TIMESTAMP=$(date +%Y%m%d_%H%M%S)

echo "Создание backup..."
tar -czf "arh/modules/$TIMESTAMP.tar.gz" dev/modules/
mysqldump db_name | gzip > "arh/sql/$TIMESTAMP.sql.gz"
echo "✓ Backup: $TIMESTAMP"

#!/bin/bash
# deploy/rollback.sh

BACKUP_ID=$1  # 20260213_143022

echo "Откат к $BACKUP_ID..."
tar -xzf "arh/modules/$BACKUP_ID.tar.gz" -C dev/
gunzip < "arh/sql/$BACKUP_ID.sql.gz" | mysql db_name
echo "✓ Откат выполнен"

## Backup {timestamp}

**Что:** Перед деплоем модулей Drupal
**Состояние:** Ванилла Drupal 11.3.3 + locale + commerce
**Работает:** ✓ Сайт доступен, админка работает

**Откат:**
```bash
cd ~/
tar -xzf drupal-vanilla-20260210.tar.gz -C new.site.ru/
gunzip -c drupal-vanilla.sql.gz | mysql db_name