F.A.Q.Wiki

Как пра­вило, пос­ле заказа сер­вера тебе сооб­щают его IP-адрес и пароль поль­зовате­ля. При­чем он прек­расно виден в панели управле­ния вир­туаль­ным сер­вером. Про­вай­дер, если он сге­нери­ровал этот пароль, его зна­ет и хра­нит в базе дан­ных — ведь его где‑то записа­ли, что­бы показы­вать тебе каж­дый раз в панели управле­ния.

К тому же пароли от сер­вера обыч­но генери­руют­ся слу­чай­ным обра­зом и слож­ны для под­бора, а вот пароли, отоб­ража­емые в панели управле­ния, не всег­да соот­ветс­тву­ют этим тре­бова­ниям. Поэто­му пер­вым делом меня­ем пароль root. Счи­тай это не параной­ей, а прос­той пре­дос­торож­ностью. Не забывай менять пароль каж­дые два‑три месяца — так­же из сооб­ражений безопас­ности. Зай­ди по SSH как root и вве­ди коман­ду

passwd

Да, при вво­де сим­волы не отоб­ража­ются — нет ни букв, ни цифр, ни звез­дочек, это нор­маль­но. Вве­ди новый пароль и наж­ми Enter. На пер­вом эта­пе мы себя обе­зопа­сили и можем прис­тупить к нас­трой­ке.

Су­щес­тву­ет нес­коль­ко стра­тегий защиты учет­ной записи root. Пер­вая зак­люча­ется в сле­дующем: ты соз­даешь учет­ку поль­зовате­ля с извес­тным толь­ко тебе име­нем, пре­дос­тавля­ешь ей воз­можность исполь­зовать коман­ду sudo (что­бы ты мог редак­тировать фай­лы кон­фигура­ции и уста­нав­ливать софт), а затем отклю­чаешь вход для root по SSH. На выходе получа­ем пароль­ную аутен­тифика­цию, но будет исполь­зовать­ся учет­ная запись, имя которой извес­тно лишь тебе. Пре­иму­щес­тва сле­дующие: ник­то не взло­мает учет­ку root, пос­коль­ку она будет вык­лючена. Недос­таток пря­чет­ся в сло­ве «пароль­ная».

Са­ма по себе пароль­ная аутен­тифика­ция не так надеж­на, как аутен­тифика­ция по пуб­лично­му клю­чу. Вто­рая стра­тегия как раз и зак­люча­ется в исполь­зовании такой аутен­тифика­ции. Недос­таток — более слож­ная нас­трой­ка, преж­де все­го для конеч­ных поль­зовате­лей: при­дет­ся генери­ровать пару клю­чей, и для челове­ка, который никог­да это­го не делал, понача­лу это может показать­ся слож­ным. Но, как пра­вило, на арен­дован­ном VDS мало кто соз­дает мно­го учет­ных записей для вхо­да по SSH — обыч­но исполь­зует­ся одна‑две учет­ки, если адми­нов нес­коль­ко. Пре­иму­щес­тва аутен­тифика­ции по пуб­лично­му клю­чу — ник­то не смо­жет подоб­рать пароль и, сле­дова­тель­но, получить дос­туп к тво­ему сер­веру. Если ты будешь исполь­зовать аутен­тифика­цию по клю­чу, сме­ло про­пус­кай пун­кты 2 и 4 — не нуж­но соз­давать допол­нитель­ную учет­ку и вно­сить ее в sudoers. А вот про­межу­точ­ный пункт 3 обя­затель­но про­читай, так как удоб­ный редак­тор тебе при­годит­ся.

Пос­ле покуп­ки VDS поль­зовате­лю сооб­щают пароль root, поль­зователь копиру­ет его в про­филь сво­его SSH-кли­ента. Но это в кор­не неп­равиль­но. Во‑пер­вых, учет­ная запись root — это всем извес­тное имя, и, ког­да зло­умыш­ленник попыта­ется взло­мать твой сер­вер методом гру­бой силы, он будет пытать­ся получить имен­но учет­ную запись root. Все прос­то: име­на соз­данных тобой поль­зовате­лей он не зна­ет, а root есть у всех. Поэто­му нам нужен обыч­ный поль­зователь, под которым ты будешь работать пос­тоян­но. Соз­даем поль­зовате­ля (имя нуж­но изме­нить на свое собс­твен­ное):

adduser user

passwd user

Пер­вая коман­да добав­ляет учет­ную запись с име­нем user, вто­рая изме­няет пароль для нее. Толь­ко не соз­давай поль­зовате­ля admin, пожалуй­ста!

Что­бы этот поль­зователь мог работать с пра­вами root, нуж­но добавить его в sudoers, но сна­чала понадо­бит­ся выпол­нить один про­межу­точ­ный шаг.

Ис­поль­зуемый боль­шинс­твом про­вай­деров по умол­чанию редак­тор Vi неудоб­ный и тре­бует спе­циаль­ных зна­ний, что нем­ного шокиру­ет начина­ющих поль­зовате­лей.

Пе­ред уста­нов­кой любого соф­та пер­вым делом обно­ви спис­ки пакетов. Дела­ется это с помощью коман­ды apt update. Обновлять спи­сок пакетов нуж­но как минимум один раз — перед пер­вой уста­нов­кой. Пос­ле это­го обновле­ние дела­ют по мере необ­ходимос­ти.

# apt update

Итак, уста­нови любой тек­сто­вый редак­тор, который тебе нра­вит­ся. Нап­ример, удоб­ный редак­тор nano:

# apt install nano

За­пус­тить отдель­но редак­тор мож­но коман­дой nano. Смот­рим, где находит­ся этот редак­тор:

which nano

Обыч­но это каталог /bin/nano. Теперь нуж­но сде­лать так, что­бы этот редак­тор исполь­зовал­ся по умол­чанию. В сов­ремен­ном Ubuntu это дела­ется так:

update-alternatives –config editor

Да­лее тебе нуж­но прос­то выб­рать nano из спис­ка пред­лага­емых вари­антов. Если дан­ный спо­соб не сра­ботал (нет коман­ды update-alternatives), мож­но пой­ти прос­тым путем и про­писать перемен­ную окру­жения EDITOR:

export EDITOR=/bin/nano

Что­бы перемен­ная окру­жения EDITOR уста­нав­ливалась при каж­дом вхо­де в сис­тему, отре­дак­тируй файл .bashrc, который находит­ся в домаш­нем катало­ге поль­зовате­ля. Добавь в него коман­ду

export EDITOR=/bin/nano

Об­рати вни­мание, что это нуж­но сде­лать для каж­дого поль­зовате­ля. Для поль­зовате­ля root домаш­ний каталог — /root. Для поль­зовате­ля denis — /home/denis.

Пос­ле это­го все коман­ды, вызыва­ющие редак­тор по умол­чанию, будут исполь­зовать удоб­ный редак­тор nano. Одна из таких команд — visudo.

Ра­нее мы соз­дали обыч­ного поль­зовате­ля user. Теперь нуж­но прев­ратить его в адми­нис­тра­тора, то есть пре­дос­тавить воз­можность исполь­зовать sudo. Вве­ди в тер­минале коман­ду

visudo

Эта коман­да запус­тит тек­сто­вый редак­тор для изме­нения фай­ла кон­фигура­ции sudoers. Най­ди и рас­коммен­тируй строч­ку

wheel ALL=(ALL) ALL

Ука­зан­ная строч­ка раз­реша­ет всем поль­зовате­лям груп­пы wheel исполь­зовать коман­ду sudo. Если она уже рас­коммен­тирова­на, ничего делать не нуж­но. Наж­ми F10 для выхода из редак­тора.

Пос­ле это­го добавь нашего поль­зовате­ля user в груп­пу wheel:

usermod -aG wheel user

Да­лее отклю­чись от SSH-сер­вера и попытай­ся вой­ти как поль­зователь user с задан­ным ранее паролем. Обра­ти вни­мание, что, ког­да ты работал как поль­зователь root, приг­лашение коман­дной стро­ки име­ло вид #, теперь оно выг­лядит как $. Залоги­нив­шись, вве­ди коман­ду

sudo bash

Ес­ли приг­лашение коман­дной стро­ки поменя­лось на #, теперь у тебя есть пра­ва root. Такой трюк поз­воля­ет вво­дить коман­ды от име­ни root без исполь­зования коман­ды sudo, что, несом­ненно, удоб­нее.

Де­ло оста­лось за малым — зап­ретить поль­зовате­лю root вхо­дить в сис­тему по SSH. Для это­го, работая уже под новым поль­зовате­лем user, вве­ди коман­ду

sudo mcedit /etc/ssh/sshd_config

До­бавь в кон­фигура­цион­ный файл сер­вера SSH такую стро­ку (или рас­коммен­тируй ее):

PermitRootLogin no

Сох­рани файл кон­фигура­ции, рес­тарта­ни SSH (systemctl restart ssh) и поп­робуй под­клю­чить­ся как поль­зователь root — у тебя не получит­ся. WARNING

Пе­резаг­ружать SSH нуж­но толь­ко в том слу­чае, если ты убе­дил­ся, что можешь вой­ти как поль­зователь user (от име­ни это­го поль­зовате­ля мож­но ввес­ти коман­ду sudo)! Ина­че есть риск потерять дос­туп к сер­веру, и тог­да при­дет­ся обра­щать­ся в сап­порт.

Как вари­ант, мож­но не отклю­чать вход под учет­ной записью root, а нас­тро­ить вход по клю­чу (см. далее) и лишь пос­ле того, как ты убе­дишь­ся, что можешь вой­ти как root по клю­чу, в кон­фиг SSH добавить строч­ку

PermitRootLogin without-password

Ко­неч­но, пос­ле это­го нуж­но опять перезаг­ружать SSH.

Су­щес­тву­ет прак­тика аутен­тифика­ции по клю­чу (public key authentication), а не по паролю. Пре­иму­щес­тва и недос­татки это­го метода рас­смат­ривать не будем, здесь одни пре­иму­щес­тва — пароль ник­то не под­берет, так как его поп­росту нет. Это самый надеж­ный спо­соб аутен­тифика­ции.

Прин­цип аутен­тифика­ции по клю­чу сле­дующий: соз­дает­ся пара клю­чей (откры­тый и зак­рытый). Зак­рытый ключ хра­нит­ся на сто­роне кли­ента, и в иде­але он не дос­тупен ни для кого. Откры­тый заг­ружа­ется на сер­вер, к которо­му нуж­но получить дос­туп.

В иде­аль­ном мире клю­чи дол­жны генери­ровать сами поль­зовате­ли. Сге­нери­ровать их мож­но с помощью коман­ды ssh-keygen, а так­же исполь­зуя фун­кци­ональ­ность SSH-кли­ента (нап­ример, воз­можность соз­дания клю­чевой пары есть в Bitvise SSH Client и во мно­гих дру­гих кли­ентах). Если у тебя Linux, никакой допол­нитель­ный софт уста­нав­ливать не нуж­но. Вве­ди коман­ду

$ mkdir ~/.ssh; ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa

Здесь мы генери­руем RSA-клю­чи дли­ной 2048 бит. Пос­ле того как клю­чи будут сге­нери­рова­ны, пуб­личный ключ ста­нет дос­тупен по име­ни ~/.ssh/id_rsa.pub. Далее нуж­но передать откры­тый ключ на сер­вер. Самый прос­той и пра­виль­ный спо­соб сде­лать это — исполь­зовать коман­ду ssh-copy-id:

ssh-copy-id username@remote_host

При выпол­нении этой коман­ды ты можешь уви­деть сле­дующее:

The authenticity of host '111.222.33.44 (111.222.33.44)' can't be established.

ECDSA key fingerprint is fd:ff:c4:a9:55:be:a3:f4:e1:55:01:ac:d8:7d:12:fb.

Are you sure you want to continue connecting (yes/no)? yes

Твой локаль­ный компь­ютер прос­то не рас­позна­ет уда­лен­ный сер­вер — это нор­маль­но при пер­вом под­клю­чении. Вве­ди yes (имен­но yes, а не y) и наж­ми Enter. Коман­да ssh-copy-id най­дет соз­данный ключ и отпра­вит его на сер­вер. Содер­жимое клю­ча ~/.ssh/id_rsa.pub будет ско­пиро­вано в файл ~/.ssh/authorized_keys уда­лен­ной учет­ной записи. Дан­ный спо­соб сра­бота­ет, если пока еще дей­ству­ет аутен­тифика­ция по паролю. На эта­пе пер­воначаль­ной нас­трой­ки это обыч­ное дело — сна­чала все поль­зовате­ли генери­руют клю­чевые пары и заг­ружа­ют на сер­вер свои откры­тые клю­чи, а затем зак­рыва­ется вход по паролю. Но если вход по паролю уже отклю­чен, а тебе надо заг­рузить ключ для нового поль­зовате­ля, то пот­ребу­ется най­ти спо­соб дос­тавить ключ (файл id_rsa.pub) на сер­вер. Далее нуж­но перей­ти в каталог ~/.ssh учет­ной записи, для которой нас­тра­ивает­ся ключ, и помес­тить содер­жимое id_rsa.pub в конец фай­ла authorized_keys:

cat id_rsa.pub » authorized_keys

Но не будем стро­ить лиш­ние пред­положе­ния и усложнять себе жизнь. Счи­таем, что дос­туп по паролю пока открыт и дос­таточ­но исполь­зовать коман­ду ssh-copy-id для заг­рузки клю­чей на сер­вер. Ког­да откры­тые клю­чи всех поль­зовате­лей заг­ружены, мож­но отклю­чить вход по паролю. Для это­го открой в любом тек­сто­вом редак­торе файл /etc/ssh/sshd_config и уста­нови в зна­чение No дирек­тиву PasswordAuthentication:

PasswordAuthentication no

Так­же нуж­но убе­дить­ся, что три сле­дующие дирек­тивы уста­нов­лены таким обра­зом:

PubkeyAuthentication yes

AuthorizedKeysFile %h/.ssh/authorized_keys

PermitRootLogin without-password

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

Ос­талось перезаг­рузить SSH:

systemctl restart ssh

На сто­роне кли­ента вой­ти по клю­чу на SSH-сер­вер мож­но так:

ssh -i ~/.ssh/id_rsa.pub user@example.com

Здесь мы ука­зыва­ем имя фай­ла клю­ча, имя поль­зовате­ля и имя сер­вера. В Windows нуж­но нас­тра­ивать исполь­зуемый тобой SSH-кли­ент, нап­ример в Bitvise SSH Client необ­ходимо нажать кноп­ку‑ссыл­ку Client key manager на вклад­ке Login и в появив­шемся окне нажать кноп­ку Generate New. В окне Generate New Keypair мож­но прос­то вос­поль­зовать­ся кноп­кой Generate. А мож­но допол­нитель­но защитить клю­чевую пару паролем — для это­го ввес­ти пароль, под­твер­дить его и нажать кноп­ку Generate. Рекомен­дует­ся исполь­зовать пароль­ную фра­зу — если во вре­мя тво­его отсутс­твия кто‑то запус­тит SSH-кли­ент и поп­робу­ет под­клю­чить­ся к сер­веру, исполь­зуя твой откры­тый ключ, у него ничего не получит­ся, так как он не зна­ет пароль.

Па­роль нужен для дос­тупа к клю­чевой паре толь­ко на локаль­ном компь­юте­ре, он не переда­ется в каком бы то ни было виде на сер­вер. Пос­ле того как клю­чевая пара сге­нери­рова­на, нуж­но нажать кноп­ку Export для экспор­та пуб­лично­го клю­ча. Фор­мат — OpenSSH. Пос­ле того как ты сох­ранишь откры­тый ключ в каком‑нибудь фай­ле, заг­рузи этот ключ на сер­вер и добавь его содер­жимое в файл

~/.ssh/authorized_keys

Спо­собов мно­го, нап­ример мож­но исполь­зовать учет­ку, в которой уже нас­тро­ена аутен­тифика­ция для заг­рузки это­го фай­ла. Мож­но заг­рузить ключ на какой‑то сайт и на сер­вере ска­чать его с помощью коман­ды wget http:адрес/имя_файла. В общем, про­яви фан­тазию, и у тебя все получит­ся. Пос­ле того как сер­вер «узна­ет» твой ключ, в основном окне кли­ента выбери Initial method — publickey, а из спис­ка Client Key — про­филь, в котором ты сох­ранил ключ. Client key manager Ос­новное окно Bitvise SSH Client ===7. НАЗНАЧАЕМ SSH НЕСТАНДАРТНЫЙ ПОРТ=== По умол­чанию SSH исполь­зует порт 22. Но ты можешь перенас­тро­ить его на дру­гой порт из сооб­ражений безопас­ности — тог­да для под­клю­чения по SSH нуж­но знать еще и номер пор­та. Открой /etc/ssh/sshd_config и най­ди дирек­тиву Port. Вмес­то 22 ука­жи дру­гой порт: Port 2206 Пос­ле это­го переза­пус­ти SSH и перело­гинь­ся. При вхо­де в нас­трой­ках кли­ента ука­жи новый номер пор­та. ===8. НАСТРАИВАЕМ БРАНДМАУЭР=== Ра­зоб­равшись с безопас­ностью поль­зовате­лей, нуж­но нас­тро­ить бран­дма­уэр. Тра­дици­онно в качес­тве бран­дма­уэра (филь­тра пакетов) в Ubuntu исполь­зует­ся iptables, но пос­коль­ку Ubuntu позици­они­рует­ся как прос­той дис­три­бутив, то и обо­лоч­ка для iptables была раз­работа­на соот­ветс­тву­ющая — UFW (Uncomplicated Firewall). Это нес­ложный фай­рвол. Пер­вым делом убе­дись, что пакет ufw вооб­ще уста­нов­лен, и уста­нови его, если это не так: sudo apt install ufw Базовая настройка Те­перь пос­мотрим сос­тояние бран­дма­уэра: sudo ufw status verbose По умол­чанию филь­тр пакетов вык­лючен, поэто­му коман­да выведет сооб­щение Status: inactive. Не нуж­но спе­шить вклю­чать фай­рвол: сна­чала его тре­бует­ся нас­тро­ить. Ведь если порт 22 ока­жет­ся по умол­чанию недос­тупен, то ты потеря­ешь дос­туп к сво­ему VDS. Конеч­но, сап­порт поможет, но это нап­расная тра­та вре­мени. С базовы­ми нас­трой­ками бран­дма­уэр зап­реща­ет все вхо­дящие соеди­нения и раз­реша­ет все исхо­дящие. Такая полити­ка иде­аль­на с точ­ки зре­ния безопас­ности — ведь если кто‑то (и ты в том чис­ле) захочет к нему под­клю­чить­ся, у него это не получит­ся. В то же вре­мя при­ложе­ния на сер­вере смо­гут соз­давать исхо­дящие соеди­нения. Рас­смот­рим две коман­ды: ufw default deny incoming ufw default allow outgoing Эти два пра­вила как раз и зада­ют полити­ку по умол­чанию: зап­реща­ются все вхо­дящие соеди­нения и раз­реша­ются все исхо­дящие. Итак, все вхо­дящие соеди­нения зап­рещены. Что­бы до сер­вера мож­но было дос­тучать­ся по опре­делен­ному пор­ту, его нуж­но сна­чала открыть. UFW хорош тем, что адми­ну даже не тре­бует­ся пом­нить номер пор­та — необ­ходимо знать толь­ко наз­вание сер­виса. Нап­ример, вот как мож­но раз­решить под­клю­чение по SSH: ufw allow ssh При этом UFW сам соз­даст пра­вило для пор­та 22 — имен­но этот порт исполь­зует­ся для SSH. Бран­дма­уэр зна­ет пор­ты и име­на всех рас­простра­нен­ных служб (HTTP, SSH, FTP, SFTP и так далее). Од­нако если ты перенас­тро­ил SSH на нес­тандар­тный порт, нуж­но явно ука­зать номер пор­та: ufw allow 2206 Пос­ле раз­решения SSH (это глав­ное, что­бы сей­час фай­рвол нам не разор­вал соеди­нение) мож­но вклю­чить ufw сле­дующей коман­дой: ufw enable Не­обхо­димо под­твер­дить запуск: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Ба­зовая нас­трой­ка Раз­берем­ся, что про­изош­ло. Сна­чала мы раз­решили SSH и получи­ли ответ Rules updated, то есть пра­вила обновле­ны. Затем мы вклю­чаем фай­рвол и получа­ем сооб­щение, что он акти­вен и будет запус­кать­ся при заг­рузке сис­темы. На этом базовая нас­трой­ка выпол­нена — SSH успешно работа­ет, и мы можем прис­тупить к даль­нейшей нас­трой­ке филь­тра пакетов. Создание правил для сервисов Те­перь нуж­но раз­решить работу дру­гих при­ложе­ний. Как пра­вило, тре­бует­ся раз­решить служ­бу HTTP (веб‑сер­вер), FTP (если этот сер­вис вам нужен) и пос­тарать­ся не забыть о HTTPS (что очень важ­но в пос­леднее вре­мя): ufw allow http ufw allow https ufw allow ftp Сде­лать то же самое мож­но было бы и по номерам пор­тов: ufw allow 80 ufw allow 443 ufw allow 21 При желании мож­но раз­решить целый диапа­зон пор­тов, ука­зав при этом тран­спортный про­токол (UDP или TCP): sudo ufw allow 2000:2200/tcp sudo ufw allow 4000:4400/udp Разрешаем IP-адреса Ufw поз­воля­ет раз­решить опре­делен­ному IP-адре­су дос­туп ко всем пор­там сер­вера, нап­ример: ufw allow from 111.222.33.44 Ес­ли нуж­но раз­решить дос­туп кон­крет­ному IP-адре­су толь­ко к опре­делен­ному пор­ту, то дела­ется это так: ufw allow from 111.222.33.44 to any port 22 Здесь мы раз­реша­ем не все под­клю­чения к SSH, а толь­ко под­клю­чения с IP-адре­са 111.222.33.44. WARNING Де­лать это нуж­но толь­ко в том слу­чае, если у тебя пос­тоян­ный IP — такой IP мож­но получить за допол­нитель­ную пла­ту у тво­его про­вай­дера. Обыч­но у поль­зовате­лей динами­чес­кие IP-адре­са — если ты пря­мо сей­час пос­мотришь свой внеш­ний IP, ука­жешь его в коман­де выше, то, как толь­ко твой IP поменя­ется, ты лишишь­ся дос­тупа к сер­веру. Так что будь осто­рожен! Раз­решить дос­туп целого диапа­зона IP-адре­сов (нап­ример, ког­да у адми­на динами­чес­кий IP) мож­но таким обра­зом: ufw allow from 123.45.67.89/24 to any port 22 Запрещаем IP-адреса и службы Что­бы зап­ретить дос­туп с опре­делен­ного IP-адре­са, вос­поль­зуйся вот такой коман­дой: ufw deny from 123.45.67.89 При желании мож­но зап­ретить все под­клю­чения к опре­делен­ной служ­бе: ufw deny ftp Удаление и сброс правил Сбро­сит все пра­вила сле­дующая коман­да: ufw reset Но до того, как вво­дить эту коман­ду, убе­дись, что ты отклю­чил фай­рвол (коман­да ufw disable), ина­че потеря­ешь дос­туп по SSH. Уда­лить кон­крет­ное пра­вило мож­но по номеру. Сна­чала вве­ди сле­дующую коман­ду, что­бы узнать номер пра­вила: ufw status numbered Да­лее вве­ди коман­ду такого вида: ufw delete <номер правила> ===9. НАСТРАИВАЕМ РЕЗЕРВНОЕ КОПИРОВАНИЕ=== Как пра­вило, в админке управле­ния сер­верами и дру­гими услу­гами про­вай­дера есть воз­можность нас­тро­ить резер­вное копиро­вание для каж­дого сер­вера. В зависи­мос­ти от усло­вий тариф­ного пла­на бэкап может быть бес­плат­ным (то есть ты можешь исполь­зовать какой‑то объ­ем прос­транс­тва под бэкапы), а может быть плат­ным. Как показы­вает прак­тика, час­то про­вай­деры тре­буют пла­ту за хра­нение бэкапов, поэто­му сама воз­можность резер­вно­го копиро­вания хоть и име­ется, но вык­лючена, что­бы у кли­ента не было допол­нитель­ных трат. У тебя, как у адми­на VDS, есть два вари­анта. Пер­вый — исполь­зовать средс­тва резер­вно­го копиро­вания про­вай­дера, вто­рой — нас­тро­ить резер­вное копиро­вание на сво­ем сер­вере. Бэкап на сто­роне про­вай­дера надеж­нее, так как резер­вная копия хра­нит­ся за пре­дела­ми сер­вера. Вто­рой вари­ант менее надежен, пос­коль­ку если что‑то слу­чит­ся с фай­ловой сис­темой сер­вера, то ты потеря­ешь все свои дан­ные. Как быть? Луч­ше все­го исполь­зовать ком­биниро­ван­ную сис­тему — нас­тро­ить бэкапы на сто­роне про­вай­дера со сред­ней пери­одич­ностью, ска­жем раз в неделю. При такой пери­одич­ности счет за бэкапы не будет кос­мичес­ким. Зато, если что‑то слу­чит­ся с фай­ловой сис­темой, ты смо­жешь вос­ста­новить дан­ные, пусть и не самые акту­аль­ные, но это луч­ше, чем начинать все с нуля. А теперь погово­рим о бэкапе вруч­ную на сто­роне сер­вера. Есть целые решения для резер­вно­го копиро­вания. Нуж­ны они или нет — решать толь­ко тебе. Я же пред­лагаю пой­ти по самому прос­тому пути. Пер­вым делом надо опре­делить­ся, какие дан­ные сто­ит резер­вировать. Если у тебя на сер­вере веб‑сайт (нап­ример, интернет‑магазин), то копиро­вать нуж­но толь­ко фай­лы кор­невого катало­га веб‑сер­вера (DocumentRoot, обыч­но это /var/www/html, но зависит от нас­тро­ек сер­вера) и базу дан­ных. Фай­лы веб‑сер­вера мож­но копиро­вать раз в неделю — они меня­ются отно­ситель­но нечас­то. Если ты дела­ешь бэкап средс­тва­ми про­вай­дера, ска­жем каж­дую пят­ницу, то бэкап фай­лов сер­вера мож­но делать в середи­не недели — в сре­ду. Тог­да у тебя будет на вся­кий слу­чай две резер­вные копии за неделю. Мож­но и чаще — глав­ное, что­бы хва­тило мес­та на дис­ке. Если у тебя 1 Тбайт, а сайт весит 250 Гбайт, то очень час­то бэкапы соз­давать не при­дет­ся. Соз­дать архив с резер­вной копи­ей фай­лов сай­та мож­но коман­дой zip -r /backups/latest.zip /var/ww/html Эту коман­ду нуж­но добавить в рас­писание crontab. Вве­ди коман­ду crontab –e и добавь строч­ку: 0 2 * * 3 /usr/bin/zip –r /backups/latest.zip /var/ww/html Де­лать бэкап луч­ше все­го ночью, что­бы сни­зить наг­рузку на сер­вер. Здесь копия будет соз­давать­ся по сре­дам в два часа ночи. Рас­паковать архив мож­но с помощью коман­ды unzip. Те­перь о базе. Изме­нения в базу дан­ных вно­сят­ся пос­тоян­но: менед­жеры добав­ляют информа­цию о про­дук­тах, какой‑то скрипт импорта изме­няет цены и остатки товаров, а посети­тели дела­ют заказы. Поэто­му копия базы дол­жна соз­давать­ся раз в день. Для копии исполь­зуем mysql-dump: mysqldump -u cp_user -p –opt cp_main_v2 –max_allowed_packet=100M > db-latest.sql Здесь cp_user — имя поль­зовате­ля БД, cp_main_v2 — имя базы дан­ных, опция max_allowed_packet зада­ет мак­сималь­ный раз­мер пакета — на слу­чай, если БД занима­ет нес­коль­ко гигов, эта опция тебя спа­сет. Бэкап дела­ется в файл db-latest.sql. Вос­ста­новить­ся мож­но так: mysql –host=127.0.0.1 –port=3310 –max_allowed_packet=100M -u cp_user -p cp_main_v2 < /db-latest.sql Наз­начение парамет­ров дол­жно быть понят­но. Парамет­ры host и port мож­но не ука­зывать, если MySQL работа­ет на localhost и исполь­зует стан­дар­тный порт. Коман­ду соз­дания дам­па нуж­но запус­кать каж­дый день, поэто­му в crontab добав­ляем стро­ку 0 1 * * * /usr/bin/mysqldump -u cp_user -p –opt cp_main_v2 –max_allowed_packet=100M > /root/db-latest.sql Бэ­кап будет сни­мать­ся каж­дый день в час ночи (а в два мы запус­каем соз­дание бэкапа фай­лов). Кро­ме бэкапов не забывай о снап­шотах! Перед каж­дым зна­чимым изме­нени­ем на сер­вере (вро­де уста­нов­ки рас­ширения, перес­борки CMS, обновле­ния ПО, нап­ример уста­нов­ки новой вер­сии PHP) делай снап­шот. Да, всег­да мож­но вос­ста­новить­ся из бэкапа, но бэкап у нас не самый све­жий, да и вре­мени такое вос­ста­нов­ление занима­ет боль­ше, чем вос­ста­нов­ление из снап­шота. Снап­шоты тоже плат­ные, но их цена нич­тожна на фоне прос­тоя production-сер­вера. НАПОСЛЕДОК — УСТАНОВКА АДМИНКИ Лич­но мне про­ще и при­выч­нее управлять сер­вером через SSH. Но если нужен гра­фичес­кий интерфейс для выпол­нения ежед­невных рутин­ных задач, можешь уста­новить панель управле­ния. Выбор кон­крет­ной панели зависит от двух фак­торов: необ­ходимой фун­кци­ональ­нос­ти и сто­имос­ти панели управле­ния. Если нуж­ны бес­плат­ные решения, смот­ри в сто­рону Webmin и VestaCP. Осталь­ные вари­анты менее популяр­ны. Собс­твен­но, на этом все — базовая нас­трой­ка VDS завер­шена. Теперь мож­но прис­тупить к уста­нов­ке и нас­трой­ке необ­ходимо­го ПО (Nginx, MySQL, PHP и про­чее). Источник —–