Рубрика: Linux

Разбирался подойдет ли эта система с точки зрения меня как пользователя-разработчика

Вот вы решили сделать свой сайт, выбрали уже доменное имя, купили хостинг и закинули движок на сервер хостера. К вам стали подтягиваться посетители, вы стали постить тексты, фото, видо и вот вдруг обнаруживается, что места больше нет. Вы заходите в панель управления, а там предлагается объём до 100 ГБ и стоить это будет “космос”. Так что, кина не будет? (цит. из ф. “Джентельмены удачи”). Ну, мы же айтишники, мы понимаем, что в ИТ можно всё!..ну, почти всё))…

Для начала нам потребуется перевести хостинг на VPS. И вы не поверите, но абонентская плата будет меньше за те же ресурсы. По крайней мере у меня на Бегете (на нём я около 5 лет) это было именно так. Кстати, вот партнерская ссылка, по которой и мне будет профит и вам скидка:

https://beget.com/p1223557

Для тех, кто не имел с этим дело скажу. Обычный хостинг – это фактически папка на сервере, где ещё таких как вы могут быть сотни. Один мощный сервер распределяет свои ресурсы между множеством сайтов таких же как и вы клиентов. Поддержка, обслуживание и работы на этом сервере требуют квалифицированный персонал, по этому за это берутся отдельные деньги. VPS – это вам даётся сервер с уже предустановленной операционной системой, в частности Ubuntu, и установленным на неё ПО для работы сайта. Чаще всего это пакет LAMP (Linux, Apache, MySQL, PHP). Сам сервере виртуальный, но для нас это не имеет никакого значения, т.к. ничто не будет отличать его от реального. Но и здесь хостер выделит вам всё равно те же 10 ГБ (начальный уровень), а за всё что больше придётся доплатить…это если вы что-то не знаете, что знаю я)))…Открываем папку моего сайта https://elvinto.ru и смотрим размер свободного месте на диске:

Внимательно смотрим в правый нижний угол – 94 ГБ и з 1.8 ТБ свободно. Теперь взглянем, что в моём тарифном плане в панели управления:

Получается как в сказке “Карлик нос” – избушка изнутри больше, чем снаружи. Так-то оно так, да не совсем. Пора открывать карты)).

Есть у меня на этом VPS-сервере портал в другое измерение, а именно – на мой домашний комп. Весь процесс сводится к монтировании домашней папки в папку VPS-сервера. Домашний сервер у меня тоже на Ubuntu, дома потребуется “белый” IP, по этому и для этого примера тоже буду писать исходя из этого. Пользователь на VPS vpsuser, на домашнем компе – homeuser. В папке homeuser есть папка content, которая и является тем терабайтным хранилищем, которое мы подключаем.

Настроим сначала сервер VPS.

Для этого сначала нужно установить sshfs:

sudo apt-get install sshfs

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

ssh-keygen -b 4096

В результате получим в папке ~/.ssh пару файлов – публичный и приватный ключ. Теперь публичный ключ можно скопировать себе на домашний комп. Сделал я это просто – выложил на сайте по ссылке прямо в корне elvinto.ru/id_rsa.pub (сейчас там нет этого файла, чтобы не засорять корень), а с домашнего компа скачал из браузера. Бояться, что его кто-то украдёт не надо, т.к. красть его глупо, это публичный ключ и расшифровать закодированную им информацию может только обладатель приватного ключа, который остался в папке .ssh на VPS (вы же ничего не напутали?!!)) ).

Настройка домашнего сервера.

Создайте удобочитаемую папку на том диске, где у вас эти самые терабайты. У меня в примере это /home/homeuser/content. Теперь в папку /home/.ssh закиньте id_rsa.pub и переименуйте его в authorized_keys (если такой файл уже есть, то допишите в конец этого файла ваш id_rsa.pub). У файла authorized_keys обязательно должны быть права (с другими может отказать в авторизации по ключу и потребует ввести пользователь и пароль):

chmod 0600 authorized_keys

Снова продолжаем настраивать VPS.

Теперь нужно в файл /etc/rc.local (если его нет, см.далее) перед exit 0 добавить нужный текст (для сайта на WordPress – расширяется папка wp-content/uploads):

sshfs -o idmap=user,allow_other,reconnect,ServerAliveInterval=600,IdentityFile=/home/vpsuser/.ssh/id_rsa -p 22 homeuser@ВашБелыйIPадрес:/home/homeuser/content /ПутьКВашемуСайту/wp-content/uploads

Если файла rc.local нет, значит сервис rc-local просто не включен, такое встречается на Ubuntu >= 20.04. Всё делается просто. Создайте при помощи, например, nano или mcedit этот файл и дайте ему права на запуск. Файл должен начинаться со спец.строки и заканчиваться exit 0:

Теперь нужно включить сервис rc-local:

sudo systemctl enable rc-local

и стартануть его:

sudo systemctl start rc-local.service

Проверяем на VPS папку, куда монтировали, она должна ссылаться на ваш домашний сервер.

П.С.:

Вы должны понимать, что качество вашего сайта после этого будет обеспечиваться двумя основными факторами – стабильность и скорость домашнего инета и надежность домашнего хранилища. Но если речь идет о бесплатном обеспечении сайта терабайтами, то уж постарайтесь это осуществить…как-то))).

El Vinto, 2023

Торренты прочно вошли в нашу жизнь как удобное средство обмена файлами через сеть интернет. Однако, рано или поздно встаёт вопрос, насколько безопасно это использование и рационально ли мы используем для этого компьютер. Торрент-обмен строится на базе пиринговой сети, о которой я упоминал в другой своей статье – о клиенте и сервере, а пользователь использует клиентское приложение, которое и выполняет всю работу по файловому обмену. Весь вопрос безопасности сводится к тому, кем изготовлено это приложение и насколько качественно оно сделано. Если на компьютере, где установлен торрент-клиент, находится какая-либо конфиденциальная информация (личные файлы, семейные фотографии, сканы документов), то я не считаю установку торрент-клиента на такой компьютер хотя бы сколько-нибудь безопасной. Гораздо было бы удобнее разместить торрент-клиента на отдельном компьютере или виртуальной машине, давать удаленно задачи на файловый обмен и забирать готовые файлы по мере выполнения. Об этом речь в этой статье, а устанавливать будем софт на Ubuntu 22.04 Server. В качестве клиента будет использоваться веб-интерфейс.

Сначала устанавливаем сам сервер Deluge и его вспомогательный веб-сервис:

sudo apt-get install deluged deluge-web

В Ubuntu 22.04 вместе с установкой Deluge не происходит автоматического формирования файлов настройки сервиса, по этому их нужно создать вручную. Для этого нужно открыть необходимый каталог:

cd /etc/systemd/system

Теперь создадим сначала файла deluged.service:

sudo nano deluged.service

и наполним его следующим содержимым:

[Unit]
Description=Deluge Bittorrent Client Daemon
Documentation=man:deluged
After=network-online.target

[Service]
Type=simple
User=deluge
Group=deluge
UMask=000
ExecStart=/usr/bin/deluged -d
Restart=on-failure
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target

После этого создадим файл deluge-web.service:

sudo nano deluge-web.service

Со следующим содержимым:

[Unit]
Description=Deluge Bittorrent Client Web Interface
Documentation=man:deluge-web
After=network-online.target deluged.service
Wants=deluged.service

[Service]
Type=simple
User=deluge
Group=deluge
UMask=022
ExecStart=/usr/bin/deluge-web -d
Restart=on-failure

[Install]
WantedBy=multi-user.target

Проверьте, действительно ли исполняемые файлы находятся по этому пути (ну кто его знает куда их в следующий раз запихнут):

/usr/bin/deluged

/usr/bin/deluge-web

Если вдруг оказалось, что там их нет, то найдём их, для этого сначала возвратимся в корневой каталог и запустим поиск:

cd /

find / -name deluged

Лично у меня с этим проблем не возникло:

Теперь нужно создать пользователя, того самого, которого указали в настройках сервиса (это был пользователь deluge). От его имени будет выполняться сервис. Создаётся он просто:

sudo adduser deluge

Пароль вводится любой, он всё равно нам вряд ли понадобится, в конце выражаем согласие игреком:

Далее включаем и запускаем работу сервисов:

sudo systemctl enable deluged.service

sudo systemctl enable deluge-web.service

sudo systemctl start deluged.service

sudo systemctl start deluge-web.service

Теперь открываем браузер и вводим путь к вашему Ubuntu серверу с Deluge. У меня это 192.168.1.24 (не забываем указать специальный порт интерфейса):

Пароль входа – это НЕ тот пароль, который вы ставили для пользователя deluge. Это пароль по-умолчанию, который тоже deluge.

На вопрос не хочу ли я сменить этот пароль, лично я отвечаю “Нет”, т.к. кроме меня в сети никто файлы качать не будет, и админить их тоже:

Далее появится окно выбора сервера. Нужно кликнуть (выбрать) по одной единственной строке и далее по кнопке “Start Daemon”:

Сервис веб состыкуется с сервисом deluged (это почему-то обозначается как старт демона) и теперь можно подключиться (нажать кнопку Connect – она станет доступна):

Появится рабочее окно списка торрентов:

Теперь, когда мы убедились, что всё работает, нужно донастроить сервер. Добавлять вручную торренты дело заморочное, по этому хорошо бы каталог, куда мы сразу записывали торрент-файлы (файлы с расширением .torrent) и хорошо бы иметь доступ к папке с уже скачанными файлами, но об этом позже. А пока создадим два каталога внутри домашнего каталога deluge:

sudo mkdir /home/deluge/data

sudo mkdir /home/deluge/torrents

Первая – для данных, вторая для торрент-файлов

Установим хозяина владельца на папки:

sudo chown deluge:deluge /home/deluge/data

sudo chown deluge:deluge /home/deluge/torrents

и проверим, всё ли норм:

Теперь объясню зачем это сделано именно так. Дело в том, что Deluge я устанавливаю на чистый виртуальный свежеустановленный Ubuntu server с минимальными настройками, в частности – 16 ГБ жесткого диска. Конечно, такого размера не хватит практически ни на что. Для того чтобы иметь много пространства, я подключу физический старый дряхлых жесткий диск и прокину его внутрь этой виртуальной. Делаю я так, потому что мне для торрентов жалко нового диска, и рано или поздно он своё отслужит, и когда накроется, я не хочу снова устанавливать Ubuntu, Deluge, Samba и т.п., я просто хочу прокинуть новый такой же старый и дряхлых (извиняюсь за каламбур) жесткий диск и продолжить сразу же работу. Вопрос будет только в том, чтобы перемонтировать этот диск в папку /home/deluge/data и проблема будет решена. Вот для чего я создал папку data – туда будет монтироваться диск большого объёма. Для торрент-файлов такой подход будет избыточным – это небольшие файлики, содержащие только управляющую информацию на закачку.

После подключения диска для готовых файлов к виртуальной (или физической) машине (это не имеет значения), на нём хорошо бы переопределить разделы и отформатировать, но сначала я его найду в списке устройств:

cd /dev

ls -al | grep sd

В результате система покажет какие диски у нас присутствуют:

Вот этот sdb без номера и есть наш новый старый дряхлый диск…хотя вру, у меня это новый виртуальный, новее некуда…на старом дряхлом физическом)))

Я дам ему один единственный раздел всего объёма:

sudo fdisk /dev/sdb

Введем сначала команду n и всё “отэнтерим”, проверим разделы командой p, а затем введем команду w для сохранения и выхода:

Да, диск я взял новый не такой уж и большой – 64 ГБ (не оказалось свободного места на датасторе перед написанием статьи), но это не так критично )).

Проверим, что нового появилось в дисках:

Всё верно – появился диск sdb1. Это как раз и есть наш раздел, но прежде чем сможем его использовать, нужно его отформатировать. Для этого я буду использовать следующую команду (опять отэнтерив вопросы):

sudo mkfs.ext4 /dev/sdb1

Получим результат:

Убедимся, что всё прошло ровно командой blkid:

Видим, что диск sdb1 имеет идентификатор и признак файловой системы ext4.

Создадим на диск папку, куда будем при загрузке системы монтировать этот диск:

sudo mkdir /torrents-disk

Добавим в файл /etc/fstab новую строку:

UUID=51a19ac1-7b9e-4553-ab29-9c99eae704f9 /torrents-disk ext4

Должно получиться как-то так:

Сохраним файл в новом виде и перезагрузим машину командой reboot.

После загрузки проверим всё ли мы сделали правильно командой:

df -h /torrents-disk

Должно получиться как-то так:

Информация свидетельствует о том, что при загрузке системы диск автоматически примонтировался успешно.

Создадим внутри каталога /torrents-disk каталог data:

sudo mkdir /torrents-disk/data

Примонтируем его в папку /home/deluge/data (если вы ещё не забыли зачем мы его вообще в систему добавили):

sudo mount -o bind /torrents-disk/data /home/deluge/data

Убеждаемся, что и папка /home/deluge/data ссылается теперь на наш “большой” диск:

Теперь, возможно у вас возник вопрос,- почему я прямо в fstab не примонтировал диск внутрь /home/deluge. Ответ прост – мне так удобнее в обслуживании, и ещё диск этот может мне понадобиться не только для торрентов, и захочу отдельную папку его примонтировать в другую совсем не связанную с торрент-сервисом. Если 2-3 ТБ, пусть он старый, но использовать его для торрентов, как-то неправдоподобно и бессмысленно. Я такой объем торрентов точно не буду вводить в обмен, по этому буду разделять диск с ещё другими сервисами, какими – потом решу.

Вторую команду монтирования тоже хорошо бы запихнуть куда-нибудь для автоматического выполнения при загрузке системы. Запихну-ка я её в rc.local. Однако, если мы посмотрим внимательно на свежий Ubuntu 22.04, там этого файла нет, а сервис находится в полной отключке))). Исправим это недоразумение)).

Создадим файл /etc/rc.local:

sudo nano /etc/rc.local

Содержимое его будет такое:

#!/bin/sh -e

mount -o bind /torrents-disk/data /home/deluge/data

exit

Сохраним его и дадим права и установим как исполняемый:

chmod 0744 /etc/rc.local

Создадим файл настройки сервиса:

sudo nano /etc/systemd/system/rc-local.service

Должно получиться так:

Включим, стартанём и проверим сервис rc-local.service:

sudo systemctl enable rc-local.service

sudo systemctl start rc-local.service

sudo systemctl status rc-local.service

Должно быть так:

Давайте перезагрузим наш сервачок и убедимся, что после ребута он будет делать ровно то, что должен. Проверим папку /home/deluge/data:

Теперь создадим три каталога внутри /torrents-disk/data.

sudo mkdir /torrents-disk/data/downloads

sudo mkdir /torrents-disk/data/downloaded

sudo mkdir /torrents-disk/data/autouploads

downloads будет хранить торренты пока они находятся в процессе закачки (до конца незакачанные торренты)

downloaded будет хранить файлы, которые полностью закачены и готовы к употреблению, так сказать

autouploads будет хранить торрент файлы .torrents. В эту папку мы будем сохранять задания на закачку, т.е. сами торренты.

На каталог autouploads нужно дать все права, чтобы гостевой пользователь мог туда сохранять торренты:

sudo chmod 0777 /torrents-disk/data/autouploads

На папку /torrents-disk/data и всех, которые внутри устанавливаем владельца:

sudo chown -R deluge:deluge /torrents-disk/data

Теперь организуем сетевой доступ к папке с торрентами и к папке с готовыми загруженными файлами. Делать я это буду путём установки в систему сервиса Samba:

sudo apt-get install samba

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

sudo nano /etc/samba/smb.conf

В конец файла допишем:

[autouploads]
comment = Auto uploads
browseable = yes
path = /torrents-disk/data/autouploads
guest ok = yes
read only = no
create mask = 0777

[downloaded]
comment = Downloaded
browseable = yes
path = /torrents-disk/data/downloaded
guest ok = yes
read only = yes
create mask = 0700

Должно получиться так:

В папку autouploads можно будет писать файлы, а из папки downloaded можно будет только читать файлы (оно и логично).

Перезапустим сервис Samba:

sudo /etc/init.d/smbd restart

Проверим, что по сети стал доступен сам сервер \\192.168.1.24\ (вместо моего IP тут будет IP вашего), а папка autouploads доступна для записи (я просто создал тестовый файл):

Попробуем сохранить туда торрент файл:

Файл торрента действительно сохранился в сетевой папке, однако, ожидать его закачки ещё рановато. Нужно настроить сам Deluge и привязать его к нашим каталогам. Откроем эти настройки в веб-интерфейсе:

Сразу же видим, что папка загрузки указано неверно. В Линуксе имеет значение заглавная буква имен или нет. Правильный каталог не Downloads, а downloads. Также сами каталоги находятся внутри /home/deluge/data. Укажем и остальные каталоги и нажмем кнопку Apply:

Переходим в раздел Plugins и добавляем новый плагин AutoAdd. Он нужен чтобы Deluge автоматически забирал файлы из каталога с торрентами (где у нас уже ожидает по крайней мере один файл с торрентом), потом также нажимаем Apply:

Переходим во вновь появившийся раздел AutoAdd и добавляем папку слежения за торрентами, а затем кнопку Add и опять-таки кнопку Apply:

После этого окно закрывается и торрент сразу же начинает скачиваться:

Файл скачался и мы можем его теперь скопировать из папки (по факту это оказался не просто один файл, а сразу каталог с несколькими файлами):

Статья создана El Vinto, 2023 (Исходник на сайте https://elvinto.ru)

1. Обзор

Snap – это система упаковки программного обеспечения, разработанная Canonical в первую очередь для использования в системах Linux с системой инициализации systemd. Он направлен на решение ряда проблем, связанных с упаковкой и распространением программного обеспечения, но также имеет свой набор недостатков. В этом руководстве мы рассмотрим недостатки использования Snap и узнаем, как отключить или удалить его.

Все команды были протестированы в Snap 2.58.2, запущенной в Ubuntu Desktop 22.04.02 LTS. Однако они также должны быть совместимы с большинством других дистрибутивов Linux.

2. Введение в проблему

Хотя Snap предоставляет ряд преимуществ, у него также есть некоторые потенциальные недостатки, такие как использование дискового пространства, производительность и ограниченная интеграция и настройка.

Из-за этих проблем и некоторых спорных решений, принятых Canonical за последние несколько лет, некоторые дистрибутивы отключили или вообще удалили Snap из своих выпусков.

2.1. Недостатки Snap

По сравнению с традиционными системами упаковки, такими как .deb или другими форматами, такими как Flatpak и AppImage, пакеты Snap, как правило, занимают больше места на диске. Более того, они запускаются медленнее, поскольку требуют инициализации среды выполнения и загрузки зависимостей в память.

Поскольку пакеты Snap являются автономными и изолированными от хост-системы, они предлагают ограниченную интеграцию с системными ресурсами и другими приложениями. Это может вызвать проблемы с доступом к определенным системным ресурсам, таким как системные темы и шрифты.

2.2. Противоречия с браузером Chromium

Начиная с Ubuntu версии 19.10, Canonical обязала пользователей Ubuntu и ее производных использовать Snap для установки Chromium. Пакет chromium-browser .deb теперь включает только скрипты-оболочки, которые облегчают загрузку пакета Snap.

В результате этого решения, Linux Mint удалил Snap из своего пакета выпуска, начиная с версии 20 – Ulyana. Команда apt также предотвращает установку snapd.

2.3. Автоматическое обновление по умолчанию

По умолчанию Snap выполняет четыре проверки в день на наличие обновлений и автоматически обновляется, когда они доступны. Однако эта функция может вызвать проблемы в системах с ограниченными ресурсами. Когда ресурсы, такие как оперативная память и процессоры, ограничены, операционная система может завершить другие важные процессы, чтобы приспособиться к процессу автоматического обновления.

2.4. Ubuntu не поддерживает Flatpak

Компания Canonical объявила, что она не будет включать программное обеспечение Flatpak в пакет Ubuntu, начиная с версии 23.04 – Lunar Lobster, в попытке стимулировать использование Snap вместо него.

3. Удаление и отключение Snap

Давайте отключим и удалим Snap из нашей системы.

При новой установке Ubuntu 22.04.2 LTS у нас предварительно установлены следующая версия Snap и пакеты:

$ snap --version
snap    2.58.2
snapd   2.58.2
series  16
ubuntu  22.04
kernel  5.19.0-35-generic

$ snap list
Name                       Version           Rev    Tracking         Publisher   Notes
bare                       1.0               5      latest/stable    canonical✓  base
core20                     20230126          1822   latest/stable    canonical✓  base
firefox                    110.0-3           2356   latest/stable/…  mozilla✓    -
gnome-3-38-2004            0+git.6f39565     119    latest/stable/…  canonical✓  -
gtk-common-themes          0.1-81-g442e511   1535   latest/stable/…  canonical✓  -
snap-store                 41.3-66-gfe1e325  638    latest/stable/…  canonical✓  -
snapd                      2.58.2            18357  latest/stable    canonical✓  snapd
snapd-desktop-integration  0.1               49     latest/stable/…  canonical✓  -

3.1. Удаление существующих пакетов Snap

Теперь давайте приступим к удалению пакетов Snap, или привязок, в следующем порядке:

$ snap remove firefox
$ snap remove gtk-common-themes
$ snap remove gnome-3-38-2004
$ snap remove snapd-desktop-integration
$ snap remove snap-store
$ snap remove core20
$ snap remove bare
$ snap remove snapd

Прежде чем перейти к следующему шагу, давайте убедимся, что список snaps пуст:

$ snap list
No snaps are installed yet. Try 'snap install hello-world'.

Если бы остались какие-либо привязки, мы могли бы вернуться к их перечислению и попытаться удалить их с помощью snap remove.

3.2. Удаление демона snapd

Далее давайте остановим, отключим, удалим и удержим демон snapd:

$ sudo systemctl stop snapd
Warning: Stopping snapd.service, but it can still be activated by:
snapd.socket

$ sudo systemctl disable snapd
Removed /etc/systemd/system/multi-user.target.wants/snapd.service.

$ sudo systemctl mask snapd
Created symlink /etc/systemd/system/snapd.service → /dev/null.

$ sudo apt purge snapd -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
snapd*
...
Removing snapd state

$ sudo apt-mark hold snapd
snapd set on hold.

Команда ‘apt-mark hold‘ означает, что пакет помечен как отложенный, что предотвратит автоматическую установку, обновление или удаление пакета.

3.3. Удаление каталогов пакетов Snap

Snap по умолчанию хранит все пакеты в каталоге ~/snap/. Давайте удалим его.:

$ rm -rf ~/snap/

Поскольку каталог находится в каталоге home, нам не нужно использовать sudo для его удаления. Однако важно быть осторожным при вводе команды, поскольку она удалит каталог рекурсивно.

Мы также должны убедиться, что путь ~/snap/ указан правильно.

3.4. Предотвращение установки Snap с помощью команды apt

Canonical изменила пакет chromium-browser .deb, теперь он включает только скрипты-оболочки, которые запускают установку Snap.

Чтобы предотвратить подобные случаи, мы можем использовать следующую команду, предложенную Linux Mint:

$ sudo cat <<EOF | sudo tee /etc/apt/preferences.d/nosnap.pref
Package: snapd
Pin: release a=*
Pin-Priority: -10
EOF

В результате, когда мы пытаемся установить браузер Chromium с помощью команды apt:

$ sudo apt install chromium-browser
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
chromium-browser : PreDepends: snapd but it is not installable
E: Unable to correct problems, you have held broken packages.

Как мы можем видеть из приведенной выше команды, Snap не сможет установить себя без нашего согласия.

3.5. Удаление всех оставшихся каталогов Snap

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

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

$ rm -rf ~/snap
$ sudo rm -rf /snap
$ sudo rm -rf /var/snap
$ sudo rm -rf /var/lib/snapd

4. Заключение

В этой статье мы рассмотрели процесс удаления и отключения Snap из нашей системы, а также предотвращение его установки без нашего согласия при использовании команды apt.

Для Ubuntu 22.04.

Для начала необходимо создать файл скрипта /etc/snake-backup-script по бэкапированию со следующим содержимым:

#!/bin/bash -e

declare -a databases=("buh" "ut" "zup")

for dbname in "${databases[@]}"
do
FILENAME=/backups-postgre/backup-$dbname-$(date +"%Y-%m-%dT%H-%m-%S")".dump.gz"

if sudo -u postgres pg_dump $dbname | gzip > $FILENAME ; then
        echo $FILENAME "OK"
else
        echo $FILENAME "ERROR"
fi

done

find /backups-postgre -type f -ctime +20 -delete

exit 0

Этот файл при запуске будет перебирать массив баз данных PostgreSQL и делать по ним выборочный бэкап и отправлять каждую БД в отдельный gz файл. Файл будет иметь имя включающее признак backup, название БД и дату/время. Таким образом, каждый бэкап будет уникальным и весь вопрос будет только в том чтобы следить за свободным пространством. Важно, чтобы бэкап выполнялся от имени postgres, для этого в скрипте используется модификатор sudo. Запись find будет искать бэкапы старше 20 дней и удалять их. Это сделано чтобы не загромождать диск.

Файл будет запускаться из Cron каждые три часа. Для этого нужно настроить Cron.

sudo crontab -e

Чтобы бэкап запускался каждый день в 7 утра, в файл внести запись:

0 7 * * * /etc/snake-backup-script

Теперь хороший вопрос, как восстановить:

Распаковываем нужную резервную копию:

gunzip /backups-postgre/mybackupfile.dump.gz

su postgres

Проверить наверняка базы данных:

psql -l

Удалить базу, в которую восстанавливать:

psql -c "DROP DATABASE mydatabase;"

Создать заново базу данных:

psql -c "CREATE DATABASE mydatabase;"

Восстановить базу данных:

psql -d mydatabase < /backups-postgre/mybackupfile.dump

sudo timedatectl set-timezone Europe/Moscow