Системный администратор: Ассистент с нейросетью онлайн

Решение: ежедневный бэкап через cron + tar ✅

Ниже — простой и надежный вариант: каждый день в 02:00 архивируем /var/www в /backup и удаляем копии старше 7 дней.

1) Создайте каталог для бэкапов

sudo mkdir -p /backup
sudo chmod 700 /backup

Если бэкап будет запускаться от root, этого достаточно.

2) Создайте скрипт бэкапа

Например, /usr/local/bin/backup_www.sh:

sudo nano /usr/local/bin/backup_www.sh

Вставьте:

#!/bin/bash
set -e

SRC="/var/www"
DEST="/backup"
DATE="$(date +%F_%H-%M-%S)"
HOST="$(hostname -s)"
ARCHIVE="$DEST/www_${HOST}_${DATE}.tar.gz"
LOGFILE="$DEST/backup.log"

mkdir -p "$DEST"

tar -czf "$ARCHIVE" "$SRC"

echo "[$(date '+%F %T')] Backup created: $ARCHIVE" >> "$LOGFILE"

find "$DEST" -maxdepth 1 -type f -name "www_${HOST}_*.tar.gz" -mtime +7 -delete
echo "[$(date '+%F %T')] Old backups older than 7 days removed" >> "$LOGFILE"

Сделайте его исполняемым:

sudo chmod +x /usr/local/bin/backup_www.sh

3) Проверьте скрипт вручную

sudo /usr/local/bin/backup_www.sh

Проверьте, что архив появился:

ls -lh /backup

4) Добавьте задачу в cron

Откройте crontab для root:

sudo crontab -e

Добавьте строку:

0 2 * * * /usr/local/bin/backup_www.sh

Это означает:

• 0 — минута
• 2 — час
• * * * — каждый день, каждый месяц, любой день недели

5) Как убедиться, что всё работает

Проверьте лог:

tail -n 20 /backup/backup.log

Посмотрите задания cron:

sudo crontab -l

Полезные улучшения

Исключить лишние файлы

Если в /var/www есть временные данные, можно исключить их через tar --exclude, например:

tar -czf "$ARCHIVE" --exclude='*/cache/*' "$SRC"

Делать бэкап не всего каталога, а только сайта

Например:

SRC="/var/www/example.com"

Важное замечание ⚠️

Этот вариант хранит архивы 7 дней, но не проверяет целостность бэкапа и не шифрует его.
Если данные важные, лучше дополнительно:

• хранить копии на другом сервере/диске;
• использовать rsync или borgbackup;
• периодически тестировать восстановление.

Если хотите, могу сразу дать вариант через systemd timer или с отправкой бэкапа на удалённый сервер по SSH.

Настройка SSH-доступа по ключам 🔐

Ниже — безопасный вариант для отдельного пользователя: вход только по SSH-ключу, без пароля, и ограничение в домашней директории.

1) Создайте пользователя

sudo adduser deploy

Если нужен доступ только к определенной папке, заранее подготовьте каталог:

sudo mkdir -p /home/deploy/www
sudo chown -R deploy:deploy /home/deploy

2) Добавьте SSH-ключ

На своей рабочей машине сгенерируйте ключ, если его еще нет:

ssh-keygen -t ed25519

Скопируйте публичный ключ на сервер:

ssh-copy-id deploy@server_ip

Если ssh-copy-id недоступен, добавьте ключ вручную:

sudo -u deploy mkdir -p /home/deploy/.ssh
sudo -u deploy nano /home/deploy/.ssh/authorized_keys

Права должны быть строгими:

sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh

3) Ограничьте пользователя в sshd

Откройте конфиг:

sudo nano /etc/ssh/sshd_config

Проверьте или добавьте параметры:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

В конец файла добавьте блок для пользователя:

Match User deploy
    ChrootDirectory /home/deploy
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTcpForwarding no

Важно

• ChrootDirectory должен принадлежать root, а не пользователю.
• Внутри него можно оставить отдельную папку для работы.

Исправьте права на корень chroot:

sudo chown root:root /home/deploy
sudo chmod 755 /home/deploy
sudo mkdir -p /home/deploy/www
sudo chown deploy:deploy /home/deploy/www

4) Проверьте конфиг и перезапустите SSH

Сначала проверьте синтаксис:

sudo sshd -t

Если ошибок нет, примените настройки:

sudo systemctl restart ssh

5) Проверьте вход

Подключение:

ssh deploy@server_ip

Если настроен ForceCommand internal-sftp, обычный shell не откроется — это нормально. Для SFTP:

sftp deploy@server_ip

Что получится

• парольный вход для deploy отключен;
• подключение работает только по ключу;
• пользователь не сможет выйти за пределы /home/deploy;
• доступ можно использовать для безопасной загрузки файлов.

Если нужен именно shell-доступ

Тогда не используйте ForceCommand internal-sftp. Вместо этого можно:

• оставить вход по ключам;
• ограничить команды через sudoers;
• или настроить rbash/контейнер, если нужен более жесткий контроль.

Если хотите, могу сразу дать вариант:

1. только SFTP-доступ;
2. shell-доступ, но без прав root;
3. доступ к одной папке через sudo и rsync.

Что проверить в первую очередь 🔎

Обычно проблема в одном из трех мест:

1. Права на общий ресурс
2. Права NTFS на саму папку
3. Кэшированные учетные данные или сломанная SMB-сессия

Начните с быстрой диагностики на сервере и на клиенте.

1) Проверка на сервере

Убедитесь, что шарa реально доступна

На сервере откройте PowerShell от администратора:

Get-SmbShare
Get-SmbShareAccess -Name share

Проверьте:

• есть ли нужная шара share
• есть ли у группы пользователей Read или Change
• не остались ли слишком жесткие ограничения только на Administrators

Проверьте NTFS-права

Даже если доступ есть на уровне шары, NTFS может его блокировать:

icacls "D:\Shares\share"

Нужно, чтобы у нужной группы были права хотя бы:

• RX — чтение
• M — изменение, если нужен запись/удаление

Если права сломаны, можно выдать их, например, группе домена:

icacls "D:\Shares\share" /grant "DOMAIN\Users:(OI)(CI)M"

2) Проверка с клиентского ПК

Сбросьте старые подключения

Иногда Windows цепляется к старым учетным данным:

net use * /delete /y

После этого попробуйте подключиться заново:

net use \\fileserver\share

Если логин нужен явно:

net use \\fileserver\share /user:DOMAIN\username

Очистите сохраненные пароли

Откройте Диспетчер учетных данных:

• Панель управления
• Диспетчер учетных данных
• Учетные данные Windows

Удалите записи, связанные с:

• fileserver
• именем сервера
• IP-адресом сервера

3) Проверьте домен и время

Если время на клиенте и сервере сильно отличается, доменная авторизация может ломаться.

На клиенте:

w32tm /query /status

На сервере:

w32tm /query /status

Если есть расхождение, синхронизируйте:

w32tm /resync

4) Посмотрите журнал событий

На сервере откройте:

• Event Viewer
• Windows Logs -> Security
• Windows Logs -> System

Ищите ошибки по:

• SMB
• отказам входа
• проблемам Kerberos/NTLM
• событиям доступа к файлам

Часто полезны события:

• 4625 — неудачный вход
• 5140 — доступ к сетевому ресурсу
• 1058 / 1053 — если проблема связана с политиками или доменом

5) Если это доменная среда

Проверьте:

• сервер состоит в домене
• DNS у клиента указывает на контроллер домена, а не на внешний DNS
• имя fileserver корректно резолвится

Проверка:

nslookup fileserver
ping fileserver

Если DNS неверный, клиент может пытаться подключаться не туда или авторизоваться не тем способом.

6) Типичный рабочий сценарий исправления

Если нужно быстро восстановить доступ:

# На сервере
Get-SmbShareAccess -Name share
icacls "D:\Shares\share"

# На клиенте
net use * /delete /y
cmdkey /list

Потом:

1. удалить сохраненные учетные данные,
2. проверить права на шаре и NTFS,
3. заново подключиться под доменной учеткой,
4. убедиться, что время и DNS в порядке.

7) Хорошая практика на будущее

Чтобы таких проблем было меньше:

• давайте права через группы, а не отдельным пользователям
• отдельно контролируйте:
  • Share permissions
  • NTFS permissions
• документируйте, кто имеет доступ к какой папке
• не смешивайте старые локальные учетные записи и доменные, если это возможно

Если хотите, я могу сразу дать готовый чек-лист для проверки сетевой шары в Windows Server 2019 по шагам с командами.