Дата публикации: 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ить" один из своих проектов для полной изоляции.

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

Генератор паролей с длинной 64 символа
Женская одежда с бахромой
Кадастровые работы в Бийске
Как Aptum хостинг помогает малым бизнесам в управлении CRM-системами
Как выбрать планировку сайта для блогов на DreamHost
Как выбрать Vdsina вечный хостинг для своего проекта
Казань окна VEKA - профессионализм и опыт
Курьерская вода
Новостройки Оренбурга: недвижимость с отличной ценой
Онлайн чат-партнерство
Пиломатериалы для возведения бани
Почему VDSina — лучший выбор хостинга
Секреты Вконтакте: тонкости и хитрости
Скидки до 50% на тур в Коста-Рике
Видеочат рулетка бесплатно