boring_backup/docs/baf.1.rst
2022-05-14 00:20:02 +03:00

214 lines
14 KiB
ReStructuredText
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

===
baf
===
----------------------------------
backup automation micro-framework.
----------------------------------
:Copyright: \(C) 2022, ge <https://nixhacks.net/>, GPLv3+
:Manual section: 1
Синопсис
--------
``baf`` [options] [<arguments>]
Описание
--------
Baf это утилита для резервного копирования на основе сценариев Bash. По умолчанию предусмотрено создание полных резервных копий файлов и баз данных MySQL и PostgreSQL, но функционал может быть расширен в сценариях при помощи пользовательских функций.
Опции
-----
-h, --help print help text and exit.
-v, --version print version and exit.
Основы
------
Baf это седство для полного резервного копирования и может быть использован как микро-фреймворк для написания сценариев резервного копирования.
Baf не реализует собственный язык сценариев, а полагается на Bash. В любом варианте применения Baf требует написания сценария для выполнения бэкапа.
В сценариях можно использовать переменные и функции. Сценарий импортируется Baf с помощью команды `source` (см. ``bash``\(1) п. SHELL BUILTIN COMMANDS).
Простейший сценарий резервного копирования выглядит следующим образом::
sources=('file:/home/user')
targets=('file:/var/backup')
Здесь массивы `sources` и `targets` определяют точки (`points`) резервного копирования — источники (`sources`) и назначения (`targets`). Это основные сущности, с которыми работает Baf. Вот некоторые особенности точек:
- Все точки указываются в формате URI (см. RFC 3986). Описание URI также есть в этой документации ниже.ы
- Точки могут указывать как на локальные (размещённые на текущей машине), так и на удалённые (размещённые на удалённой машине) ресурсы.
- Можно указать как несколько источников, так и несколько назначений.
Для выполнения бэкапа директорий или отдельных файлов применяется схема URI `file`. В схеме `file` нельзя указать директорию, размещённую на удалённом хранилище (за исключением случая, когда удалённое хранилище примонтировано как файловая система), для этого используйте другие схемы. В примере выше будет выполнена резервная копия локальной директории /home/user в другую локальную директорию /var/backup. Поскольку в сценарии из примера нет ничего, кроме указания точек `sources` и `targets`, бэкап будет выполнен с параметрами по умолчанию: директория /home/user будет заархивирована с помощью утилиты ``tar``\(1), архив будет сжат с помощью утилиты ``gzip``\(1) и помещён в директорию /var/backup. Имя архива будет сложено из строки::
${name_prefix}${name}_%Y%m%d-%H%M${file_ext}
Здесь:
``${name_prefix}``
Переменная, значение которой соответствует имени файла сценария (без расширения).
``${name}``
Имя архивируемой директории/файла (``basename``\(1)).
``%Y%m%d-%H%M``
Дата, интерпретируемая утилитой ``date``\(1).
``${file_ext}``
Расширение имени файла, соответствующее формату архива. По умолчанию ".tar.gz".
Обзор URI
---------
Источники (`sources`) и назначения (`targets`) должны быть указаны в виде URI. Это позовляет наглядно в одной сроке видеть весь набор данных. Парсер реализует поддержку следующего синтаксиса URI::
scheme:[//[username[:password]@][hostname[:port]]/[path]?[query]#[fragment]
Парсер URI соответствует RFC 3986 не полностью - разбиение на составные части URI происходит верно, но интерпретация отдельных ситуаций может отличаться. См. примеры URI и реузультаты их интерпретации парсером в файле `tests/parse_uri.bats`. На практике рекомендую придерживаться примеров, которые приведены ниже и в файле `tests/parse_uri.bats`. В случае, если изменение логики парсера необходимо, вы можете прислать правки в pull-реквесте или завести feature-реквест в репозитории проекта.
Примеры URI для массива `sources`::
mysql://wordpress:1jobrRRjtLYs@localhost/wordpress
postgres://django:9%3F2%3D%40gHW@localhost:5432:/django
sqlite:///var/www/app/data/database.db
file:///var/www/html/
Примеры URI для `targets`::
file:/var/backup
ftp://jhon:%24t%D0%AFo%7C%5C%7C6@[fe80::5054:ff:fe24:382]:2021/backups/
rsync://backup_user@192.168.3.12:2022/backups
s3://my_bucket
Пароли содержащие специальные символы недопустимые в URI (включая пробелы) необходимо закодировать в percent code.
Python 2::
python2 -c "import urllib, sys; print urllib.quote(sys.argv[1], safe='')" 'PA$$WORD'
Python 3::
python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1], safe=''))" 'PA$$WORD'
Perl 5::
echo 'PA$$WORD' | perl -MURI::Escape -wlne 'print uri_escape $_'
Поддерживаемые протоколы и схемы URI
------------------------------------
Схемы, которые могут быть использованы как sources
``````````````````````````````````````````````````
file
Может содержать путь к локальному файлу или директории. Файлы архивируются при помощи ``tar`` и по умолчанию сжимаются с помощью ``gzip``. Примеры::
file:/var/www/html
file:///home/jhon/cool_stuff.txt
mysql
URI содержит реквизиты для подключения к БД MySQL/MariaDB. Формат::
mysql://[username[:password]@]hostname[:port]/database
С помощью утилиты ``mysqldump``\(1) формируется дамп в формате SQL, файл по умолчанию сжимается утилитой ``gzip``.
postgres
Аналогично `mysql`, но для PostgreSQL. Для создания дампа используется ``pg_dump``\(1), файлы по умолчанию сохраняются с расширением ".psql.gz".
sqlite
Схема для баз данных SQLite. Ничем не отличается от `file`, добавлена для наглядного обозначения, что источником является БД SQLite, а не иной файл.
Схемы, которые могут быть использованы как targets
``````````````````````````````````````````````````
file
См. описание выше. В контексте `targets` указывает директорию для сохранения архивов с файлами и базами данных.
ftp
Для выполнения загрузки файлов на удалённый FTP-сервер используется утилита GNU ``ftp``\(1).
sftp
OpenSSH File Transfer Protocol.
rsync
Rsync.
s3
Amazon S3 or any S3-compatible storage.
swift
OpenStack Swift.
sj
Storj DCS.
dav, davs
WebDAV.
Создание резервных копий
------------------------
Baf предполагает, что для всех резервных копий необходимо создавать архивы. Поэтому вам нужно следить за тем, чтобы в локальном хранилище всегда хватало дискового пространства для создания новых архивов. Baf также не удаляет старые архивы и вам также надо позаботиться об удалении устаревших резервных копий. Изменить это поведение можно с помощью пользовательских функций в сценариях. В этом разделе речь пойдёт о поведении, которое установлено в Baf по умолчанию.
Базовая концепция строится на том, что существует несколько точек источников и несколько точек назначения. Создаётся резервная копия источника и копируется в точку назначения.
Для всех источников в сценарии выполняется локальная резервная копия. После этого локальная копия переносится в удалённые точки назначения, если они заданы. Копирование локального бэкапа будет осуществлёно столько раз, сколько точек назначения задано. В каждом сценарии обязательно должен быть задан хотя бы один источник и одна точка назначения. При этом в списке точек назначения обязательно должна присутствовать точка со схемой `file`. Именно в неё будут сохранены архивы.
Пример. Имеется следующий сценарий::
sources=(
'mysql://wordpress:1jobrRRjtLYs@localhost/wordpress'
'file:///var/www/wordpress'
)
targets=(
'file:///var/backup'
'ftp://jhon:%24t%D0%AFo%7C%5C%7C6@[fe80::5054:ff:fe24:382]:2021/backups/'
)
Здесь будут созданы архивы файлов и базы данных и сохранены в локальную директорию /var/backup. Затем эти файлы будут переданы по протоколу FTP на сервер fe80::5054:ff:fe24:382 в директорию /backups. Файлы из директории /var/backup не будут удалены или перемещены. Если добавить дополнительную точку назначения, то файлы из /var/backup будут скопированы и туда. Обратите внимание, что Baf не выполняет повторного создания архивов для каждой точки назначения — архивы создаются один раз и далее распространяются по всем указанным назначениям. Если в массиве `targets` имеется несколько точек назначения со схемой `file`, то архивы будут сохранены в первую по порядку точку, а затем скопированы оттуда в остальные.
Потребление ресурсов
--------------------
Избегайте указания в одном сценарии точек назначения, которые ведут на примонтированный к локальной машине сетевой диск и другое удалённое хранилище одновременно. В таком случае архивы будут создаваться сразу на сетевом диске, что может существенно замедлить скорость их создания. Также при копировании файлов в другое удалённое хранилище будет выполняться двойная работа по сети, что тоже будет очень медленным.
Резервное копирование на удалённое хранилище
--------------------------------------------
FTP
```
SFTP
````
Rsync over SSH
``````````````
Rsync with rsyncd
`````````````````
Amazon S3
`````````
S3 compatible storage
`````````````````````
OpenStack Swift
```````````````
Storj DCS
`````````
WebDAV
``````
Переменные в сценариях
----------------------
Библиотека функций
------------------
Использование функций в сценариях
---------------------------------
See also
--------
``bash``\(1), ``tar``\(1), ``date``\(1), ``mysqldump``\(1), ``pg_dump``\(1)
RFC 3986 https://datatracker.ietf.org/doc/html/rfc3986