История изменений
Исправление Jameson, (текущая версия) :
перспектива сделать бэкап с «живой» файловой системой как вы выразились так и манит.
Это называется «снапшот». И для того чтобы бэкап был консистентным, ведь фс то у нас живая и блоки изменяются и записываются прямо во время и в процессе бэкапа, требуются дополнительные действия — нужно перед бэкапом сбросить на диск кэши и буферы, «заморозить» запись, пусть например блоки на запись в кэше накапливаются, пока бэкап не завершится и блочное устройство не разморозится, или через COW пишутся в другое место, на другое блочное устройство. После окончания бэкапа их можно будет обратно «объединить».
Это реализовано в LVM2, на уровне блоков, работает с любой ФС или без неё, например для RAW томов БД. А так же это часть функционала btrfs и zfs.
Ты по сути переизобретаешь снапшоты, не нужно, они уже изобретены. И ФС у тебя побилась потому что запись в процессе копирования не блокировалась. И кстати копия тоже неконсистентна и повреждена, по той же причине. Повреждения могут быть незначительными и малозаметными (побились временные файлы в хомяке и кэшах), или фатальными (развалился журнал например, ФС не монтируется) в зависимости от используемой ФС, кармы и погоды на Марсе. Так что в качестве бэкапа настолько грубый подход не годится, обессмысливает саму идею.
Никакой «хитрой» эвристики в dd нет — если пытаемся копировать блок в который в данный момент идет запись — получаем в зависимости от ключей и дефолтных настроек либо ошибку копирования, либо «битый» блок, то бишь образ тоже будет «битый», неконсистентный. Аналогично при попытке ФС писать в блок который в данный момент копируется — получаем «битый» файл, то бишь повреждённую ФС.
Исправление Jameson, :
перспектива сделать бэкап с «живой» файловой системой как вы выразились так и манит.
Это называется «снапшот». И для того чтобы бэкап был консистентным, ведь фс то у нас живая и блоки изменяются и записываются прямо во время и в процессе бэкапа, требуются дополнительные действия — нужно перед бэкапом сбросить на диск кэши и буферы, «заморозить» запись, пусть например блоки на запись в кэше накапливаются, пока бэкап не завершится и блочное устройство не разморозится, или через COW пишутся в другое место, на другое блочное устройство. После окончания бэкапа их можно будет обратно «объединить».
Это реализовано в LVM2, на уровне блоков, работает с любой ФС или без неё, например для RAW томов БД. А так же это часть функционала btrfs и zfs.
Ты по сути переизобретаешь снапшоты, не нужно, они уже изобретены. И ФС у тебя побилась потому что запись в процессе копирования не блокировалась. И кстати копия тоже неконсистентна и повреждена, по той же причине. Повреждения могут быть незначительными (побились временные файлы в хомяке и кэшах), или фатальными (развалился журнал например, ФС не монтируется) в зависимости от используемой ФС, кармы и погоды на Марсе. Потому что никакой «хитрой» эвристики в dd нет — если пытаемся копировать блок в который в данный момент идет запись — получаем в зависимости от ключей и дефолтных настроек либо ошибку копирования, либо «битый» блок, то бишь образ тоже будет «битый», неконсистентный. Аналогично при попытке ФС писать в блок который в данный момент копируется — получаем «битый» файл, то бишь повреждённую ФС.
Исправление Jameson, :
перспектива сделать бэкап с «живой» файловой системой как вы выразились так и манит.
Это называется «снапшот». И для того чтобы бэкап был консистентным, ведь фс то у нас живая и изменяется прямо во время и в процессе бэкапа, требуются дополнительные действия — нужно перед бэкапом сбросить на диск кэши и буферы, «заморозить» запись, пусть например блоки на запись в кэше накапливаются, пока бэкап не завершится и блочное устройство не разморозится, или через COW пишутся в другое место, на другое блочное устройство. После окончания бэкапа их можно будет обратно «объединить».
Это реализовано в LVM2, на уровне блоков, работает с любой ФС или без неё, например для RAW томов БД. А так же это часть функционала btrfs и zfs.
Ты по сути переизобретаешь снапшоты, не нужно, они уже изобретены. И ФС у тебя побилась потому что запись в процессе копирования не блокировалась. И кстати копия тоже неконсистентна и повреждена, по той же причине. Повреждения могут быть незначительными (побились временные файлы в хомяке и кэшах), или фатальными (развалился журнал например, ФС не монтируется) в зависимости от используемой ФС, кармы и погоды на Марсе.
Исходная версия Jameson, :
перспектива сделать бэкап с «живой» файловой системой как вы выразились так и манит.
Это называется «снапшот». И для того чтобы бэкап был консистентным, ведь фс то у нас живая и изменяется прямо во время и в процессе бэкапа, требуются дополнительные действия — нужно перед бэкапом сбросить на диск кэши и буферы, «заморозить» запись, пусть например блоки на запись в кэше накапливаются, пока бэкап не завершится, или через COW пишутся в другое место, на другое блочное устройство. После окончания бэкапа их можно будет обратно «объединить».
Это реализовано в LVM2, на уровне блоков, работает с любой ФС или без неё, например для RAW томов БД. А так же это часть функционала btrfs и zfs.
Ты по сути переизобретаешь снапшоты, не нужно, они уже изобретены. И ФС у тебя побилась потому что запись в процессе копирования не блокировалась. И кстати копия тоже неконсистентна и повреждена, по той же причине. Повреждения могут быть незначительными (побились временные файлы в хомяке и кэшах), или фатальными (развалился журнал например, ФС не монтируется) в зависимости от используемой ФС, кармы и погоды на Марсе.