= Сообщение: 4600 из 8555 ========================================= RU.LINUX =
От : Victor Sudakov 2:5005/49 06 Jan 18 00:20:32
Кому : Andrew Kant 06 Jan 18 00:20:32
Тема : Чем бэкапить RedHat Enterprise Linux Server 6 ?
FGHI : area://RU.LINUX?msgid=2:5005/49+5a4fb80a
На : area://RU.LINUX?msgid=2:469/83.1+5a4e6b6a
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.LINUX?msgid=2:469/83.1+5a4fd847
==============================================================================
Dear Andrew,
04 Jan 18 19:47, you wrote to me:
VS>> [dd]
VS>>>> В эхотаге стандартным средством бэкапа системы считается tar? Я
VS>>>> не ради флейма спрашиваю.
AK>>> Я не знаю, что считается стандартным, в линуксе нет хэндбука с
AK>>> подобными стандартами,
VS>> Как это нет хэндбука? То есть я понимаю, что общего хэндбука по
VS>> линуксу быть не может, но у уважающих себя дистрибутивов хэндбук
VS>> быть обязан, иначе какая же это OS (вспоминая многотомный
VS>> бумажный мануал по нетвари).
AK> Hу тогда иди читай красношляпный мануал :)
А это мысль. Закончатся новогодние праздники - пойду читать, может и насчет бэкапа что найдется, там с десяток книжек.
AK>>> но сам пользуюсь либо tar'ом (если нужно
AK>>> получить бэкап и сохранить его), либо rsync'ом (когда надо сразу
AK>>> получить клон).
VS>> tar и rsync нормально переносят симлинки, хардлинки, sparse файлы
VS>> и прочие особенности?
AK> линкивроде переносят без проблем, разряженных файлов у меня нет - не
AK> знаю. Возьми попробуй.
А у меня разряженных файлов бывает много - как минимум диски thin provisioned виртуалок. Плохо, если они раздуются до своих "виртуальных" размеров при восстановлении/переносе.
Попробовал: вроде хорошо:
[sudakov@vas ~/tmp] truncate -s5g test1g.bin
[sudakov@vas ~/tmp] du -hs !$
du -hs test1g.bin
512B test1g.bin
[sudakov@vas ~/tmp] mkdir QQQ1
[sudakov@vas ~/tmp] rsync -av test1g.bin QQQ1/
sending incremental file list
test1g.bin
sent 5,370,019,944 bytes received 35 bytes 202,642,263.36 bytes/sec
total size is 5,368,709,120 speedup is 1.00
[sudakov@vas ~/tmp] du -hs QQQ1/test1g.bin
512B QQQ1/test1g.bin
[sudakov@vas ~/tmp]
VS>>>> А как у тара с бэкапом живых файловых систем, или на ext4 можно
VS>>>> сделать
VS>>>> снапшот и его уже тарить?
AK>>> Обычно ext4 лежит поверх lvm, а вот lvm уже умеет снэпшоты.
А как lvm-ом сделать снапшот и смонтировать его, не покажешь?
VS>> Снэпшоты, которым пофиг на вышележащую файловую систему - это
VS>> плохие снэпшоты.
AK> ну-ну, и снэпшоты уровня стораджа типа нетапа итп - тоже плохие?
Конечно. Ты же читал мотивацию создания ZFS? Там прямо написано, что ставилась задача создать logical volume manager, который интегрирован с FS:
"ZFS is unusual, because unlike most other storage systems, it unifies both of these roles and acts as both the volume manager and the file system. Therefore, it has complete knowledge of both the physical disks and volumes (including their condition, status, their logical arrangement into volumes, and also of all the files stored on them). "
https://en.wikipedia.org/wiki/ZFS#ZFS_compared_to_most_other_file_systems
AK> С другой стороны, лучше плохо ехать, чем хорошо идти, так что и с
AK> плохими снэпшотами лучше, чем вообще без них, если знаешь где соломку
AK> стелить.
С этим не поспоришь.
AK>>> Hа счёт бэкапов живых файловых систем - как обычно, если нет
AK>>> средств у приложений как-то подготовиться, то можешь получить
AK>>> неконсистентное состояние. Hо здесь тебя ничего не спасёт -
AK>>> разве bsd-шный dump сможет тебе красиво сдампить файлы mysql
AK>>> если в них в этот момент что-то меняется?
VS>> Ответ, насколько я понимаю, скорее положительный: сможет. Потому
VS>> что dump использует ufs snapshots, а они создаются с учетом
VS>> операций записи в файлы, т.е. snapshot is FS-aware. Или он даже
VS>> приостанавливает запись на диск на момент создания снэпшота, я не
VS>> помню. Побочным следствием этого является тот факт, что при
VS>> активной записи на диск можно очень долго дожидаться окончания
VS>> создания снэпшота, у меня такое бывало.
AK> И откуда FS знает, что приложение записало всё что нужно на диск, а не
AK> оставило где-то в буферах?
Э, задача бэкапить что-то в буферах приложения и не ставилась. Мы же бэкапим диск, а не system state. Второе уже на порядки сложнее, если речь не о виртуалке.
AK> Такой "скорее положительный" ответ и для
AK> других методов, то есть как повезёт.
Если LVM не знает о FS, то больше шансов, что он создаст снапшот по-живому.
VS>> Hу и главное тут то, что процесс создания снапшота средствами fs
VS>> очень кратковременный, вероятность неконсистентного состояния
VS>> каких-то файлов явно меньше, чем если ты будешь полтора часа
VS>> тарить систему как есть - у тебя за это время может полсистемы
VS>> измениться, например обновления прилететь.
AK> Процесс создания снэпшота средствами lvm также очень кратковременный,
AK> а дальше ты снэпшот можешь тарить хоть год.
Надо будет попробовать этот lvm snapshot.
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322
* Origin: Ulthar (2:5005/49)
|
