Дата публикации: 24.04.2026

Подготовка файловой структуры сервера для удобного хранения проектов

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

Вы когда-нибудь заходили в чулан, где всё свалено в кучу: инструменты лежат рядом с рождественскими гирляндами, документы перемешаны с обувью, а найти нужную вещь можно только после часа раскопок? Так же выглядит сервер без продуманной файловой структуры — только вместо гирлянды у вас базы данных, вместо обуви — бэкапы, а вместо инструментов — конфиги NGINX.

Проблема: Без системы хранения вы тратите время на поиск файлов, рискуете случайно удалить важное, а при взломе сервера злоумышленник получит доступ ко ВСЕМ вашим проектам сразу.

Решение: Чёткая иерархия папок, права доступа и изоляция проектов. Сегодня вы научитесь организовывать сервер так, чтобы: ✅ Каждый проект жил в своём "контейнере" (без риска пересечения данных). ✅ Бэкапы и логи не мешались под ногами (и не занимали место на системном диске). ✅ Даже если один сайт взломают, остальные останутся в безопасности.

1. Основные принципы организации файлов на сервере

Прежде чем лепить папки наугад, запомните 4 правила, которые спасут вас от хаоса:

Принцип	Почему это важно	Пример нарушения
Изоляция проектов	Один уязвимый сайт не должен компрометировать другие.	Все сайты в `/var/www/html/` без разделения.
Разделение по типам	Логи, бэкапы и исходники не должны лежать вместе.	Бэкапы базы данных в папке с картинками сайта.
Минимальные права	Файлы должны быть доступны только тем, кому действительно нужно.	`chmod 777` для всех папок.
Документирование	Через полгода вы забудете, зачем создавали папку `/tmp/old_stuff_2023`.	Папки с названиями `new`, `test`, `backup1`.

Аналогия: Представьте сервер как многоквартирный дом.

Изоляция = у каждой семьи отдельная квартира (проект).

Разделение = кухня (логи), кладовая (бэкапы) и гостиная (исходники) не смешаны.

Права = соседи не могут зайти к вам без ключа (chmod).

Документация = на дверях висят таблички с именами жильцов (README в папках).

2. Стандартная структура папок: что и где должно лежать

В Linux нет жёстких правил, но есть устоявшиеся практики, которые используют системные администраторы. Вот базовая схема для веб-сервера:

/
├── **home/**               # Личные папки пользователей (не для проектов!)
├── **var/**
│   ├── **www/**            # Корневая директория для веб-проектов
│   │   ├── **project1.com/** # Папка проекта (домен = название)
│   │   │   ├── **public/**  # Публичные файлы (HTML, CSS, JS)
│   │   │   ├── **private/** # Закрытые файлы (конфиги, скрипты)
│   │   │   └── **logs/**    # Логи проекта (отдельно от системных)
│   │   └── **project2.com/** # Другой проект — отдельная папка
│   ├── **log/**            # Системные логи (NGINX, PHP, MySQL)
│   ├── **backups/**        # Бэкапы (лучше на отдельном диске!)
│   └── **tmp/**            # Временные файлы (очищаются автоматически)
├── **etc/**                # Конфигурационные файлы (NGINX, PHP, MySQL)
└── **opt/**                # Дополнительное ПО (например, Composer, Node.js)

Почему именно так?

/var/www/ — стандарт для веб-проектов. Здесь хранятся только файлы сайтов.
public/ внутри проекта — защищает закрытые данные (например, конфиги базы данных не будут доступны по URL).
Логи и бэкапы вне /var/www/ — если сайт взломают, злоумышленник не получит доступ к логам или резервным копиям.
/opt/ для софта — удобно обновлять ПО, не затрагивая системные файлы.

Важно: Не храните проекты в /home/ваш_пользователь/! Это для личных файлов, а не для веб-сайтов.

3. Права доступа: кто и что может делать с файлами

Представьте, что вы дали ключи от квартиры всем соседам, а потом удивились, что пропал ноутбук. Так же работают права доступа на сервере — если выставить 777, любой процесс (включая вредоносный) сможет изменить ваши файлы.

Базовые команды для управления правами

Команда	Что делает	Пример
`chmod 755 папка`	Владелец: полный доступ. Остальные: чтение + выполнение (но не запись!).	Для папок с публичными файлами.
`chmod 644 файл`	Владелец: чтение/запись. Остальные: только чтение.	Для PHP-скриптов, HTML-файлов.
`chown пользователь:группа файл`	Меняет владельца файла.	`chown www-data:www-data index.php`
`chmod 600 конфиг`	Только владелец может читать/изменять (для чувствительных данных).	Для `.env`, конфигов базы данных.

Кто такой `www-data` и почему он важен?

В большинстве веб-серверов (NGINX, Apache) процессы выполняются от имени пользователя www-data. Это значит:

Файлы, к которым обращается сайт (PHP-скрипты, картинки), должны быть доступны этому пользователю.
Никогда не давайте www-data права на запись в конфиги или системные папки!

Практический совет:
Для папки /var/www/project1.com/public/:
sudo chown -R www-data:www-data /var/www/project1.com/public/
sudo chmod -R 755 /var/www/project1.com/public/
Для закрытых файлов (например, /var/www/project1.com/private/config.db):
sudo chmod 600 /var/www/project1.com/private/config.db

4. Изоляция проектов: как защититься от "эффекта домино"

Если все сайты лежат в одной купчи, взлом одного проекта даёт доступ ко всем остальным. Решение: изолировать каждый проект как отдельного пользователя.

Способ 1: Разные пользователи для разных проектов

Создайте нового пользователя для проекта:
```
sudo adduser project1_user
```
Назначьте его владельцем папки проекта:
```
sudo chown -R project1_user:www-data /var/www/project1.com/
```
Запретите доступ другим пользователям:
```
sudo chmod -R 750 /var/www/project1.com/
```

Способ 2: Docker-контейнеры (для продвинутых)

Если вы используете Docker, каждый проект живёт в своём контейнере с изолированной файловой системой. Пример docker-compose.yml:

version: '3'
services:
  web:
    image: nginx:alpine
    volumes:
      - ./project1.com/public:/usr/share/nginx/html
      - ./project1.com/private:/etc/nginx/conf.d
    ports:
      - "80:80"

Плюсы Docker:

Полная изоляция (даже если взломают один контейнер, другие не пострадают).

Лёгкое масштабирование.

Возможность быстро переносить проекты между серверами.

Минусы:

Сложнее в настройке для новичков.

Требует дополнительных ресурсов сервера.

5. Бэкапы и логи: где хранить и как не захламлять сервер

Где хранить бэкапы?

❌ Неправильно: В той же папке, что и проект (/var/www/project1.com/backups/). ✅ Правильно:

На отдельном диске (например, /mnt/backups/).
В облачном хранилище (AWS S3, Backblaze B2).
На другом сервере (через rsync).

Пример команды для бэкапа базы данных MySQL:
mysqldump -u пользователь -pпароль база_данных > /mnt/backups/project1_db_$(date +%F).sql

Как управлять логами?

Логи могут забить диск за несколько дней. Решение:

Ротация логов (автоматическое архивирование и удаление старых логов):

sudo apt install logrotate

Конфиг для NGINX (/etc/logrotate.d/nginx):

/var/log/nginx/*.log {
   daily
   missingok
   rotate 14
   compress
   delaycompress
   notifempty
   create 0640 www-data adm
   sharedscripts
   postrotate
       systemctl reload nginx
   endscript
}

Отдельные логи для каждого проекта:

# В конфиге NGINX для project1.com
access_log /var/log/nginx/project1_access.log;
error_log /var/log/nginx/project1_error.log;

6. Документирование: как не забыть, зачем вы создали ту или иную папку

Через месяц вы забудете, почему папка /var/www/old_stuff_2023/ занимает 10 ГБ. Решение: ведите README-файлы в каждой важной директории.

Пример README.md для проекта:

# Project1.com - Лендинг для курса по арбитражу

## Структура папок:
- `/public/` - Публичные файлы (HTML, CSS, JS).
- `/private/` - Закрытые скрипты и конфиги.
- `/logs/` - Логи NGINX и PHP (ротируются раз в неделю).

## Важные заметки:
- Бэкапы базы данных хранятся в `/mnt/backups/project1_db_*`.
- Доступ по SSH только с ключом (пароль отключён).
- Конфиг NGINX: `/etc/nginx/sites-available/project1.com`

## Контакты:
- Админ: admin@example.com
- Хостинг: DigitalOcean, IP 123.123.123.123

Совет: Используйте комментарии в конфигах (например, в NGINX или MySQL), чтобы объяснять неочевидные настройки.

Практика для закрепления

Упражнение 1: Структура папок

Создайте файловую структуру для двух проектов (arbitrage-tool.com и landing-page.com) по образцу из урока. Используйте команды:

sudo mkdir -p /var/www/arbitrage-tool.com/{public,private,logs}
sudo mkdir -p /var/www/landing-page.com/{public,private,logs}

Вопрос: Почему папка private должна быть отдельно от public?

Упражнение 2: Права доступа

Выставите правильные права для:

Папки /var/www/arbitrage-tool.com/public/ (доступ на чтение для всех, запись — только для владельца).
Файла /var/www/arbitrage-tool.com/private/config.db (доступ только для владельца).

Вопрос: Какую команду вы используете, чтобы проверить текущие права файла?

Упражнение 3: Изоляция проектов

Создайте нового пользователя landing_user и сделайте его владельцем папки /var/www/landing-page.com/. Запретите доступ другим пользователям.

Вопрос: Какой командой вы проверите, что права выставлены правильно?

Упражнение 4: Бэкапы

Напишите команду для создания бэкапа базы данных arbitrage_db и сохранения его в /mnt/backups/ с именем arbitrage_db_YYYY-MM-DD.sql.

Вопрос: Почему не рекомендуется хранить бэкапы в /var/www/?

Упражнение 5: Документирование

Создайте файл README.md в папке /var/www/arbitrage-tool.com/ с описанием:

Назначения проекта.
Структуры папок.
Контактов администратора.

Вопрос: Какие ещё важные данные стоит указать в README для серверных проектов?

Итоги урока

Изоляция = безопасность. Каждый проект должен жить в своём "контейнере" (папке, пользователе или Docker-контейнере).
Права доступа = замки на дверях. chmod 777 — как оставить дверь открытой с табличкой "Берите всё".
Бэкапы и логи = страховка. Храните их отдельно от проектов и настраивайте ротацию.
Документация = память. Через полгода вы сами себе скажете спасибо за README.

Домашнее задание:

Организуйте файловую структуру на своём сервере (или локальной машине) по приведённому шаблону.
Настройте автоматическую ротацию логов для NGINX.
Создайте скрипт для ежедневного бэкапа базы данных (можно использовать cron).

Бонус: Если используете Docker, попробуйте "заdockerить" один из своих проектов для полной изоляции.

Вопросы? Пишите в комментариях — разберём сложные моменты! 🚀

Введение: чем VDS отличается от шаред-хостинга и зачем это веб-мастеру
Как правильно выбрать тариф: CPU, RAM, NVMe или SSD, канал
Выбор операционной системы: почему Ubuntu 22.04/24.04 — стандарт индустрии
Регистрация домена и первичная настройка DNS-записей (A, AAAA, CNAME)
Генерация SSH-ключей на локальном компьютере (Windows/Mac/Linux)
Добавление публичного ключа на сервер и первый вход по SSH
Отключение входа по паролю и запрет авторизации для root
Смена стандартного порта SSH для снижения шума в логах
Создание основного рабочего пользователя с правами sudo
Базовое обновление системы и установка необходимых утилит (curl, wget, git, htop)
Настройка часового пояса и синхронизация времени (NTP)
Установка и базовая настройка фаервола UFW
Разрешение только необходимых портов (SSH, HTTP, HTTPS)
Установка Fail2Ban для защиты от перебора паролей
Настройка правил Fail2Ban для SSH и веб-сервера
Знакомство с Docker: установка движка и CLI
Установка Docker Compose для управления мульти-контейнерными приложениями
Основы изоляции: почему каждый проект должен быть в своем контейнере
Подготовка файловой структуры сервера для удобного хранения проектов
Развертывание Nginx как обратного прокси-сервера через Docker
Настройка конфигурации Nginx для статических сайтов
Установка PHP-FPM в отдельном контейнере
Связка Nginx и PHP-FPM через внутреннюю Docker-сеть
Оптимизация настроек PHP-FPM (pm.max_children, memory_limit) под нагрузку
Установка MariaDB/MySQL в изолированном контейнере
Безопасное хранение паролей от БД через переменные окружения (.env)
Подключение к базе данных из внешнего клиента (DBeaver/Navicat) через туннель
Установка Redis для кэширования запросов и сессий
Интеграция Redis с PHP-приложением для ускорения работы
Автоматическая выдача SSL-сертификатов через Certbot (Let's Encrypt)
Настройка автопродления SSL-сертификатов по крону
Принудительный редирект с HTTP на HTTPS в Nginx
Включение gzip и brotli сжатия для ускорения загрузки страниц
Настройка кэширования статики (browser caching) в заголовках Nginx
Защита от простых DDoS и ботов: модуль limit_req в Nginx
Настройка резервного копирования баз данных (mysqldump) по расписанию
Настройка резервного копирования файлов проектов (tar)
Отправка бэкапов на удаленное хранилище (S3-compatible storage или другой сервер)
Ротация и очистка старых логов, чтобы не забить диск
Мониторинг нагрузки: установка и настройка htop и iotop
Просмотр логов в реальном времени: tail, grep и journalctl
Установка простого мониторинга доступности (Uptime Kuma или скрипт в Telegram)
Изоляция арбитражных инструментов: запуск ботов в отдельных контейнерах
Установка SOCKS5/HTTP прокси (3proxy) внутри Docker для мультиаккаунтинга
Настройка аутентификации и ограничения доступа к прокси по IP
Проверка анонимности и работы прокси-сервера
Оптимизация ядра Linux (sysctl.conf) для высоких нагрузок и сетевых соединений
Настройка swap-файла: когда он нужен, а когда вредит
Чек-лист финальной проверки безопасности перед запуском проекта
План действий при взломе или падении сервера: восстановление из бэкапа
АПТЕЧКА ДЛЯ ЖИВОТНЫХ
Автомобили Германии — FORD, MERSEDES, VW, IVECO
Чат рулетка 2026: чаты, где каждый момент — шанс
Чат рулетка онлайн
Чат с Аней: психологический разговор
Чатрулетка: новый способ общения
Чай и кофе: сила вкуса
Детские игрушки из безопасных материалов
Эксплуатация шин: Рекомендации по использованию
Фототехника для пейзажей
Как Aptum хостинг помогает малым бизнесам в управлении CRM-системами
Как выбрать Vdsina вечный хостинг для своего проекта
Компоненты безопасности IP
Конкуренция на российском автомобильном рынке
Онлайн генератор паролей для Windows
Оптимизация обработки форм GEO проекта
Сервер для социальных сетей: Безопасность, Скорость, Изоляция
Смешные моменты
Сравнение Arsys хостинг сервисов для блогеров с WordPress на 2023 год
Весь экран под циферблат