На сколько безопасно дедуплицировать бэкапы?

Question

[Василий]

Окей, дедупликация - это создание ссылки на уже имеющиеся куски информации, короче - дюже умное сжатие.
Получается, что при дедупликации, если физическая копия информации, на которую ссылается 10 ссылок инкриментальных/диффиренциальных бэкапов, была повреждена при записи, то все эти 10 бэкапов, использующие ссылку на повреждённый участок, множатся на ноль? Да, я в курсе про 3-2-1, и тем не менее.
А если там три фулл бэкапа, то если был повреждён один это автоматически равно что все три повреждены в одном и том же месте?

Откуда вопрос взялся-то: решил улучшить систему бэкапирования, много читал, и периодически натыкался на "дедупликация помогает здорово экономить место на диске с бэкапами", или предложение использовать zfs как фс для хранения бэкапов.

Вопрос: это люди вообще бесстрашные, или я всё не правильно понимаю?
з.ы. бэкаплю bareOS если это имеет какое-то значение.

з.з.ы:
Всех благодарю за ответы! Очень помогли разобраться и вправить мозги на место)))

Answer 1

[aleks-th]

На этот вопрос нельзя однозначно ответить.
Да если идёт сбой то бекап накрывается медным тазом.

Но у тебя так же может и диск сдохнуть , и рейд, и файловая система, и ленточки размагнитится и вирус может все бэкапы зашифровать, так же может над серверной котельную прорвать, случится пожар, подача 380 вместо 220, сервер с бекапами могут украсть, владелец здания может ваше оборудование заблокирова, а ещё все это может произойти одновременно...

Вообще для бекапов нужно определится :

1. Что храним, и зачем, какая информация критична а какая не очень?
2. Объем данных?
3. С какой периодичностью делать бекапы?
4. Как проверяем что бэкап нормальный, как будем и за какое время разворачивать в случае чего?
5. Какие риски могут быть и как с ними будем бороться?
5. Сколько и кто за это платит?

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

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

Но перед этим все равно нужно рисовать схему и смотреть, что храним, как храним, и сколько готовы платить денег и времени за то что храним.

Comments

[Василий]

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

[Василий]

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

Answer 2

[mayton2019]

Боюсь что процесс дедупликации будет требовать ресурсов гораздо больше чем сам backup.

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

Из коробочных инструментов есть fdupes. Я им пользовался когда надо искать в большом архиве pdf
документов такие-же документы дубли или фолдеры-дубли. Но fdupes просто ставит более простую
задачу. Ищет полное совпадение всех файлов со всеми. Вот. А если ты будешь играться с дифференциальными
или прочими бэкапами то сложность твоей задачи еще более вырастает.

Comments

[Василий]

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

Вопрос, таки, о целесообразности этого мероприятия. Место сэкономить хочется, особенно смотря на то что данные могут дедуплицироваться и в двое, и в трое, и в десятеро при очень уж одинаковых данных, но блин, читаю об этом, и вообще не понимаю как можно даже задуматься о том, чтобы бэкапы держать на томах с дедупликацией, не говоря уже о том чтобы рассказывать это людям на полном серьёзе. Как говорится, авчёмсмысл?

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

[mayton2019]

Я тебе советую не париться вообще этим вопросом. Выигрыш будет сомнительный а зато нагрузку на дисковое оборудование ты создашь нехилую и потенциальные ошибки и damage может вылезти в конце совершенно нееби.... огромный короче.

Если тебе очень сильно хочется доказать выгоду твоей идеи - то сядь с бумажкой и каранадашом и попробуй в долларах посчитать полезный эффект. Я вообще сомневаюсь что он там будет. Вот. Я часто сам себя осаживаю такой мыслью. Чтоб руки не лишний раз не шалили. Я спрашиваю сам себя - я-бы за это заплатил? За риски. Зачем мне в пятницу вечером выскакивать из пивбара и ехать обратно в офис просто потому что база накрылась и дежурный девопс не может ее восстановить. Да и еще и наглец при этом тычет мне в мои последние изменения плана по дедубликации. В другое время - послал бы его к чорту и остался бы пить пиво со свинными ребрами но тут как-то не выходит. Вроде как моя технология дедубликации была внедрена. Значит надо ехать в офис.

[Василий]

mayton2019, )))))))
не, мне не нужно никому доказывать, как я скажу - так и будет (единственный эникей в конторе, я здесь власть!), и особенно не хочу использовать что-то не вполне надёжное. Да, почитав ответы, по итогу эту идею сливаю))
Может быть отдельно для файлшары что-то подобное настрою, там супермаленький объём, чисто для частого версионирования файлов на всякий случай.

[mayton2019]

Дедубликация может быть полезна для файловой шары где пользователи загружают фотки котиков. Например фото кота продублировалось дважды. Ты раз в сутки запускаешь сканер файлов. Он - просто берет контрольные суммы md5 (в стореджах MS-Blob / s3 это коробочная фича) из атрибутов файла и сводит двух котов к одному. Вот. Это вполне себе рабочий вариант. Особенно если там видео загружать. Экономия налицо.

Answer 3

[Drno]

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

Да, это всё жрет кучу места

Comments

[Василий]

голых? Диск клонзилой чтоли?

[Drno]

Василий, просто данные rsync копируешь и всё.
ну при желании можно и clonezilla делать, если есть возможность отключать сервер.

лично у меня все в lxc контейнерах. я либо бэкаплю их с помощью rsync, либо делаю lxc export

Answer 4

[pindschik]

Вот ситуация из практики - дедупликация средствами Windows Server, экономия дискового пространства порядка 60% (проектные данные, документы, личные файлы пользователей и т.п.), сжатый объем хранения - сейчас около 10 терабайт. За 10 лет ни одного случая косяков, кроме помирания дисков механически.
Естественно, что резервное копирование реализовано несколькими уровнями и на разные носители. Но сам по себе механизм дедупликации работает очень стабильно. По процессорной загрузке - не особо велика. Да и кто запрещает сделать расписание?
Смотря какие данные, сжатие будет разным, но возможно в то же хранилище вы сможете положить уже 2 (независимо друг от друга дедуплицированные) копии, вместо одной. Понятно, что лучше быть богатым и здоровым, чем бедным и больным - но вы видели ценовую разницу между диском на 10 Тб и на 25 Тб?

Comments

[Василий]

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

Answer 5

[CityCat4]

Ну, например у меня дедупликация экономит 90% места :)

Free: 1.90 TB
Used: 11.09 TB (997.2 GB can be reclaimed)
Deduplication: Enabled
Compression: Fast
Encryption: Disabled
Space savings: 94.0% (158.49 TB)
Automatic self-healing: Disabled

Испольузется Nakivo Backup & Replication. Да, его больше не купить и саппорта нет. И если репа сдохнет - то бэкапы накрылись. (Два раза за семь лет - бывало из-за бросков питания). Защита от этого проста - еще одна полка или сервер, куда бэкапы копируются.