История изменений

И ZFS я в первую очередь предлагаю для сохранения данных различных разделов OS, в т.ч. системных, /home, и т.п.

Там где данные нужно «восстанавливать» - они восстанавливаются редеплоем по протоколу DR.

Если какой-то дурак затрет условно говоря /home/user1 а ты откатишь весь /home включая всех пользователей под ним - то тебя попросту уволят. А если ты собрался монтировать снапшот и восстанавливать оттуда данные для user1, то ты еще больший дурак, потому что для архивирования хомяков и отката раз в год, ФС со снапшотами и тормозами - дикий оверинжиниринг и ненужно. Это все делается rsync c `date` и чпунькается по NFS на бэкап-сервер, или просто на локальный бэкап-винт.

Очень смешно. Но у меня практики намного больше твоей, в т.ч. сопротивления попыткам уничтожения данных через РЭБ глушение шин компа, включая SATA.

Шпионских фильмов пересмотрел что ли. Иди что ли разбери кабель SATA и больше не неси здесь пургень.

Даже IBM предусмотрела сохранение данных в т.ч. и снэпшотами в Db2, но таким как ты объяснять бесполезно, что откат на снэпшот например в тестовой среде происходит во много раз быстрее восстановления из бэкапа.

Безусловно. Вот только тянет за собой то, что восстанавливать не нужно. Ну если ты собрался ради трех удаленных таблиц восстанавливать целый раздел на 512Гб - то ССЗБ.

Но промышленные СУБД - это исключение, где действительно есть достаточно надежные механизмы бэкапов, отработанные за десятилетия, чего не скажешь о большинстве других софтин.

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

Первая же атака ганстолкеров может легко уничтожить твои бэкапы данных без ZFS и без СУБД типа IBM Db2, которая в т.ч. и сама умеет в чексуммы.

Атаки гансракеров уничтожат и ZFS в том числе. Ни разу не видел реквестов в жире «напали гансракеры, нада восстановить все данные». Наверное процентов 90% реквестов звучат как «упс, удалил документик из папочки ~/Documents, помогите».

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

Сегодня один сервер закончил запись транзакций на цифре 5000 и похерился, другой сервер для этих 5000 транзакций записал детальную инфу, а ты такой умный взял и восстановил снапшот сделанный на 4000-ной транзакции, чем похерил детальную инфу для тыщи транзакций на втором сервере. MySQL тебе дурачку в этом случае скажет «Duplicate entry for key», банк уволит со взысканием, а государство вообще посадить может за вредительство.

RAID недостаточно, чтобы предотвратить потерю данных

Десятилетиями хватало, а теперь уже недостаточно. За свою практику поменял наверное больше тысячи битых дисков, и ни разу данные не потерялись. Но RAID изобрели лошары, да ?)

Короче, бросай эту дискуссию. Ради интереса сходи куда нибудь сюда https://www.phoronix.com/benchmark/result/2019_bcachefs_linux_benchmarks/fa51... и подумай почему никто в здравом уме не будет жертвовать производительностью, ради теоретической возможности восстановления ВСЕГО из какого-то там снапшота.

И ZFS я в первую очередь предлагаю для сохранения данных различных разделов OS, в т.ч. системных, /home, и т.п.

Там где данные нужно «восстанавливать» - они восстанавливаются редеплоем по протоколу DR.

Если какой-то дурак затрет условно говоря /home/user1 а ты откатишь весь /home включая всех пользователей под ним - то тебя попросту уволят. А если ты собрался монтировать снапшот и восстанавливать оттуда данные для user1, то ты еще больший дурак, потому что для архивирования хомяков и отката раз в год, ФС со снапшотами и тормозами - дикий оверинжиниринг и ненужно. Это все делается rsync c `date` и чпунькается по NFS на бэкап-сервер, или просто на локальный бэкап-винт.

Очень смешно. Но у меня практики намного больше твоей, в т.ч. сопротивления попыткам уничтожения данных через РЭБ глушение шин компа, включая SATA.

Шпионских фильмов пересмотрел что ли. Иди что ли разбери кабель SATA и больше не неси здесь пургень.

Даже IBM предусмотрела сохранение данных в т.ч. и снэпшотами в Db2, но таким как ты объяснять бесполезно, что откат на снэпшот например в тестовой среде происходит во много раз быстрее восстановления из бэкапа.

Безусловно. Вот только тянет за собой то, что восстанавливать не нужно. Ну если ты собрался ради трех удаленных таблиц восстанавливать целый раздел на 512Гб - то ССЗБ.

Но промышленные СУБД - это исключение, где действительно есть достаточно надежные механизмы бэкапов, отработанные за десятилетия, чего не скажешь о большинстве других софтин.

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

Первая же атака ганстолкеров может легко уничтожить твои бэкапы данных без ZFS и без СУБД типа IBM Db2, которая в т.ч. и сама умеет в чексуммы.

Атаки гансракеров уничтожат и ZFS в том числе. Ни разу не видел реквестов в жире «напали гансракеры, нада восстановить все данные». Наверное процентов 90% реквестов звучат как «упс, удалил документик из папочки ~/Documents, помогите».

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

Сегодня один сервер закончил запись транзакций на цифре 5000 и похерился, другой сервер для этих 5000 транзакций записал детальную инфу, а ты такой умный взял и восстановил снапшот сделанный на 4000-ной транзакции, чем похерил детальную инфу для тыщи транзакций на втором сервере. MySQL тебе дурачку в этом случае скажет «mysql duplicate entry for key», банк уволит со взысканием, а государство вообще посадить может за вредительство.

RAID недостаточно, чтобы предотвратить потерю данных

Десятилетиями хватало, а теперь уже недостаточно. За свою практику поменял наверное больше тысячи битых дисков, и ни разу данные не потерялись. Но RAID изобрели лошары, да ?)

Короче, бросай эту дискуссию. Ради интереса сходи куда нибудь сюда https://www.phoronix.com/benchmark/result/2019_bcachefs_linux_benchmarks/fa51... и подумай почему никто в здравом уме не будет жертвовать производительностью, ради теоретической возможности восстановления ВСЕГО из какого-то там снапшота.