Какие сейчас топовые программы для создания резервных копий в linux?

Question

[Павел]

Стоит сервер с апачем php и всеми вытекающими + свое облачное хранилище (nextcloud) , думаю как обезопасить себя от потери данных , надо все это дело целиком инкрементно бекапить , проблема в том что с линуксом не знаком , на винде использую AOMEI Backupper , надо что то простое , чтоб не выключая сервер копировало все данные , хотя можно и выключать , допустим в 3-4 часа ночи сделать бекап и запустить вновь , подскажите как правильно и безболезненно это сделать?

Answer 1

[Борис Сёмов]

rsnapshot + скрипт для резервного копирования ваших баз данных, например.

Answer 2

[Дмитрий]

Rsync, самописный скрипт, и ещё миллион вариантов.

Comments

[Павел]

а подскажите , если он копирует файлы , он копирует серверные файлы типа mysql в "активном" состоянии?

[Дмитрий]

Файлы копирует, естественно надо озаботиться что бы в файлы в этот момент никто не писал. С БД то же самое. Распространённый вариант - всё лежит на LVM, скрипт делает снапшота (если нужно ставит блокировки на базе данных), делает делает снапшота, (снимает блокировки, если были), монтирует снапшот и уже из него бекапит, после успешного бекапы удаляет снапшот.

[Борис Сёмов]

mrusklon, Нет. Они должны, либо с помощью mysqldump сниматься отдельно, либо чем-то вроде xtrabackup, но не копированием на ходу файлов данных, конечно.

А копируете вы только /etc, если не используете для этого уже какую-инбудь системы контроля версий или систему управления конфигурацией, и файлы ваших приложений, ну и может что-то ещё, например почту и.т.п. Всю систему копировать не нужно.
А если нужно, то это уже лучше делать с помощью снепшотов LVM, например, и там уже не идёт речь о инкриментальном копировании.

[Дмитрий]

Борис Сёмов, dump заставляет читать всю базу - от этого может сильно проседать производительность на длительное время (в зависимости от размера базы) Снапшот делается быстрее и во время бекапы производительность бд не проседает. НО, если база маленькая, можно и так.

[Борис Сёмов]

Дмитрий, Это даст гарантию консистентности данных, а LVM снапшот нет, без снимка памяти в то же время, например. К тому же, Когда данные из снапшота вы куда-то будете выгружать, то всё равно они все будут читаться, а если не будете, то наличие снапшотов режет производительность LVM. Природу не обмануть. =)

Для больших баз, я упомянул выше про xtrabackup у которого лучше с блокировками.

Answer 3

[Дмитрий Шицков]

Наилучший вариант - файловая система с поддержкой снапшотов (btrfs, zfs) совместно с rsync, к примеру. Так же, можно обойтись механизмом send/recive этих ФС.
Делаете снапшот на сервере и отправляете его на бекап-сервер. Для варианта с rsync, после этого на бекап-сервере можно сделать снапшот для версионирования бекапов. Для случая отправки в этом не будет нужды.

Однако, рекомендуется бекапть БД штатными и рекомендуемыми средствами конкретной СУБД

Comments

[Борис Сёмов]

Нет, не наилучший: Это затратно по месту, это затратно по трафику, это проблематично, если требуется восстановить не весь образ. К тому же, что btrfs, что zfs редко самый разумный выбор.

[АртемЪ]

Борис Сёмов,

Это затратно по месту

Разве снапшот занимает много места?

это затратно по трафику

Если использовать rsync или что-то подобное то в чем проблема? Передавайте только изменения.

это проблематично, если требуется восстановить не весь образ

Проблема выдернуть из снапшота нужные файлы?

К тому же, что btrfs, что zfs редко самый разумный выбор.

Ну вот с этим пожалуй соглашусь.

[Борис Сёмов]

АртемЪ, Вероятно, вы не поняли, что я имел в виду. Вы не передадите только сам снепшот, и не будете очевидно его хранить как замороженные изменения на удалённом диске. Т.е. нет, локально он не занимает много дополнительного места, но дело-то не в том. Передавать и хранить вы будете весь образ диска.

С трафиком тоже не всё так гладко - в одном случае, вы работаете с данными приложения, и возможно какими-нибудь конфигами, их суммарно заведомо меньше, чем всей информации на диске. В случае снапшотов, вы будете передавать заведомо больше изменений, даже если бы вы передавали все изменения всех файлов на диске - вы работаете уже уровнем ниже, чем файловая система, и изменений от образа к образу будет больше, чем от набора файлов к набору файлов, особенно, если мы об LVM.

Проблема выдернуть из снапшота нужные файлы?

Это не то, чтобы проблема, это просто заметно сложнее, чем взять уже готовый файл, в виде файла и хранящийся. И даже сложнее, чем достать его из архива, если сравнивать с заархивированным образом.

[Дмитрий Шицков]

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

А вот именно что передам только сам снапшот.

это просто заметно сложнее, чем взять уже готовый файл,

Равноценно - снапшоты в том же zfs доступны на уровне файловой подсистемы как каталоги. Достаточно зайти в каталог с нужной датой.

[Борис Сёмов]

Дмитрий Шицков, В случае ZFS send/recive, всё будет лучше чем в случае LVM снимков, конечно, но всё ещё хуже, чем в случае rsync части данных на диске, и по трафику, и по занимаемым объёмам. К тому же, область реальной разумной применимости ZFS не так уж велика, и платой за эти удобства будет память и быстродействие файловой системы.

Answer 4

[fdroid]

Как вариант, rdiffbackup и веб-интерфейс для него rdiffweb.