Какие сейчас топовые программы для создания резервных копий в linux?
Стоит сервер с апачем php и всеми вытекающими + свое облачное хранилище (nextcloud) , думаю как обезопасить себя от потери данных , надо все это дело целиком инкрементно бекапить , проблема в том что с линуксом не знаком , на винде использую AOMEI Backupper , надо что то простое , чтоб не выключая сервер копировало все данные , хотя можно и выключать , допустим в 3-4 часа ночи сделать бекап и запустить вновь , подскажите как правильно и безболезненно это сделать?
Файлы копирует, естественно надо озаботиться что бы в файлы в этот момент никто не писал. С БД то же самое. Распространённый вариант - всё лежит на LVM, скрипт делает снапшота (если нужно ставит блокировки на базе данных), делает делает снапшота, (снимает блокировки, если были), монтирует снапшот и уже из него бекапит, после успешного бекапы удаляет снапшот.
mrusklon, Нет. Они должны, либо с помощью mysqldump сниматься отдельно, либо чем-то вроде xtrabackup, но не копированием на ходу файлов данных, конечно.
А копируете вы только /etc, если не используете для этого уже какую-инбудь системы контроля версий или систему управления конфигурацией, и файлы ваших приложений, ну и может что-то ещё, например почту и.т.п. Всю систему копировать не нужно.
А если нужно, то это уже лучше делать с помощью снепшотов LVM, например, и там уже не идёт речь о инкриментальном копировании.
Борис Сёмов, dump заставляет читать всю базу - от этого может сильно проседать производительность на длительное время (в зависимости от размера базы) Снапшот делается быстрее и во время бекапы производительность бд не проседает. НО, если база маленькая, можно и так.
Дмитрий, Это даст гарантию консистентности данных, а LVM снапшот нет, без снимка памяти в то же время, например. К тому же, Когда данные из снапшота вы куда-то будете выгружать, то всё равно они все будут читаться, а если не будете, то наличие снапшотов режет производительность LVM. Природу не обмануть. =)
Для больших баз, я упомянул выше про xtrabackup у которого лучше с блокировками.
Наилучший вариант - файловая система с поддержкой снапшотов (btrfs, zfs) совместно с rsync, к примеру. Так же, можно обойтись механизмом send/recive этих ФС.
Делаете снапшот на сервере и отправляете его на бекап-сервер. Для варианта с rsync, после этого на бекап-сервере можно сделать снапшот для версионирования бекапов. Для случая отправки в этом не будет нужды.
Однако, рекомендуется бекапть БД штатными и рекомендуемыми средствами конкретной СУБД
Нет, не наилучший: Это затратно по месту, это затратно по трафику, это проблематично, если требуется восстановить не весь образ. К тому же, что btrfs, что zfs редко самый разумный выбор.
АртемЪ, Вероятно, вы не поняли, что я имел в виду. Вы не передадите только сам снепшот, и не будете очевидно его хранить как замороженные изменения на удалённом диске. Т.е. нет, локально он не занимает много дополнительного места, но дело-то не в том. Передавать и хранить вы будете весь образ диска.
С трафиком тоже не всё так гладко - в одном случае, вы работаете с данными приложения, и возможно какими-нибудь конфигами, их суммарно заведомо меньше, чем всей информации на диске. В случае снапшотов, вы будете передавать заведомо больше изменений, даже если бы вы передавали все изменения всех файлов на диске - вы работаете уже уровнем ниже, чем файловая система, и изменений от образа к образу будет больше, чем от набора файлов к набору файлов, особенно, если мы об LVM.
Проблема выдернуть из снапшота нужные файлы?
Это не то, чтобы проблема, это просто заметно сложнее, чем взять уже готовый файл, в виде файла и хранящийся. И даже сложнее, чем достать его из архива, если сравнивать с заархивированным образом.
Дмитрий Шицков, В случае ZFS send/recive, всё будет лучше чем в случае LVM снимков, конечно, но всё ещё хуже, чем в случае rsync части данных на диске, и по трафику, и по занимаемым объёмам. К тому же, область реальной разумной применимости ZFS не так уж велика, и платой за эти удобства будет память и быстродействие файловой системы.
Простой
Простой
