====== Резервное копирование информации ====== [[http://wiki.mihanik.net/doku.php?id=размышлизмы:резервное_копирование_информации&do=export_pdf|Экспорт в PDF ]] ~~ODT~~ Дата создания: 2021/12/19 07:44 (C) mihanik ===== Лирическое отступление. ===== Давно занимаюсь сопровождением информационных систем различных предприятий, давно сталкиваюсь с разными ситуациями, когда по разным причинам "рабочая информация" бывает повреждена настолько, что становится невозможным её использование. Соответственно, приходилось прибегать к восстановлению информации из резервной копии. Неоднократно. Сразу скажу, что за более чем 20 (двадцать!) лет работы мной не было потеряно **НИ ОДНОЙ БАЗЫ ДАННЫХ** моих клиентов. Соответственно, хочу описать основные принципы создания резервных копий, а также требования к организации резервного копирования. Системные администраторы делятся на тех кто не делает резервных копий, и тех, кто уже их делает. ===== Типы резервных копий ===== Для себя я выделяю два вида резервных копий: "горячая копия", "холодная копия". К каждому типу резервной копии у меня свои требования. ==== "Горяча копия" ==== Требования к резервной копии горячего типа: * Создаётся так часто, как этого требует бизнес. * Позволяет "откатиться" за минимальное количество времени (от нескольких минут до часа). * Расположена на быстрых носителях и "близко" к "месту использования". === Пояснения. === == Расположена на быстрых носителях и "близко" к "месту использования". == При возможности располагать горячую резервную копию следует или на том же сервере, где используется информация, или же на быстром сетевом хранилище, для связи с которым используются стандартные протоколы операционной системы. Например, **smb**, **cifs** и прочие. **Плюсы**: * "Близкое расположение" и использование стандартных протоколов обеспечит максимальную скорость создания резервной копии; * Скорость восстановления информации из горячей резервной копии будет максимальной. Конечно, в этом есть несколько минусов. **Минусы**: * Если копия расположена прямо на сервере, то это требует наличие достаточного пространства на дисках, что не всегда возможно; * Использование стандартных протоколов не защитит от воздействия вирусов-шифрователей или от "ручного повреждения" резервной копии злоумышленником. == Позволяет "откатиться" за минимальное количество времени (от нескольких минут до часа). == Тут пояснять нечего. Если копия "рядом", то и восстановить информацию из неё будет просто и быстро. == Создаётся так часто, как этого требует бизнес. == Тут тоже пояснять нечего. ==== "Холодная копия" ==== Требования к резервной копии холодного типа: * Создаётся так часто, как этого требует бизнес. * Позволяет уверенно "откатиться" на нужную дату. * Расположена НЕ на том же сервере, где используется информация. * При создании копии используются НЕСТАНДАРТНЫЕ протоколы, которые операционная система не поддерживает нативно. === Пояснения. === == Создаётся так часто, как этого требует бизнес. == Пояснений не требует. == Позволяет уверенно "откатиться" на нужную дату. == Система резервного копирования должна обеспечивать {{https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 | консистентность }} резервной копии, и, в случае её повреждения, возможность автоматизированной её "починки". Другими словами, мы должны быть уверены в том, что холодная резервная копия **НЕ ПОВРЕЖДЕНА**. Это не освобождает нас от регулярного проведения тестового восстановления информации из резервной копии с последующей проверкой на корректность/работоспособность == Расположена НЕ на том же сервере, где используется информация. == Тут всё просто. Это на тот случай, если в "основной" сервер попадёт "ядрёная бомба", сгорит материнская плата или "стуканут" диски локального файлового хранилища. == При создании копии используются НЕСТАНДАРТНЫЕ протоколы, которые операционная система не поддерживает нативно. == Например, если вы используете ОС Windows, то лучше использовать протоколы FTP, SSH и прочие. Это сделает невозможным повреждение резервной копии **вирусом-шифрователем** и **ЗНАЧИТЕЛЬНО ЗАТРУДНИТ** ручное повреждение информации злоумышленником в случае его несанкционированного проникновения на сервер. Однако! Не стоит забывать, что логины и пароли от таких "нестандартных подключений" следует хранить в полной тайне. ===== Как это обычно делаю я. ===== Горячую копию я делаю при помощи простейших операций. * Выгрузка базы 1С в DT-файл. * Создание резервных копий СУБД встроенными средствами. * Простое копирование файлов с "архивную папку". (Возможно, с применением архиватора) * и т.п.. Холодную копию в Windows я делаю при помощи {{ https://www.duplicati.com/ | Duplicati }}, а в Linux при помощи {{ https://duplicity.gitlab.io/duplicity-web/ | Duplicity }} Обе программы используют похожий подход к созданию резервной копии, обе позволяют создавать очень гибкие планы создания резервных копий, обе используют дедупликацию данных, что значительно уменьшает размеры резервной копии. Очень рекомендую! Про Duplicity можете почитать тут: https://habr.com/ru/company/selectel/blog/211170/ или на официальном сайте. Про Duplicati тут: https://ru.wikipedia.org/wiki/Duplicati или на официальном сайте. Программы замечательные. За всё время их использования ни разу не подвели! [[#top|⇑ Наверх ⇑]]