Расскажу пару историй с ошибками бэкапов, с которыми столкнулся за последнее время. Я уже много раз рассказывал про свои подходы к созданию бэкапов. Вот примеры: 1, 2, 3, 4, 5, 6. Ничего нового не скажу, просто поделюсь своими историями.
Проблема номер 1. Есть сервер PBS для бэкапа виртуальных машин Proxmox. Бэкапы регулярно делаются, проходят проверку встроенными средствами, ошибок нет. Решаю проверить полное восстановление VM на новый сервер. Нашёл подходящий свободный сервер, подключил хранилище PBS, запустил восстановление виртуалки размером 450 Гб. А оно не проходит. Тупо ошибка:
в случайный момент времени. Ошибка неинформативная. Со стороны PBS просто:
Похоже на сетевую ошибку. Немного погуглил, увидел людей, которые сталкивались с похожими проблемами. Причины могут быть разными. У кого-то с драйвером сетевухи проблемы, какие-то настройки интерфейса меняют, у кого-то через VPN есть эта ошибка, без VPN нет. Я, кстати, по VPN каналу делал восстановление. Возможно, это мой случай.
Столкнуться с проблемами передачи такого большого файла через интернет вероятность очень большая. Никакой докачки нет. После ошибки, начинай всё заново. Поэтому я всегда делаю бэкап VM и в обязательном порядке сырых данных внутри этой виртуалки. Обычно с помощью rsync или чего-то подобного. Это позволит всегда иметь под рукой реальные данные без привязки к какой-то системе бэкапов, которая может тупо заглючить или умереть.
Хорошо, что это была просто проверка и у меня есть другие бэкапы данных. А если бы была авария и тут такой сюрприз в виде невозможности восстановиться. Кстати, бэкап на самом деле живой. Я вытащил из него данные через обзор файлов. Но целиком восстановить VM не получилось из-за каких-то сетевых проблем.
Проблема номер 2. События вообще в другом месте и никак не связаны. Разные компании. Появляется новый свободный сервер, который ещё не запустили в эксплуатацию. Решаю на него восстановить полную версию VM через Veeam Backup and Replication. Вим регулярное делает бэкапы, шлёт отчёты, бэкапы восстанавливаются через настроенную задачу репликации. То есть всё работает как надо.
Новый сервер в другой локации, с другой сетью, связь через VPN. Но тут сразу скажу, проблема не в этом. Запускаю восстановление, а оно раз за разом падает с ошибкой:
Налицо какая-то сетевая проблема, но не могу понять, в чём дело. SMB шара работает, доступна. Бэкапы туда складываются и разворачиваются планом репликации. На вид всё ОК.
Несколько дней я подходил к этой задаче и не мог понять, что не так. Решение пришло случайно. Я вспомнил, что NAS, с которого монтируется SMB шара, файрволом ограничен белым списком IP, которым разрешён доступ к данным. Я проверял с управляющей машины и реплицировал данные на сервера из этого списка, которые в одной локации. Проблем не было. А нового сервера в списках не было. Восстановление запускает агента на новом сервере и он напрямую от себя тянет данные с хранилища, а я думал, что через прокси на управляющей машине.
Хорошо, что всё это было выявлено во время проверки. А если бы всё грохнулось и я пытался бы восстановиться, то не факт, что вспомнил, в чём проблема, особенно в состоянии стресса. Столько бы кирпичей отложил, когда увидел, что бэкап не восстанавливается.
❗️В заключении скажу банальность - проверяйте бэкапы. Особенно большие VM и бэкапы баз данных.
#backup
Проблема номер 1. Есть сервер PBS для бэкапа виртуальных машин Proxmox. Бэкапы регулярно делаются, проходят проверку встроенными средствами, ошибок нет. Решаю проверить полное восстановление VM на новый сервер. Нашёл подходящий свободный сервер, подключил хранилище PBS, запустил восстановление виртуалки размером 450 Гб. А оно не проходит. Тупо ошибка:
restore failed: error:0A000119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../ssl/record/ssl3_record.c:622в случайный момент времени. Ошибка неинформативная. Со стороны PBS просто:
TASK ERROR: connection error: connection resetПохоже на сетевую ошибку. Немного погуглил, увидел людей, которые сталкивались с похожими проблемами. Причины могут быть разными. У кого-то с драйвером сетевухи проблемы, какие-то настройки интерфейса меняют, у кого-то через VPN есть эта ошибка, без VPN нет. Я, кстати, по VPN каналу делал восстановление. Возможно, это мой случай.
Столкнуться с проблемами передачи такого большого файла через интернет вероятность очень большая. Никакой докачки нет. После ошибки, начинай всё заново. Поэтому я всегда делаю бэкап VM и в обязательном порядке сырых данных внутри этой виртуалки. Обычно с помощью rsync или чего-то подобного. Это позволит всегда иметь под рукой реальные данные без привязки к какой-то системе бэкапов, которая может тупо заглючить или умереть.
Хорошо, что это была просто проверка и у меня есть другие бэкапы данных. А если бы была авария и тут такой сюрприз в виде невозможности восстановиться. Кстати, бэкап на самом деле живой. Я вытащил из него данные через обзор файлов. Но целиком восстановить VM не получилось из-за каких-то сетевых проблем.
Проблема номер 2. События вообще в другом месте и никак не связаны. Разные компании. Появляется новый свободный сервер, который ещё не запустили в эксплуатацию. Решаю на него восстановить полную версию VM через Veeam Backup and Replication. Вим регулярное делает бэкапы, шлёт отчёты, бэкапы восстанавливаются через настроенную задачу репликации. То есть всё работает как надо.
Новый сервер в другой локации, с другой сетью, связь через VPN. Но тут сразу скажу, проблема не в этом. Запускаю восстановление, а оно раз за разом падает с ошибкой:
Restore job failed. Error: The network path was not found. Failed to open storage for read access. Storage: [\\10.30.5.21\veeam\Office\OfficeD2024-05-23T040102_8E4F.vib]. Failed to restore file from local backup. VFS link: [summary.xml]. Target file: [MemFs://frontend::CDataTransferCommandSet::RestoreText_{f81d9dbd-ee5b-4a4e-ae58-744bb6f46a6b}]. CHMOD mask: [226]. Agent failed to process method {DataTransfer.RestoreText}.Налицо какая-то сетевая проблема, но не могу понять, в чём дело. SMB шара работает, доступна. Бэкапы туда складываются и разворачиваются планом репликации. На вид всё ОК.
Несколько дней я подходил к этой задаче и не мог понять, что не так. Решение пришло случайно. Я вспомнил, что NAS, с которого монтируется SMB шара, файрволом ограничен белым списком IP, которым разрешён доступ к данным. Я проверял с управляющей машины и реплицировал данные на сервера из этого списка, которые в одной локации. Проблем не было. А нового сервера в списках не было. Восстановление запускает агента на новом сервере и он напрямую от себя тянет данные с хранилища, а я думал, что через прокси на управляющей машине.
Хорошо, что всё это было выявлено во время проверки. А если бы всё грохнулось и я пытался бы восстановиться, то не факт, что вспомнил, в чём проблема, особенно в состоянии стресса. Столько бы кирпичей отложил, когда увидел, что бэкап не восстанавливается.
❗️В заключении скажу банальность - проверяйте бэкапы. Особенно большие VM и бэкапы баз данных.
#backup
Прочитал интересную серию статей Building A 'Mini' 100TB NAS, где человек в трёх частях рассказывает, как он себе домой NAS собирал и обновлял. Железо там хорошее для дома. Было интересно почитать.
Меня в третьей части привлёк один проект для создания хранилища с дублированием информации - SnapRAID. Я раньше не слышал про него. Это такая необычная штука не то бэкапилка, не то рейд массив. Наполовину и то, и другое. Расскажу, как она работает.
Образно SnapRAID можно сравнить с RAID 5 или RAID 6, но с ручной синхронизацией. И реализован он программно поверх уже существующей файловой системы.
Допустим, у вас сервер с четырьмя дисками. Вы хотите быть готовым к тому, что выход из строя одного из дисков не приведёт к потере данных. Тогда вы настраиваете SnapRAID следующим образом:
/mnt/diskp <- диск для контроля чётности
/mnt/disk1 <- первый диск с данными
/mnt/disk2 <- второй диск с данными
/mnt/disk3 <- третий диск с данными
Принцип получается как в обычном RAID5. Вы создаёте настройки для SnapRAID в
И после этого запускаете синхронизацию:
Данные на дисках могут уже присутствовать. Это не принципиально. SnapRAID запустит процесс пересчёта чётности файлов, как в обычном RAID 5. Только проходит это не в режиме онлайн, а после запуска команды.
После того, как вся чётность пересчитана, данные защищены на всех дисках. Если любой из дисков выйдет из строя, у вас будет возможность восстановить данные на момент последней синхронизации.
Звучит это немного странно и я до конца не могу осознать, как это работает, потому что толком не понимаю, как контроль чётности помогает восстанавливать файлы. Но в общем это работает. Получается классический RAID 5 с ручной синхронизацией.
Надеюсь основной принцип работы я передал. Насколько я понял, подобная штука может быть очень удобной для дома. К примеру, для хранения медиа контента, к которому доступ в основном в режиме чтения. Не нужны никакие рейд контроллеры и массивы. Берём любые диски, объединяем их в SnapRAID, синхронизируем данные раз в сутки по ночам и спокойно спим. Если выйдет из строя один диск, вы ничего не теряете. Имеете честный RAID 5 с ручной синхронизацией, что для дома приемлемо. Да и не только для дома. Можно ещё где-то придумать применение.
Одной из возможностей SnapRAID является создание некоего пула, который будет объединять символьными ссылками в режиме чтения данные со всех дисков в одну точку монтирования, которую можно расшарить в сеть. То есть берёте NAS из четырёх дисков. Один диск отдаёте на контроль чётности. Три Остальных заполняете, как вам вздумается. Потом создаёте пул, шарите его по сети, подключаете к телевизору. Он видит контент со всех трёх дисков.
Выглядит эта тема на самом деле неплохо. У меня дома как раз NAS на 4 диска и у меня там 2 зеркала RAID 1 на базе mdadm. В основном хранится контент для медиацентра, фотки и немного других файлов. Вариант со SnapRAID смотрится в этом случае более привлекательным, чем два рейд массива.
Я прочитал весь Getting Started. Настраивается и управляется эта штука очень просто. Небольшой конфиг и набор простых команд. Понятен процесс восстановления файлов, добавления новых дисков. Даже если что-то пойдёт не так, то больше данных, чем было на сломавшемся диске, вы не потеряете. Не выйдет так, что массив развалился и вы остались без данных, так как они лежат в исходном виде на файловой системе.
SnapRAID есть в составе openmediavault. Он там очень давно присутствует в виде плагина. Программа представляет из себя один исполняемый файл и конфигурацию к нему. Есть как под Linux, так и Windows.
⇨ Сайт / Исходники
#fileserver #backup
Меня в третьей части привлёк один проект для создания хранилища с дублированием информации - SnapRAID. Я раньше не слышал про него. Это такая необычная штука не то бэкапилка, не то рейд массив. Наполовину и то, и другое. Расскажу, как она работает.
Образно SnapRAID можно сравнить с RAID 5 или RAID 6, но с ручной синхронизацией. И реализован он программно поверх уже существующей файловой системы.
Допустим, у вас сервер с четырьмя дисками. Вы хотите быть готовым к тому, что выход из строя одного из дисков не приведёт к потере данных. Тогда вы настраиваете SnapRAID следующим образом:
/mnt/diskp <- диск для контроля чётности
/mnt/disk1 <- первый диск с данными
/mnt/disk2 <- второй диск с данными
/mnt/disk3 <- третий диск с данными
Принцип получается как в обычном RAID5. Вы создаёте настройки для SnapRAID в
/etc/snapraid.conf:parity /mnt/diskp/snapraid.paritycontent /var/snapraid/snapraid.contentcontent /mnt/disk1/snapraid.contentcontent /mnt/disk2/snapraid.contentdata d1 /mnt/disk1/data d2 /mnt/disk2/data d3 /mnt/disk3/И после этого запускаете синхронизацию:
# snapraid syncДанные на дисках могут уже присутствовать. Это не принципиально. SnapRAID запустит процесс пересчёта чётности файлов, как в обычном RAID 5. Только проходит это не в режиме онлайн, а после запуска команды.
После того, как вся чётность пересчитана, данные защищены на всех дисках. Если любой из дисков выйдет из строя, у вас будет возможность восстановить данные на момент последней синхронизации.
Звучит это немного странно и я до конца не могу осознать, как это работает, потому что толком не понимаю, как контроль чётности помогает восстанавливать файлы. Но в общем это работает. Получается классический RAID 5 с ручной синхронизацией.
Надеюсь основной принцип работы я передал. Насколько я понял, подобная штука может быть очень удобной для дома. К примеру, для хранения медиа контента, к которому доступ в основном в режиме чтения. Не нужны никакие рейд контроллеры и массивы. Берём любые диски, объединяем их в SnapRAID, синхронизируем данные раз в сутки по ночам и спокойно спим. Если выйдет из строя один диск, вы ничего не теряете. Имеете честный RAID 5 с ручной синхронизацией, что для дома приемлемо. Да и не только для дома. Можно ещё где-то придумать применение.
Одной из возможностей SnapRAID является создание некоего пула, который будет объединять символьными ссылками в режиме чтения данные со всех дисков в одну точку монтирования, которую можно расшарить в сеть. То есть берёте NAS из четырёх дисков. Один диск отдаёте на контроль чётности. Три Остальных заполняете, как вам вздумается. Потом создаёте пул, шарите его по сети, подключаете к телевизору. Он видит контент со всех трёх дисков.
Выглядит эта тема на самом деле неплохо. У меня дома как раз NAS на 4 диска и у меня там 2 зеркала RAID 1 на базе mdadm. В основном хранится контент для медиацентра, фотки и немного других файлов. Вариант со SnapRAID смотрится в этом случае более привлекательным, чем два рейд массива.
Я прочитал весь Getting Started. Настраивается и управляется эта штука очень просто. Небольшой конфиг и набор простых команд. Понятен процесс восстановления файлов, добавления новых дисков. Даже если что-то пойдёт не так, то больше данных, чем было на сломавшемся диске, вы не потеряете. Не выйдет так, что массив развалился и вы остались без данных, так как они лежат в исходном виде на файловой системе.
SnapRAID есть в составе openmediavault. Он там очень давно присутствует в виде плагина. Программа представляет из себя один исполняемый файл и конфигурацию к нему. Есть как под Linux, так и Windows.
⇨ Сайт / Исходники
#fileserver #backup
Я давно знаю и работаю с программой для бэкапа виртуальных сред Veeam Backup & Replication. Как всем известно, этот бренд ушёл из России, заблокировал доступ к своим ресурсам, не осуществляет продажи и не оказывает тех. поддержку. Полноценных аналогов с такой же функциональностью не так много. Я даже затрудняюсь назвать их, хотя наверняка есть, но мне не знакомы. То есть не работал с ними. Отечественные решения, насколько я знаю, по возможностям пока не дотягивают до Veeam.
Есть китайский аналог Vinchin Backup & Recovery. Я года два назад про него узнал, когда начались всевозможные санкции. Были пару обзоров от наших интеграторов КРОК и ГК ЛАНИТ. Причём отзывы вполне нормальные. В то же время на меня выходили сами разработчики и хотели какой-то кооперации: статьи, заметок в telegram, анонсов вебинаров и т.д. Был необычный опыт, так как общаться приходилось явно с не русскоязычным человеком, но мы понимали друг друга. Но всё как-то не срасталось по срокам и форматам.
Чтобы как-то предметно общаться, я решил всё же своими глазами посмотреть и попробовать этот продукт. К тому же на сайте есть русскоязычная версия с описанием, а список возможностей выглядит очень привлекательно. Можно объединить в единой системе бэкап вообще всей информации. Плюс поддержка отечественных ОС и систем виртуализации.
Есть полностью бесплатная версия для бэкапа трёх виртуальных машин. Не густо, конечно, но хоть что-то.
📌 Vinchin Backup & Recovery умеет бэкапить:
◽Виртуальные машины на различных гипервизорах и системах виртуализации. Список там очень внушительный, перечислю наиболее популярные и актуальные: zVirt, ROSA Virtualization, RED Virtualization, Hyper-V, Proxmox, VMware, Citrix, XCP-ng, oVirt, OpenStack
◽Базы данных популярных СУБД: MS SQL, MySQL, Oracle, PostgreSQL, MariaDB
◽Файлы в операционных системах Windows и Linux с помощью установленных агентов. Есть поддержка Astra Linux и RED OS.
◽Целиком операционные системы Windows и Linux, либо отдельные диски в них.
◽Сетевые диски, подключаемые по протоколам CIFS и NFS.
◽Microsoft Exchange как локальной установки, так и облачной.
◽Виртуальные машины облачного провайдера AWS EC2
Получается, он покрывает все варианты информации. Тут и виртуальные машины, и сервера через агентов, и сетевые диски, и СУБД.
Я развернул у себя эту систему. Ставится автоматически из готового ISO образа. Всё управление через веб интерфейс. Попробовал забэкапить и восстановить виртуальные машины на Hyper-V и Proxmox, а также сетевой диск.
Всё получилось практически сходу. Система простая, функциональная и удобная. Мне прям она вообще понравилась. Оформил всё в простой обзор с картинками, чтобы наглядно показать, как всё это выглядит на практике:
⇨ Обзор Vinchin Backup & Recovery
Если выбираете себе подобный продукт, то посмотрите Vinchin. Честно говоря, я с некоторым скепсисом её разворачивал, ожидая увидеть какие-то нелогичности, мелкие баги как интерфейса, так и самой работы, возможно ещё какие-то проблемы. Но на удивление, всё прошло гладко и ровно. Никаких ошибок я не заметил.
За скобками остался вопрос стоимости. Так как на сайте в открытом доступе цен нет, сказать мне об этом нечего. Все цены только по запросу. В лучших традициях, так сказать. Ну и ещё раз напомню, что есть бесплатная версия для бэкапа трёх виртуальных машин.
#backup
Есть китайский аналог Vinchin Backup & Recovery. Я года два назад про него узнал, когда начались всевозможные санкции. Были пару обзоров от наших интеграторов КРОК и ГК ЛАНИТ. Причём отзывы вполне нормальные. В то же время на меня выходили сами разработчики и хотели какой-то кооперации: статьи, заметок в telegram, анонсов вебинаров и т.д. Был необычный опыт, так как общаться приходилось явно с не русскоязычным человеком, но мы понимали друг друга. Но всё как-то не срасталось по срокам и форматам.
Чтобы как-то предметно общаться, я решил всё же своими глазами посмотреть и попробовать этот продукт. К тому же на сайте есть русскоязычная версия с описанием, а список возможностей выглядит очень привлекательно. Можно объединить в единой системе бэкап вообще всей информации. Плюс поддержка отечественных ОС и систем виртуализации.
Есть полностью бесплатная версия для бэкапа трёх виртуальных машин. Не густо, конечно, но хоть что-то.
📌 Vinchin Backup & Recovery умеет бэкапить:
◽Виртуальные машины на различных гипервизорах и системах виртуализации. Список там очень внушительный, перечислю наиболее популярные и актуальные: zVirt, ROSA Virtualization, RED Virtualization, Hyper-V, Proxmox, VMware, Citrix, XCP-ng, oVirt, OpenStack
◽Базы данных популярных СУБД: MS SQL, MySQL, Oracle, PostgreSQL, MariaDB
◽Файлы в операционных системах Windows и Linux с помощью установленных агентов. Есть поддержка Astra Linux и RED OS.
◽Целиком операционные системы Windows и Linux, либо отдельные диски в них.
◽Сетевые диски, подключаемые по протоколам CIFS и NFS.
◽Microsoft Exchange как локальной установки, так и облачной.
◽Виртуальные машины облачного провайдера AWS EC2
Получается, он покрывает все варианты информации. Тут и виртуальные машины, и сервера через агентов, и сетевые диски, и СУБД.
Я развернул у себя эту систему. Ставится автоматически из готового ISO образа. Всё управление через веб интерфейс. Попробовал забэкапить и восстановить виртуальные машины на Hyper-V и Proxmox, а также сетевой диск.
Всё получилось практически сходу. Система простая, функциональная и удобная. Мне прям она вообще понравилась. Оформил всё в простой обзор с картинками, чтобы наглядно показать, как всё это выглядит на практике:
⇨ Обзор Vinchin Backup & Recovery
Если выбираете себе подобный продукт, то посмотрите Vinchin. Честно говоря, я с некоторым скепсисом её разворачивал, ожидая увидеть какие-то нелогичности, мелкие баги как интерфейса, так и самой работы, возможно ещё какие-то проблемы. Но на удивление, всё прошло гладко и ровно. Никаких ошибок я не заметил.
За скобками остался вопрос стоимости. Так как на сайте в открытом доступе цен нет, сказать мне об этом нечего. Все цены только по запросу. В лучших традициях, так сказать. Ну и ещё раз напомню, что есть бесплатная версия для бэкапа трёх виртуальных машин.
#backup
Server Admin
Обзор Vinchin Backup & Recovery – инструмента для бэкапа всей...
Обзор, знакомство и первый опыт использования системы бэкапов Vinchin Backup & Recovery для физических и виртуальных сред.
Для тех, кто пользуется Proxmox Backup Server (PBS) важное предостережение. Я им пользуюсь практически с момента релиза, но только недавно столкнулся с проблемой. Не допускайте исчерпания свободного места на сервере с бэкапами.
Я краем уха слышал, что очистка от старых данных нетривиальная штука и нельзя просто взять, удалить ненужные бэкапы и освободить занятое место. Но сам с этим не сталкивался, так как обычно место планирую с запасом и настраиваю мониторинг. Так что своевременно предпринимаю какие-то действия.
А тут проспал. Точнее, неправильно отреагировал на сложившуюся ситуацию. Были видно, что место заканчивается. Я зашёл, удалил некоторые бэкапы в ожидании увеличения свободного объёма для хранения. Была сделана копия большой виртуалки, которая тоже поехала в архив. Рассчитывал, что благодаря дедупликации, реального места будет занято не так много. Но ошибся.
То ли место не успело освободиться, то ли дедупликация в реальности сработала не так, как я ожидал, но в итоге было занято 100% доступного объёма хранилища и все процессы в нём встали. Он даже сам себя очистить не мог. Процесс Garbage Collect не запускался из-за недостатка свободного места. Я решил вопрос просто - очистил логи systemd:
Они занимали несколько гигабайт, так что мне хватило для того, чтобы отработал процесс Garbage Collect. Но он не удаляет данные, а только помечает их к удалению. Реально данные будут удалены через 24 часа и 5 минут после того, как сборщик мусора пометит их на удаление. И никакого способа вручную запустить реальную очистку хранилища нет. По крайней мере я не нашёл.
Очень внимательно прочитал несколько тем на официальном форуме по этой проблеме и везде совет один - освобождайте место или расширяйте хранилище, если у вас zfs, запускайте сборщик мусора и ждите сутки. Других вариантов нет, кроме полного удаления Datastore со всеми бэкапами. Тогда место освободится сразу.
Это особенность реализации дедупликации в PBS. Помеченные на удаления chunks реально удаляются через 24 часа. Форсировать этот процесс не получится.
#proxmox #backup
Я краем уха слышал, что очистка от старых данных нетривиальная штука и нельзя просто взять, удалить ненужные бэкапы и освободить занятое место. Но сам с этим не сталкивался, так как обычно место планирую с запасом и настраиваю мониторинг. Так что своевременно предпринимаю какие-то действия.
А тут проспал. Точнее, неправильно отреагировал на сложившуюся ситуацию. Были видно, что место заканчивается. Я зашёл, удалил некоторые бэкапы в ожидании увеличения свободного объёма для хранения. Была сделана копия большой виртуалки, которая тоже поехала в архив. Рассчитывал, что благодаря дедупликации, реального места будет занято не так много. Но ошибся.
То ли место не успело освободиться, то ли дедупликация в реальности сработала не так, как я ожидал, но в итоге было занято 100% доступного объёма хранилища и все процессы в нём встали. Он даже сам себя очистить не мог. Процесс Garbage Collect не запускался из-за недостатка свободного места. Я решил вопрос просто - очистил логи systemd:
# journalctl --vacuum-size=256MОни занимали несколько гигабайт, так что мне хватило для того, чтобы отработал процесс Garbage Collect. Но он не удаляет данные, а только помечает их к удалению. Реально данные будут удалены через 24 часа и 5 минут после того, как сборщик мусора пометит их на удаление. И никакого способа вручную запустить реальную очистку хранилища нет. По крайней мере я не нашёл.
Очень внимательно прочитал несколько тем на официальном форуме по этой проблеме и везде совет один - освобождайте место или расширяйте хранилище, если у вас zfs, запускайте сборщик мусора и ждите сутки. Других вариантов нет, кроме полного удаления Datastore со всеми бэкапами. Тогда место освободится сразу.
Это особенность реализации дедупликации в PBS. Помеченные на удаления chunks реально удаляются через 24 часа. Форсировать этот процесс не получится.
#proxmox #backup
Судя по проведённым ранее опросам, большинство читателей канала администрируют системы под управлением Linux. Тем не менее, я заметил, что заметки о Windows всегда вызывают живой интерес и отклик. Люди либо тоскуют по винде, либо привирают о том, что её не администрируют 😁.
Сегодня будет заметка о неплохой бесплатной программе для бэкапа систем под управлением Windows, причём как обычных, так и серверных. Речь пойдёт про Hasleo Backup Suite Free. Я её установил и попробовал. Честно говоря, даже не понял, в чём тут подвох. Программа полностью бесплатна и при этом обладает очень неплохими возможностями. Кратко перечислю основные:
▪️ Бэкап на уровне всей системы, диска, раздела или набора файлов и директорий.
▪️ Клонирование системы, диска, разделов.
▪️ Тип бэкапов: полный, инкрементный, дифференцированный.
▪️ Поддержка расписания, политики хранения, очистки бэкапов.
▪️ Универсальное восстановление системы на другое железо.
▪️ Шифрование, проверка бэкапов.
▪️ Создание загрузочного образа на базе WinPE.
▪️ Логирование своей работы.
В этой системе есть всё, что ожидаешь от подобного продукта. Есть даже нормальный перевод на русский язык. Я на него посмотрел, явных ляпов не заметил, кроме разве что обозначения образа диска изображением. То есть монтировать не образ диска, а изображение диска. Она даже директории с бэкапами создаёт на русском языке: "Бэкап системы 20240903135711". В данном случае это скорее минус, чем плюс. Тут и русский язык, и пробелы. Лучше без этого обойтись и пользоваться английской версией.
Я проверил эту программу следующим образом:
1️⃣ Установил на систему и сделал полный бэкап на сетевую папку.
2️⃣ Через интерфейс программы создал загрузочный диск.
3️⃣ Создал чистую виртуалку, загрузился с загрузочного диска.
4️⃣ В загрузившейся системе назначил IP адрес, подключил сетевой диск.
5️⃣ Восстановил из сетевого диска образ системы.
На удивление всё прошло гладко, быстро и просто. Загрузочный диск удобнее, быстрее грузится, нежели то же самое от Veeam Agent For Windows, которым я регулярно пользуюсь.
В общем и целом программа понравилась. Из бесплатных точно одна из лучших. В целом, я даже не придумал, что в ней не хватает. Есть всё, что нужно, без каких-то излишеств. Рекомендую 👍
⇨ Сайт
#backup #windows
Сегодня будет заметка о неплохой бесплатной программе для бэкапа систем под управлением Windows, причём как обычных, так и серверных. Речь пойдёт про Hasleo Backup Suite Free. Я её установил и попробовал. Честно говоря, даже не понял, в чём тут подвох. Программа полностью бесплатна и при этом обладает очень неплохими возможностями. Кратко перечислю основные:
▪️ Бэкап на уровне всей системы, диска, раздела или набора файлов и директорий.
▪️ Клонирование системы, диска, разделов.
▪️ Тип бэкапов: полный, инкрементный, дифференцированный.
▪️ Поддержка расписания, политики хранения, очистки бэкапов.
▪️ Универсальное восстановление системы на другое железо.
▪️ Шифрование, проверка бэкапов.
▪️ Создание загрузочного образа на базе WinPE.
▪️ Логирование своей работы.
В этой системе есть всё, что ожидаешь от подобного продукта. Есть даже нормальный перевод на русский язык. Я на него посмотрел, явных ляпов не заметил, кроме разве что обозначения образа диска изображением. То есть монтировать не образ диска, а изображение диска. Она даже директории с бэкапами создаёт на русском языке: "Бэкап системы 20240903135711". В данном случае это скорее минус, чем плюс. Тут и русский язык, и пробелы. Лучше без этого обойтись и пользоваться английской версией.
Я проверил эту программу следующим образом:
1️⃣ Установил на систему и сделал полный бэкап на сетевую папку.
2️⃣ Через интерфейс программы создал загрузочный диск.
3️⃣ Создал чистую виртуалку, загрузился с загрузочного диска.
4️⃣ В загрузившейся системе назначил IP адрес, подключил сетевой диск.
5️⃣ Восстановил из сетевого диска образ системы.
На удивление всё прошло гладко, быстро и просто. Загрузочный диск удобнее, быстрее грузится, нежели то же самое от Veeam Agent For Windows, которым я регулярно пользуюсь.
В общем и целом программа понравилась. Из бесплатных точно одна из лучших. В целом, я даже не придумал, что в ней не хватает. Есть всё, что нужно, без каких-то излишеств. Рекомендую 👍
⇨ Сайт
#backup #windows
До меня докатилась новость о недавнем обновлении основного продукта Veeam - Veeam Backup & Replication. У них коммерческий продукт сейчас называется Veeam Data Platform, а бесплатная community версия так и осталась Veeam Backup & Replication Community Edition. Я перестал следить за их новостями с тех пор, как перешёл почти полностью на Proxmox и его продукт для бэкапа Proxmox Backup Server. Он закрывает базовые потребности малых и средних компаний. А Veeam Proxmox не поддерживал, поэтому и интереса не было.
Veeam решил повернуться в сторону KVM и в последнем релизе объявил поддержку систем виртуализации Nutanix и Proxmox VE. Из нового, там ещё отдельно поддержка MongoDB заявлена. На сегодняшний день это лидер рынка систем архивации данных, который поддерживает всё, что только можно: и облака, и гипервизоры, и СУБД, и отдельные системы. Он покрывает все популярные системы виртуализации: VMware, Microsoft Hyper‑V, Proxmox, Nutanix.
Решил посмотреть на бесплатную версию. У неё заявлены следующие ограничения:
This free gift from Veeam can protect up to 10 workloads: VMware, Hyper-V, Windows & Linux servers, laptops, NAS and more!
Насколько я понял, имеется ввиду 10 любых объектов для бэкапа. В принципе, средненькие ограничения, которые могут быть вполне функциональны для каких-то небольших или личных инфраструктур.
Для загрузки установщика нужна регистрация. Кому не хочется её проходить, вот прямая ссылка, можно ⇨ скачать. Доступ с адресов РФ закрыт, качать через VPN. Объём установщика солидный - 12 ГБ. Устанавливать нужно на систему Windows, в качестве СУБД будет установлена PostgreSQL. В 12-й версии есть возможность отказаться от MS SQL. В 13-й версии вангую отказ от Windows и переход на веб панель управления, как в Vinchin.
Интерфейс обновлённой 12-й версии привычен. Он вообще мало меняется от релиза к релизу. Как и логика работы. Сразу попробовал бэкап Proxmox VE. Для добавления сервера в консоль управления достаточно указать IP адрес и рутовый доступ по SSH. Далее было предложено создать служебную виртуалку на гипервизоре, которую Veeam будет поднимать через Cloud-Init во время бэкапа.
Дальше всё как обычно. Выполняется бэкап, восстановление возможно как на уровне всей системы, так и файлов на ней. В комментариях видел, кто-то писал, что восстановление на уровне файлов не работает. Я проверил, такая возможность есть, но реализована она следующим образом. Нужен какой-то промежуточный Linux хост, куда бэкап будет примонтирован для доступа к файлам. Туда ставится служба veeamagent и монтируется бэкап через fuse.
Я добавил для теста гипервизор Proxmox и Hyper-V. Забэкапил по паре виртуальных машин оттуда, ушло 4 лицензии.
Добавить про Veeam особо больше нечего. Продукт известный, лидер своей ниши. Мне лично он нравится за то, что можно забэкапить виртуалки, добавить в систему какой-нибудь старый сервер и настроить на него восстановление этих виртуалок с оповещением на почту. В итоге ты и бэкапы проверяешь и всегда имеешь под рукой актуальную копию виртуалки для различных задач.
С учётом нарастающего объёма блокировок и санкций, использовать Veeam не очень хочется, но лучше ничего нет. Так что решайте сами для себя, нужен он вам или нет. По возможностям даже бесплатной версии всё выглядит очень привлекательно. Позволяет объединить всю инфраструктуру в одном продукте. К примеру, несколько виртуалок и сетевой диск. Ну и на торрентах традиционно полные версии есть.
#backup
Veeam решил повернуться в сторону KVM и в последнем релизе объявил поддержку систем виртуализации Nutanix и Proxmox VE. Из нового, там ещё отдельно поддержка MongoDB заявлена. На сегодняшний день это лидер рынка систем архивации данных, который поддерживает всё, что только можно: и облака, и гипервизоры, и СУБД, и отдельные системы. Он покрывает все популярные системы виртуализации: VMware, Microsoft Hyper‑V, Proxmox, Nutanix.
Решил посмотреть на бесплатную версию. У неё заявлены следующие ограничения:
This free gift from Veeam can protect up to 10 workloads: VMware, Hyper-V, Windows & Linux servers, laptops, NAS and more!
Насколько я понял, имеется ввиду 10 любых объектов для бэкапа. В принципе, средненькие ограничения, которые могут быть вполне функциональны для каких-то небольших или личных инфраструктур.
Для загрузки установщика нужна регистрация. Кому не хочется её проходить, вот прямая ссылка, можно ⇨ скачать. Доступ с адресов РФ закрыт, качать через VPN. Объём установщика солидный - 12 ГБ. Устанавливать нужно на систему Windows, в качестве СУБД будет установлена PostgreSQL. В 12-й версии есть возможность отказаться от MS SQL. В 13-й версии вангую отказ от Windows и переход на веб панель управления, как в Vinchin.
Интерфейс обновлённой 12-й версии привычен. Он вообще мало меняется от релиза к релизу. Как и логика работы. Сразу попробовал бэкап Proxmox VE. Для добавления сервера в консоль управления достаточно указать IP адрес и рутовый доступ по SSH. Далее было предложено создать служебную виртуалку на гипервизоре, которую Veeam будет поднимать через Cloud-Init во время бэкапа.
Дальше всё как обычно. Выполняется бэкап, восстановление возможно как на уровне всей системы, так и файлов на ней. В комментариях видел, кто-то писал, что восстановление на уровне файлов не работает. Я проверил, такая возможность есть, но реализована она следующим образом. Нужен какой-то промежуточный Linux хост, куда бэкап будет примонтирован для доступа к файлам. Туда ставится служба veeamagent и монтируется бэкап через fuse.
Я добавил для теста гипервизор Proxmox и Hyper-V. Забэкапил по паре виртуальных машин оттуда, ушло 4 лицензии.
Добавить про Veeam особо больше нечего. Продукт известный, лидер своей ниши. Мне лично он нравится за то, что можно забэкапить виртуалки, добавить в систему какой-нибудь старый сервер и настроить на него восстановление этих виртуалок с оповещением на почту. В итоге ты и бэкапы проверяешь и всегда имеешь под рукой актуальную копию виртуалки для различных задач.
С учётом нарастающего объёма блокировок и санкций, использовать Veeam не очень хочется, но лучше ничего нет. Так что решайте сами для себя, нужен он вам или нет. По возможностям даже бесплатной версии всё выглядит очень привлекательно. Позволяет объединить всю инфраструктуру в одном продукте. К примеру, несколько виртуалок и сетевой диск. Ну и на торрентах традиционно полные версии есть.
#backup
Rsync - мощная консольная утилита и служба для быстрого копирования файлов. Отличает её в первую очередь скорость сравнения директорий с огромным количеством файлов. К примеру, если вам нужно будет сравнить и привести к единому содержимому два разнесённых по сети хранилища с миллионом файлов внутри, то rsync для этого подойдёт лучше, чем что-либо другое.
Расскажу про одну функциональность rsync, про которую, возможно, не все знают. Речь пойдёт про ключ
Суть в том, что rsync после копирования файлов удаляет их на стороне источника. Мне чаще всего это нужно, когда я локально делаю дампы баз данных. Они какое-то время лежат на сервере, где были сделаны, а потом с бэкап сервера запускается rsync, проходит по серверам, забирает с них дампы и удаляет за собой, после того, как скопирует.
Очень удобно. Не нужно на источниках настраивать автоочистку, с которой могут быть нюансы. Например, если бэкап по каким-то причинам не выполнялся, на источниках накапливаются файлы. А когда заработает снова, будут удаляться по мере копирования.
Выглядит итоговая команда для бэкапа примерно так:
Для тех, кто не привык колхозить автоматизацию бэкапов с помощью самодельных скриптов, есть готовые системы на базе Rsync. Я постарался рассмотреть практически все более ли менее известные. Вот они:
▪️ Butterfly Backup - консольная утилита Linux.
▪️ Rsnapshot - консольная утилита Linux.
▪️ ElkarBackup - сервис для бэкапов, написанный на PHP, настройка через браузер.
▪️ BackupPC - сервис для бэкапов, написанный на PERL, настройка через браузер.
▪️ Burp - сервис под Linux, более простой аналог Bacula.
▪️ cwRsyncServer Программа под Windows.
▪️ DeltaCopy Программа под Windows.
Забирайте в закладки. Для сырых данных rsync предоставляет наилучшую производительность и утилизацию канала. Особенно это заметно на большом количестве мелких файлов, или там, где большой файл изменяется незначительно. Алгоритм работы rsync позволяет не выкачивать весь файл заново, а только изменения.
#rsync #backup
Расскажу про одну функциональность rsync, про которую, возможно, не все знают. Речь пойдёт про ключ
--remove-sent-files. С этим ключом есть некоторая неоднозначность. В каких-то манах он представлен в таком виде, а где-то в виде --remove-source-files. Судя по описанию, это одно и то же. Я в своих скриптах использую --remove-sent-files. Суть в том, что rsync после копирования файлов удаляет их на стороне источника. Мне чаще всего это нужно, когда я локально делаю дампы баз данных. Они какое-то время лежат на сервере, где были сделаны, а потом с бэкап сервера запускается rsync, проходит по серверам, забирает с них дампы и удаляет за собой, после того, как скопирует.
Очень удобно. Не нужно на источниках настраивать автоочистку, с которой могут быть нюансы. Например, если бэкап по каким-то причинам не выполнялся, на источниках накапливаются файлы. А когда заработает снова, будут удаляться по мере копирования.
Выглядит итоговая команда для бэкапа примерно так:
/usr/bin/rsync --remove-sent-files --progress -av -e "ssh -p 31003 -i /home/user/.ssh/id_rsa" user@10.20.20.55:/home/bitrix/mysqlbackup/ /mnt/backup/site01/mysql-dump/
Для тех, кто не привык колхозить автоматизацию бэкапов с помощью самодельных скриптов, есть готовые системы на базе Rsync. Я постарался рассмотреть практически все более ли менее известные. Вот они:
▪️ Butterfly Backup - консольная утилита Linux.
▪️ Rsnapshot - консольная утилита Linux.
▪️ ElkarBackup - сервис для бэкапов, написанный на PHP, настройка через браузер.
▪️ BackupPC - сервис для бэкапов, написанный на PERL, настройка через браузер.
▪️ Burp - сервис под Linux, более простой аналог Bacula.
▪️ cwRsyncServer Программа под Windows.
▪️ DeltaCopy Программа под Windows.
Забирайте в закладки. Для сырых данных rsync предоставляет наилучшую производительность и утилизацию канала. Особенно это заметно на большом количестве мелких файлов, или там, где большой файл изменяется незначительно. Алгоритм работы rsync позволяет не выкачивать весь файл заново, а только изменения.
#rsync #backup
В недавнем цикле статей по LVM в комментариях всплывали вопросы так называемого Bit Rot или битового гниения. Это когда на носитель записан бит 1 или 0, а со временем по разным причинам он поменял своё значение. В конечном счёте эти изменения ведут к тому, что нужный файл хоть и нормально прочитается, но окажется "битым". Причём подвержены этим ошибкам все типы устройств хранения - от лент и CD до современных SSD. Я проверял свои старые записанные CD диски. Многие из них хоть и прочитались, но часть данных была безвозвратно утеряна или повреждена.
Защита от этого явления начинается с того, что данные у вас должны храниться в нескольких экземплярах. Если экземпляр один, то даже если вы узнаете о том, что файл побился, вам это никак не поможет.
Проще всего следить за целостностью файлов с помощью подсчёта контрольных сумм по тем или иным алгоритмам (CRC, MD5, SHA1 и т.д.) Есть много бесплатного софта, который автоматически может это выполнять и сравнивать по расписанию. В Linux такой софт обычно используется для контроля за системными файлами, чтобы определять несанкционированное изменение. Пример - Afick, Tripwire. Если у вас лежат файлы, с ними никто не работает, но изменилась контрольная сумма, значит возникли проблемы. Необходимо то же самое проверить на другом хранилище этих же файлов и если там контрольная сумма не менялась, значит тот файл оригинальный и стоит его восстановить из этой копии.
Некоторые файловые системы выполняют такие проверки в автоматическом режиме. Это заложено в их архитектуру. Пример - ZFS, Btrfs, ReiserFS, Ceph. Все эти файловые системы могут не только контролировать изменения, но и выполнять автоматическое восстановление повреждённых файлов, если хранилища на их основе собраны с избыточностью данных. То есть каждый файл хранится как минимум в двух или более копиях, для каждой из которых посчитана и сохранена контрольная сумма.
Важно понимать, что подобный контроль - не бесплатная операция. Она занимает системные ресурсы, как процессора, так и диска. И чем больше нагрузка на диск, тем больше ресурсов нужно. Перечисленные выше ФС обладают не только функциональностью контроля хэшей, но и многими другими, которые не обязательно будут нужны, но ресурсы они потребляют. Плюс, в них могут быть свои ошибки с вероятностью возникновения выше, чем Bit Rot. И стоит не забывать, что даже если вы возьмёте хранилище с ZFS или Ceph с контролем целостности файлов, это не освобождает вас от хранения этих же файлов где-то ещё.
Есть и другой механизм защиты файлов в Linux на основе контроля целостности - DM-integrity. С его помощью можно блочное устройство превратить в устройство с контролем целостности. А дальше с ним можно работать как с обычным диском - создавать разделы, тома Mdadm или Lvm. В случае нарушения целостности файла такое устройство будет возвращать Input/output error. Mdadm или LVM будут пытаться автоматически восстановить файл из копии, если хранилище обладает избыточностью данных, то есть собран рейд соответствующего уровня.
Таким образом мне не понятны претензии к Mdadm, Lvm или обычным файловым системам типа Ext4 или Xfs. Следить за целостностью файлов - не их задача. Где-то это будет слишком накладно, а где-то вообще не нужно. Если вам это необходимо, возьмите отдельный инструмент. В основном это актуально для долговременных хранилищ с холодными архивами.
☝️ Самая надёжная защита от Bit Rot - множественные копии. И тут очень важно соблюдать один принцип. Делать копию надо не от копии, а от оригинала данных. У вас есть исходное хранилище с данными, где они регулярно меняются. С него вы снимаете первый бэкап. Второй бэкап для другого хранилища надо снимать не с первого бэкапа, а тоже с исходного сервера. Иначе вы на все зависимые сервера принесёте битые файлы с первого бэкапа.
❓Для меня остался открытым другой вопрос. А как вообще понять, что у нас в хранилище файлы исправны, откроются и прочитаются? Как проверить изначальный источник правды для всех остальных копий?
#backup
Защита от этого явления начинается с того, что данные у вас должны храниться в нескольких экземплярах. Если экземпляр один, то даже если вы узнаете о том, что файл побился, вам это никак не поможет.
Проще всего следить за целостностью файлов с помощью подсчёта контрольных сумм по тем или иным алгоритмам (CRC, MD5, SHA1 и т.д.) Есть много бесплатного софта, который автоматически может это выполнять и сравнивать по расписанию. В Linux такой софт обычно используется для контроля за системными файлами, чтобы определять несанкционированное изменение. Пример - Afick, Tripwire. Если у вас лежат файлы, с ними никто не работает, но изменилась контрольная сумма, значит возникли проблемы. Необходимо то же самое проверить на другом хранилище этих же файлов и если там контрольная сумма не менялась, значит тот файл оригинальный и стоит его восстановить из этой копии.
Некоторые файловые системы выполняют такие проверки в автоматическом режиме. Это заложено в их архитектуру. Пример - ZFS, Btrfs, ReiserFS, Ceph. Все эти файловые системы могут не только контролировать изменения, но и выполнять автоматическое восстановление повреждённых файлов, если хранилища на их основе собраны с избыточностью данных. То есть каждый файл хранится как минимум в двух или более копиях, для каждой из которых посчитана и сохранена контрольная сумма.
Важно понимать, что подобный контроль - не бесплатная операция. Она занимает системные ресурсы, как процессора, так и диска. И чем больше нагрузка на диск, тем больше ресурсов нужно. Перечисленные выше ФС обладают не только функциональностью контроля хэшей, но и многими другими, которые не обязательно будут нужны, но ресурсы они потребляют. Плюс, в них могут быть свои ошибки с вероятностью возникновения выше, чем Bit Rot. И стоит не забывать, что даже если вы возьмёте хранилище с ZFS или Ceph с контролем целостности файлов, это не освобождает вас от хранения этих же файлов где-то ещё.
Есть и другой механизм защиты файлов в Linux на основе контроля целостности - DM-integrity. С его помощью можно блочное устройство превратить в устройство с контролем целостности. А дальше с ним можно работать как с обычным диском - создавать разделы, тома Mdadm или Lvm. В случае нарушения целостности файла такое устройство будет возвращать Input/output error. Mdadm или LVM будут пытаться автоматически восстановить файл из копии, если хранилище обладает избыточностью данных, то есть собран рейд соответствующего уровня.
Таким образом мне не понятны претензии к Mdadm, Lvm или обычным файловым системам типа Ext4 или Xfs. Следить за целостностью файлов - не их задача. Где-то это будет слишком накладно, а где-то вообще не нужно. Если вам это необходимо, возьмите отдельный инструмент. В основном это актуально для долговременных хранилищ с холодными архивами.
☝️ Самая надёжная защита от Bit Rot - множественные копии. И тут очень важно соблюдать один принцип. Делать копию надо не от копии, а от оригинала данных. У вас есть исходное хранилище с данными, где они регулярно меняются. С него вы снимаете первый бэкап. Второй бэкап для другого хранилища надо снимать не с первого бэкапа, а тоже с исходного сервера. Иначе вы на все зависимые сервера принесёте битые файлы с первого бэкапа.
❓Для меня остался открытым другой вопрос. А как вообще понять, что у нас в хранилище файлы исправны, откроются и прочитаются? Как проверить изначальный источник правды для всех остальных копий?
#backup
В заметках про Bit Rot, которое приводит к повреждению файлов при долговременном хранении, не хватало информации о том, как вообще можно смоделировать ситуацию, чтобы проверить настроенное хранилище.
Воздействовать на физическом уровне на устройства - задача нетривиальная. Но мне кажется, что можно действовать по-другому и получить схожий результат. Показываю по шагам свой эксперимент.
1️⃣ Для ускорения проведения экспериментов предлагаю всё делать на маленьких разделах диска. Покажу на примере mdadm raid1:
2️⃣ Заполняем весь раздел файлом:
Команда остановится с ошибкой, как только на диске закончится место.
3️⃣ Вычисляем хэш файла:
4️⃣ Запишем что-нибудь напрямую на блочное устройство. Чтобы точно попасть в созданный файл, я и сделал его во весь объём раздела.
Записали 1 блок размером 10 байт, отступив от начала 10 МБ или 100 МБ. Не помню точно, считается этот отступ в байтах или в размере блока.
5️⃣ Ещё раз проверяем хэш:
На удивление, он остался тем же. Я ожидал, что изменится.
6️⃣ Запускаем проверку целостности данных в массиве и когда закончится, смотрим результат:
У нас 128 несинхронизированных секторов. Точную причину проблем не посмотреть, но мы в данном случае знаем, что причина в том, что мы напрямую изменили часть данных.
7️⃣ Запускаем исправление ошибок:
Ждём по логу ядра окончание ремонта и смотрим ещё раз на количество ошибок:
Проверяем исходный файл:
Хэш не поменялся.
Я проводил несколько подобных экспериментов, меняя разные участки на блочном устройстве. Не всегда один repair приводил к исчезновению ошибок синхронизации, но после 2-х, 3-х раз они пропадали. И хэш файла всё время был один и тот же. Но если я через dd писал напрямую в md0:
То хэш неизменно менялся. Этот способ изменения файлов реально их меняет, хэш становится другим.
То же самое пробовал делать с массивом с включённым dm-integrity. Как и ожидается, массив получает ошибку хэша в определённом секторе:
А вот дальше я сталкивался в разных экспериментах с разным результатом. Это может не приводить ни к каким ошибкам, возникающие на некоторое время ошибки синхронизации через несколько минут сами пропадают без запуска принудительной синхронизации через repair. Хэш файла не меняется.
Но один раз я получил ошибку чтения файла, а в логе было следующее:
И так далее по кругу. То есть сектор был определён как повреждённый. Шла попытка взять его с другого диска, но там он тоже был с изменённой checksum. Не знаю, с чем это связано. Как-будто мое изменение успело синхронизироваться на второй диск и блока с правильным хэшем просто не осталось. В итоге файл вообще перестал открываться (Input/output error), его хэш нельзя было посмотреть.
Методику для тестов я вам показал. Можете помучать свои хранилища перед внедрением в эксплуатацию.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mdadm #backup
Воздействовать на физическом уровне на устройства - задача нетривиальная. Но мне кажется, что можно действовать по-другому и получить схожий результат. Показываю по шагам свой эксперимент.
# apt-get install mdadm# mdadm --create /dev/md0 -l 1 -n 2 /dev/sdb /dev/sdс# mkfs.ext4 /dev/md0# mount /dev/md0 /mnt# dd if=/dev/urandom of=/mnt/testfileКоманда остановится с ошибкой, как только на диске закончится место.
# md5sum /mnt/testfile4b1f1e62670849f08c975e9cab8cfd10 /mnt/testfile# dd if=/dev/urandom of=/dev/sdb seek=10000000 count=1 bs=10 conv=notruncЗаписали 1 блок размером 10 байт, отступив от начала 10 МБ или 100 МБ. Не помню точно, считается этот отступ в байтах или в размере блока.
# md5sum /mnt/testfile4b1f1e62670849f08c975e9cab8cfd10 /mnt/testfileНа удивление, он остался тем же. Я ожидал, что изменится.
# echo 'check' > /sys/block/md0/md/sync_action# cat /sys/block/md0/md/mismatch_cnt 128У нас 128 несинхронизированных секторов. Точную причину проблем не посмотреть, но мы в данном случае знаем, что причина в том, что мы напрямую изменили часть данных.
# echo 'repair' > /sys/block/md0/md/sync_actionЖдём по логу ядра окончание ремонта и смотрим ещё раз на количество ошибок:
# cat /sys/block/md0/md/mismatch_cnt0Проверяем исходный файл:
# md5sum /mnt/testfile4b1f1e62670849f08c975e9cab8cfd10 /mnt/testfileХэш не поменялся.
Я проводил несколько подобных экспериментов, меняя разные участки на блочном устройстве. Не всегда один repair приводил к исчезновению ошибок синхронизации, но после 2-х, 3-х раз они пропадали. И хэш файла всё время был один и тот же. Но если я через dd писал напрямую в md0:
# dd if=/dev/urandom of=/dev/md0 seek=10000000 count=1 bs=10 conv=notruncТо хэш неизменно менялся. Этот способ изменения файлов реально их меняет, хэш становится другим.
То же самое пробовал делать с массивом с включённым dm-integrity. Как и ожидается, массив получает ошибку хэша в определённом секторе:
device-mapper: integrity: dm-0: Checksum failed at sector 0xe88b8А вот дальше я сталкивался в разных экспериментах с разным результатом. Это может не приводить ни к каким ошибкам, возникающие на некоторое время ошибки синхронизации через несколько минут сами пропадают без запуска принудительной синхронизации через repair. Хэш файла не меняется.
Но один раз я получил ошибку чтения файла, а в логе было следующее:
device-mapper: integrity: dm-0: Checksum failed at sector 0x2b4f8
md/raid1:md0: dm-0: rescheduling sector 175144
device-mapper: integrity: dm-0: Checksum failed at sector 0x2b4f8
device-mapper: integrity: dm-1: Checksum failed at sector 0x2b4f8
md/raid1:md0: redirecting sector 175144 to other mirror: dm-1
device-mapper: integrity: dm-1: Checksum failed at sector 0x2b4f8И так далее по кругу. То есть сектор был определён как повреждённый. Шла попытка взять его с другого диска, но там он тоже был с изменённой checksum. Не знаю, с чем это связано. Как-будто мое изменение успело синхронизироваться на второй диск и блока с правильным хэшем просто не осталось. В итоге файл вообще перестал открываться (Input/output error), его хэш нельзя было посмотреть.
Методику для тестов я вам показал. Можете помучать свои хранилища перед внедрением в эксплуатацию.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mdadm #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
Расскажу об одной банальной вещи. Возможно кому-то она поможет, если в голову не приходило такое решение.
Ночь - время для обслуживания и бэкапов. Хорошо, когда ты за ночное окно успеваешь всё сделать и перекинуть данные на бэкап сервера. Но рано или поздно ночного окна начинает не хватать, особенно если бэкапы льются через интернет. Решать вопрос лучше всего комплексно, уменьшая объём передаваемых данных и двигая сервер с бэкапами ближе к источнику.
Если перечисленное выше не приводит к желаемому результату, то я настраиваю ограничение трафика. Вопрос этот непростой, если подразумевать полноценную приоритизацию на основе типов данных. Если ты не занимаешься этим вопросом постоянно, то довольно муторно вникать во все нюансы. Но конкретно в этой задаче не придётся сильно погружаться, так как я предлагаю просто ограничить в определённое время полосу пропускания на основе IP адреса сервера с бэкапами. А это самый простой случай.
В Mikrotik такое ограничение можно настроить с помощью Simple Queue. В шлюзах на базе Linux с помощью tc из пакета iproute2. В других шлюзах и роутерах этот как-то по-другому может решаться.
Для нормальной настройки шейпирования, чтобы не мешать привычной дневной работе, нужно обязательно иметь мониторинг полосы пропускания. Тот же Zabbix или Prometheus без особых проблем решают в типовых ситуациях эти вопросы. Надо знать среднюю загрузку канала и разрешить бэкапам литься с такой скоростью, чтобы днём не было полной утилизации полосы пропускания.
Я обычно делаю отдельные дашборды в мониторинге с загрузкой канала, чтобы во-первых, быстро оценить среднюю дневную загрузку, во-вторых, чтобы потом удобно контролировать загрузку, если бэкапы в ночь не успевают скопироваться.
Делается всё это обычно для того, чтобы если до утра задержится копирование, не парализовать работу. Если бэкапы уже сильно не успевают заливаться и уходят в день, то надо что-то менять. Потому что даже с таким ограничением они мешают полноценной работе. У тебя полезная ёмкость канала уменьшается.
#network #backup
Ночь - время для обслуживания и бэкапов. Хорошо, когда ты за ночное окно успеваешь всё сделать и перекинуть данные на бэкап сервера. Но рано или поздно ночного окна начинает не хватать, особенно если бэкапы льются через интернет. Решать вопрос лучше всего комплексно, уменьшая объём передаваемых данных и двигая сервер с бэкапами ближе к источнику.
Если перечисленное выше не приводит к желаемому результату, то я настраиваю ограничение трафика. Вопрос этот непростой, если подразумевать полноценную приоритизацию на основе типов данных. Если ты не занимаешься этим вопросом постоянно, то довольно муторно вникать во все нюансы. Но конкретно в этой задаче не придётся сильно погружаться, так как я предлагаю просто ограничить в определённое время полосу пропускания на основе IP адреса сервера с бэкапами. А это самый простой случай.
В Mikrotik такое ограничение можно настроить с помощью Simple Queue. В шлюзах на базе Linux с помощью tc из пакета iproute2. В других шлюзах и роутерах этот как-то по-другому может решаться.
Для нормальной настройки шейпирования, чтобы не мешать привычной дневной работе, нужно обязательно иметь мониторинг полосы пропускания. Тот же Zabbix или Prometheus без особых проблем решают в типовых ситуациях эти вопросы. Надо знать среднюю загрузку канала и разрешить бэкапам литься с такой скоростью, чтобы днём не было полной утилизации полосы пропускания.
Я обычно делаю отдельные дашборды в мониторинге с загрузкой канала, чтобы во-первых, быстро оценить среднюю дневную загрузку, во-вторых, чтобы потом удобно контролировать загрузку, если бэкапы в ночь не успевают скопироваться.
Делается всё это обычно для того, чтобы если до утра задержится копирование, не парализовать работу. Если бэкапы уже сильно не успевают заливаться и уходят в день, то надо что-то менять. Потому что даже с таким ограничением они мешают полноценной работе. У тебя полезная ёмкость канала уменьшается.
#network #backup
Недавно впервые услышал про новую для меня систему резервного копирования Minarca Backup. Беглый осмотр показал, что это что-то интересное, поэтому решил попробовать. Кратко скажу, что это open source клиент-серверная система с веб интерфейсом управления и локальными клиентами, которые нужно устанавливать на целевые машины, с которых снимается бэкап.
📌 Сделаю краткий акцент на основных моментах системы:
▪️сервер и клиенты можно установить на Liniux, Windows, MacOS;
▪️можно развернуть на своём железе;
▪️управление через cli или веб интерфейс;
▪️репозитории для хранения подключаются как локальные папки сервера;
▪️управлять доступом к бэкапам можно на уровне пользователей, поддерживается LDAP каталог для них, дисковые квоты;
▪️есть 2FA с отправкой кодов подтверждения на email;
▪️для установки сервера есть репозиторий с пакетами;
▪️данные от клиента на сервер передаются по протоколу HTTP с аутентификацией;
▪️бэкап выполняется на уровне файлов, нет возможности забэкапить всю систему разом или сделать образ диска;
▪️инициирует передачу данных на сервер сам клиент;
▪️клиент может самостоятельно инициировать восстановление своих файлов.
Установка сервера очень простая и типичная для готовых пакетов Debian:
Судя по зависимостям серверной части, Minarca Backup построена на базе rdiff-backup. Который, в свою очередь, является python обёрткой вокруг rsync (используется библиотека librsync). Она наследует всю скорость и быстроту синхронизации сотен тысяч файлов, которую обеспечивает rsync. Это чтобы вы понимали, что там под капотом и чего стоит ждать от этой системы. Как по мне, так это плюс, что там rsync используется. Для бэкапа сырых файлов без дедупликации это хорошее, а может и лучшее решение.
Теперь идём по IP адресу на порт 8080 и используем учётную запись: admin / admin123. По умолчанию веб интерфейс открылся на русском языке.
После этого сходил на страницу загрузки, скачал и установил для теста клиентов на Linux и Windows. Можно всех клиентов подключать под одной учёткой, либо для каждого сделать свою. Это зависит от вашей схемы инфраструктуры. Если бэкапите пользователей, логично каждому из них сделать свою учётную запись, чтобы он имел доступ только к своим бэкапам.
Windows клиента настроил через GUI, а для Linux сервера использовал команду для подключения к серверу:
Далее указал интервал для бэкапа и что бэкапим:
Последняя команда создала запись в crontab для пользователя, под которым её запустил. Теперь можно выполнить принудительный бэкап:
На сервере через веб интерфейс можно посмотреть забэкапленные файлы с обоих устройств.
Система относительно простая. Я практически сходу всё настроил и попробовал. Важно понимать, что она бэкапит только файлы, не системы целиком. Через клиент с GUI можно открыть календарь бэкапов, выбрать нужную дату, когда делался бэкап и восстановить файл.
Minarca Backup похожа частично на Kopia, но ещё больше на UrBackup, BackupPC и ElkarBackup. Причём я затрудняюсь сказать, какая из них лучше. На первый взгляд кажется, что они все примерно одного уровня, где-то одна лучше, где-то другая. Ну и нужно понимать, что сравнивать их с профессиональными платными системами от Veeam, Symantec и т.д. нет никакого смысла. Это разного уровня софт.
⇨ 🌐 Сайт / Исходники / Обзор
#backup #rsync
📌 Сделаю краткий акцент на основных моментах системы:
▪️сервер и клиенты можно установить на Liniux, Windows, MacOS;
▪️можно развернуть на своём железе;
▪️управление через cli или веб интерфейс;
▪️репозитории для хранения подключаются как локальные папки сервера;
▪️управлять доступом к бэкапам можно на уровне пользователей, поддерживается LDAP каталог для них, дисковые квоты;
▪️есть 2FA с отправкой кодов подтверждения на email;
▪️для установки сервера есть репозиторий с пакетами;
▪️данные от клиента на сервер передаются по протоколу HTTP с аутентификацией;
▪️бэкап выполняется на уровне файлов, нет возможности забэкапить всю систему разом или сделать образ диска;
▪️инициирует передачу данных на сервер сам клиент;
▪️клиент может самостоятельно инициировать восстановление своих файлов.
Установка сервера очень простая и типичная для готовых пакетов Debian:
# curl -L https://www.ikus-soft.com/archive/minarca/public.key | gpg --dearmor > /usr/share/keyrings/minarca-keyring.gpg# echo "deb [arch=amd64 signed-by=/usr/share/keyrings/minarca-keyring.gpg] https://nexus.ikus-soft.com/repository/apt-release-$(lsb_release -sc)/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/minarca.list# apt update# apt install minarca-serverСудя по зависимостям серверной части, Minarca Backup построена на базе rdiff-backup. Который, в свою очередь, является python обёрткой вокруг rsync (используется библиотека librsync). Она наследует всю скорость и быстроту синхронизации сотен тысяч файлов, которую обеспечивает rsync. Это чтобы вы понимали, что там под капотом и чего стоит ждать от этой системы. Как по мне, так это плюс, что там rsync используется. Для бэкапа сырых файлов без дедупликации это хорошее, а может и лучшее решение.
Теперь идём по IP адресу на порт 8080 и используем учётную запись: admin / admin123. По умолчанию веб интерфейс открылся на русском языке.
После этого сходил на страницу загрузки, скачал и установил для теста клиентов на Linux и Windows. Можно всех клиентов подключать под одной учёткой, либо для каждого сделать свою. Это зависит от вашей схемы инфраструктуры. Если бэкапите пользователей, логично каждому из них сделать свою учётную запись, чтобы он имел доступ только к своим бэкапам.
Windows клиента настроил через GUI, а для Linux сервера использовал команду для подключения к серверу:
# minarca configure -r http://10.20.1.36:8080/ -u admin -p admin123 -n debian-serverДалее указал интервал для бэкапа и что бэкапим:
# minarca include /etc# minarca schedule --dailyПоследняя команда создала запись в crontab для пользователя, под которым её запустил. Теперь можно выполнить принудительный бэкап:
# minarca backup --forceНа сервере через веб интерфейс можно посмотреть забэкапленные файлы с обоих устройств.
Система относительно простая. Я практически сходу всё настроил и попробовал. Важно понимать, что она бэкапит только файлы, не системы целиком. Через клиент с GUI можно открыть календарь бэкапов, выбрать нужную дату, когда делался бэкап и восстановить файл.
Minarca Backup похожа частично на Kopia, но ещё больше на UrBackup, BackupPC и ElkarBackup. Причём я затрудняюсь сказать, какая из них лучше. На первый взгляд кажется, что они все примерно одного уровня, где-то одна лучше, где-то другая. Ну и нужно понимать, что сравнивать их с профессиональными платными системами от Veeam, Symantec и т.д. нет никакого смысла. Это разного уровня софт.
⇨ 🌐 Сайт / Исходники / Обзор
#backup #rsync
Очередное напоминание-предостережение на тему бэкапов. Она просто вечная. Если вы делаете бэкапы, но не проверяете их работоспособность и просто возможность восстановления, это значит, что у вас их нет. Я не раз сталкивался с ситуацией, когда администратор делал бэкапы, но не разворачивал их. Когда случилась поломка, оказалось, что оперативно запустить работу системы из бэкапа не получается. Он просто не знает, как это сделать.
Бэкапы делались на уровне виртуальной машины. Когда умер гипервизор (а подменного точно такого же не было), восстановление на другой не увенчалось успехом. Виртуальная машина не стартовала. Я оперативно починил это, так как часто сталкивался с различными проблемами такого рода. Конкретно тут нужно было накатить другое ядро и обновить initramfs.
❗️Как я рекомендую организовать бэкап:
1️⃣ Бэкап виртуальной машины. К нему должна быть инструкция по восстановлению, где будет подробно указано, что и в какой последовательности делать, на какое железо восстанавливать. Соответственно, железо это должно быть.
2️⃣ Бэкап на уровне данных. Делать обязательно в дополнение к бэкапу виртуальных машин. Обычно бэкап виртуальной машины – это огромный файл. С ним могут быть различные проблемы. Он может долго копироваться, он может побиться при копировании или создании (сталкивался многократно). Его восстановление может длиться часами. Если у вас есть сырые данные, вы можете оперативно их предоставить хотя бы частично и запустить в работу, либо заранее копировать на подменный сервер из резерва.
3️⃣ Для бэкапов должен быть настроен мониторинг. Как его сделать – решать по месту. Обычно для файлов это проверка даты изменения в бэкапе и его объем, либо анализ созданных заранее меток для проверки. Если это бэкап через специализированную программу, то в качестве мониторинга могут выступать успешные уведомления о создании бэкапа, а не просто отправка писем при ошибке. Может банально не работать сама служба бэкапов или почтовый сервер, а вы будете думать, что у вас всё в порядке.
Когда все три пункта выполнены, можно более-менее спокойно жить и думать о проверке и разнесении территориально бэкапов. Это отдельная большая тема. Я по возможности настраиваю хранение бэкапов в двух различных локациях, помимо основной с исходными данными. Более подробно обо всём этом писал в статье:
⇨ Как правильно делать бэкапы и следить за ними
Информация там в основном теоретическая, так что не потеряла актуальности. Но есть и ссылки на конкретные материалы с реализацией отдельных функциональностей.
#совет #backup
Бэкапы делались на уровне виртуальной машины. Когда умер гипервизор (а подменного точно такого же не было), восстановление на другой не увенчалось успехом. Виртуальная машина не стартовала. Я оперативно починил это, так как часто сталкивался с различными проблемами такого рода. Конкретно тут нужно было накатить другое ядро и обновить initramfs.
❗️Как я рекомендую организовать бэкап:
1️⃣ Бэкап виртуальной машины. К нему должна быть инструкция по восстановлению, где будет подробно указано, что и в какой последовательности делать, на какое железо восстанавливать. Соответственно, железо это должно быть.
2️⃣ Бэкап на уровне данных. Делать обязательно в дополнение к бэкапу виртуальных машин. Обычно бэкап виртуальной машины – это огромный файл. С ним могут быть различные проблемы. Он может долго копироваться, он может побиться при копировании или создании (сталкивался многократно). Его восстановление может длиться часами. Если у вас есть сырые данные, вы можете оперативно их предоставить хотя бы частично и запустить в работу, либо заранее копировать на подменный сервер из резерва.
3️⃣ Для бэкапов должен быть настроен мониторинг. Как его сделать – решать по месту. Обычно для файлов это проверка даты изменения в бэкапе и его объем, либо анализ созданных заранее меток для проверки. Если это бэкап через специализированную программу, то в качестве мониторинга могут выступать успешные уведомления о создании бэкапа, а не просто отправка писем при ошибке. Может банально не работать сама служба бэкапов или почтовый сервер, а вы будете думать, что у вас всё в порядке.
Когда все три пункта выполнены, можно более-менее спокойно жить и думать о проверке и разнесении территориально бэкапов. Это отдельная большая тема. Я по возможности настраиваю хранение бэкапов в двух различных локациях, помимо основной с исходными данными. Более подробно обо всём этом писал в статье:
⇨ Как правильно делать бэкапы и следить за ними
Информация там в основном теоретическая, так что не потеряла актуальности. Но есть и ссылки на конкретные материалы с реализацией отдельных функциональностей.
#совет #backup
Server Admin
Как правильно делать бэкапы и следить за ними | serveradmin.ru
Написать данную заметку меня побудила ситуация вокруг хостера ihor.ru, с которым я сотрудничаю уже лет 5. Еще летом у них начались какие-то проблемы, а сейчас они вылились в открытое...
Расскажу про одну старую и известную бесплатную программу для бэкапов под Windows – AOMEI Backupper Standard. Давно у меня в закладках лежит. Регулярно вижу про неё упоминания в комментариях и некоторых чатах. Это Freeware версия коммерческой программы. При этом у неё даже в бесплатной редакции хорошие возможности, которых для многих будет достаточно.
📌 Основные возможности Freeware версии AOMEI Backupper Standard:
▪️Бэкап на уровне файлов, разделов, дисков, всей системы.
▪️Типы бэкапов: полный, инкрементный, посекторный.
▪️Умеет бэкапить на локальный или внешний USB диск, сетевую папку (только по SMB)
▪️Синхронизация каталогов.
▪️Восстановление системы с использованием загрузочного ISO на базе WinPE или Linux. Причём Linux версия работает без UEFI, на обычном BIOS.
▪️Клонирование разделов и дисков, в том числе посекторное.
▪️Уведомления по email.
▪️Работа только на десктопных версиях Windows, серверные не поддерживаются.
Я установил и попробовал эту программу. В целом всё работает очень просто. Сделал бэкап на сетевую папку, создал загрузочный диск, закинул его на гипервизор, загрузился с него и сделал восстановление с сетевого диска. Попробовал диск и на WinPE, и на Linux. Последний образ весит всего 45 МБ.
Но могу сразу сказать, что у неё есть очень похожий бесплатный аналог – Hasleo Backup Suite Free, который лично мне понравился больше. В первую очередь тем, что там в интерфейсе нет опций с пометкой Pro, за которые надо платить.
При этом стоит отметить, что у AOMEI Backupper чуть больше возможностей. Из тех, что заметил я, это:
🔹Выбор загрузочного диска на базе Linux или WinPE.
🔹Возможность интегрировать в загрузочный диск на базе WinPE необходимые драйвера.
🔹Функциональность по синхронизации каталогов, в том числе по расписанию.
Последняя возможность довольно полезная и может быть актуальна. Эта же функциональность есть у бесплатной программы FreeFileSync, но очевидно, что в рамках одной программы иметь всю необходимую функциональность удобнее.
⇨ 🌐 Сайт
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #windows
📌 Основные возможности Freeware версии AOMEI Backupper Standard:
▪️Бэкап на уровне файлов, разделов, дисков, всей системы.
▪️Типы бэкапов: полный, инкрементный, посекторный.
▪️Умеет бэкапить на локальный или внешний USB диск, сетевую папку (только по SMB)
▪️Синхронизация каталогов.
▪️Восстановление системы с использованием загрузочного ISO на базе WinPE или Linux. Причём Linux версия работает без UEFI, на обычном BIOS.
▪️Клонирование разделов и дисков, в том числе посекторное.
▪️Уведомления по email.
▪️Работа только на десктопных версиях Windows, серверные не поддерживаются.
Я установил и попробовал эту программу. В целом всё работает очень просто. Сделал бэкап на сетевую папку, создал загрузочный диск, закинул его на гипервизор, загрузился с него и сделал восстановление с сетевого диска. Попробовал диск и на WinPE, и на Linux. Последний образ весит всего 45 МБ.
Но могу сразу сказать, что у неё есть очень похожий бесплатный аналог – Hasleo Backup Suite Free, который лично мне понравился больше. В первую очередь тем, что там в интерфейсе нет опций с пометкой Pro, за которые надо платить.
При этом стоит отметить, что у AOMEI Backupper чуть больше возможностей. Из тех, что заметил я, это:
🔹Выбор загрузочного диска на базе Linux или WinPE.
🔹Возможность интегрировать в загрузочный диск на базе WinPE необходимые драйвера.
🔹Функциональность по синхронизации каталогов, в том числе по расписанию.
Последняя возможность довольно полезная и может быть актуальна. Эта же функциональность есть у бесплатной программы FreeFileSync, но очевидно, что в рамках одной программы иметь всю необходимую функциональность удобнее.
⇨ 🌐 Сайт
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #windows
Я обновил популярную подборку со своего сайта:
⇨ Топ бесплатных программ для бэкапа
Обновил не в плане актуализировал все описания, хотя некоторые поправил и насытил дополнительной информацией, а просто дополнил статью всеми программами, что были упомянуты в моём канале по этой теме. Я не представляю, как эту подборку можно актуализировать. Слишком хлопотно всё это перепроверять и обновлять описания. Тем более с учётом того, что она постоянно увеличивается.
Даже в таком виде статья информативна. Если подбираете себе бесплатный инструмент для бэкапа, то подборка поможет быстро сориентироваться в том, что есть, посмотреть алгоритмы, основные возможности, поддерживаемые платформы, наличие веб интерфейса и т.д.
Плюс, к каждому продукту есть ссылка на обсуждение в Telegram канале, где есть в том числе отзывы и рекомендации от тех, кто пользовался. Именно поэтому я прошу не флудить в комментариях и не превращать чат в болталку. Иногда удаляю то, что считаю бесполезным для читателей (мемы, картинки, ссоры и т.д.), чтобы не занимать зря их время и внимание.
Если считаете, что какой-то полезной программы не хватает, пишите в комментариях здесь или на сайте. Я буду дополнять. Не хватает какого-то хорошего софта для бэкапа виртуальных машин. Я кроме Proxmox Backup Server и Veeam Backup & Replication Community Edition ничего не припоминаю из этой области. Есть Vinchin Backup & Recovery, но там бесплатная версия очень куцая.
В этом обновлении добавил туда Hasleo Backup Suite Free, Minarca Backup, AOMEI Backupper Standard, Proxmox Backup Client, Rdiff-backup, nxs-backup, Veeam Backup & Replication Community Edition, Proxmox Backup Server, Vinchin Backup & Recovery. Обновил информацию по Veeam Agent for Windows or Linux Free, Cobian Backup, Kopia.
Полный список софта из статьи:
◽️Hasleo Backup Suite Free
◽️Minarca Backup
◽️Veeam Agent for Windows or Linux Free
◽️Kopia
◽️Burp
◽️Syncthing
◽️Borgbackup или Borg
◽️Clonezilla и Rescuezilla
◽️BackupPC
◽️UrBackup
◽️Butterfly Backup
◽️DeltaCopy
◽️Cobian Backup
◽️FreeFileSync
◽️Rclone
◽️Bup
◽️ReaR
◽️Restic
◽️ElkarBackup
◽️FBackup
◽️AOMEI Backupper Standard
◽️Proxmox Backup Client
◽️Rdiff-backup
◽️NXS-backup
◽️Veeam Backup & Replication Community Edition
◽️Proxmox Backup Server
◽️Vinchin Backup & Recovery
В планах всё это как-то упорядочить по различным признакам и объединить в одну таблицу с основными характеристиками. Но нужно время, чтобы всё это обработать. На деле это не такая простая задача, как может показаться.
#backup #подборка
⇨ Топ бесплатных программ для бэкапа
Обновил не в плане актуализировал все описания, хотя некоторые поправил и насытил дополнительной информацией, а просто дополнил статью всеми программами, что были упомянуты в моём канале по этой теме. Я не представляю, как эту подборку можно актуализировать. Слишком хлопотно всё это перепроверять и обновлять описания. Тем более с учётом того, что она постоянно увеличивается.
Даже в таком виде статья информативна. Если подбираете себе бесплатный инструмент для бэкапа, то подборка поможет быстро сориентироваться в том, что есть, посмотреть алгоритмы, основные возможности, поддерживаемые платформы, наличие веб интерфейса и т.д.
Плюс, к каждому продукту есть ссылка на обсуждение в Telegram канале, где есть в том числе отзывы и рекомендации от тех, кто пользовался. Именно поэтому я прошу не флудить в комментариях и не превращать чат в болталку. Иногда удаляю то, что считаю бесполезным для читателей (мемы, картинки, ссоры и т.д.), чтобы не занимать зря их время и внимание.
Если считаете, что какой-то полезной программы не хватает, пишите в комментариях здесь или на сайте. Я буду дополнять. Не хватает какого-то хорошего софта для бэкапа виртуальных машин. Я кроме Proxmox Backup Server и Veeam Backup & Replication Community Edition ничего не припоминаю из этой области. Есть Vinchin Backup & Recovery, но там бесплатная версия очень куцая.
В этом обновлении добавил туда Hasleo Backup Suite Free, Minarca Backup, AOMEI Backupper Standard, Proxmox Backup Client, Rdiff-backup, nxs-backup, Veeam Backup & Replication Community Edition, Proxmox Backup Server, Vinchin Backup & Recovery. Обновил информацию по Veeam Agent for Windows or Linux Free, Cobian Backup, Kopia.
Полный список софта из статьи:
◽️Hasleo Backup Suite Free
◽️Minarca Backup
◽️Veeam Agent for Windows or Linux Free
◽️Kopia
◽️Burp
◽️Syncthing
◽️Borgbackup или Borg
◽️Clonezilla и Rescuezilla
◽️BackupPC
◽️UrBackup
◽️Butterfly Backup
◽️DeltaCopy
◽️Cobian Backup
◽️FreeFileSync
◽️Rclone
◽️Bup
◽️ReaR
◽️Restic
◽️ElkarBackup
◽️FBackup
◽️AOMEI Backupper Standard
◽️Proxmox Backup Client
◽️Rdiff-backup
◽️NXS-backup
◽️Veeam Backup & Replication Community Edition
◽️Proxmox Backup Server
◽️Vinchin Backup & Recovery
В планах всё это как-то упорядочить по различным признакам и объединить в одну таблицу с основными характеристиками. Но нужно время, чтобы всё это обработать. На деле это не такая простая задача, как может показаться.
#backup #подборка
Server Admin
Топ бесплатных программ для бэкапа | serveradmin.ru
Подборка бесплатных программ для бэкапа. Краткое описание, возможности, отзывы реальных людей об использовании.
Очень простая и быстрая в настройке утилита для бэкапа GIT репозиториев. Можно использовать как для бэкапа куда-то локально или в S3, так и для копирования из одного репозитория в другой. Речь пойдёт про open source проект gickup.
Сразу покажу на примере, как я забэкапил к себе локально несколько своих закрытых репозиториев на публичном gitlab.
Создаю конфигурационный файл
Для получения token сходил в Preferences ⇨ Access tokens и создал personal access token с доступом только на чтение. В своём примере я забэкапил только 3 репозитория: gatus, scripts, configs. Если их не указать, забэкапит все.
Запускаю бэкап:
Вот и всё. Gickup поддерживает все популярные платформы для хостинга git, как публичные, так и приватные:
- Github
- Gitlab
- Gitea
- Gogs
- Bitbucket
- Onedev
- Sourcehut
В качестве источников для сохранения или копирования поддерживает их же, плюс:
- локальная директория
- S3 хранилище
Настройка источников и приёмников отражена в документации. Там всё кратко и по делу. Список параметров невелик. У меня сразу всё получилось.
Очень простой и быстрый способ копировать репозитории в одно или несколько мест одновременно. Дополнительно gickup умеет отправлять уведомления о своей работе в ntfy, gotify и apprise. Также может локально логи писать и отправлять метрики в Prometheus. Правда не очень понял какие. Не проверял это.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#git #backup #devops
Сразу покажу на примере, как я забэкапил к себе локально несколько своих закрытых репозиториев на публичном gitlab.
# wget https://github.com/cooperspencer/gickup/releases/download/v0.10.38/gickup_0.10.38_linux_amd64.tar.gz# tar xzvf gickup_0.10.38_linux_amd64.tar.gzСоздаю конфигурационный файл
conf.yml:source:
gitlab:
- token: glpat-GtPuYrBvnxxkTFsq-Y
url: https://gitlab.com/
user: zeroxzed
include:
- gatus
- scripts
- configs
wiki: true
issues: true
destination:
local:
- path: /home/zerox/backup-gitlab
structured: true
keep: 5
Для получения token сходил в Preferences ⇨ Access tokens и создал personal access token с доступом только на чтение. В своём примере я забэкапил только 3 репозитория: gatus, scripts, configs. Если их не указать, забэкапит все.
Запускаю бэкап:
# ./gickup conf.ymlВот и всё. Gickup поддерживает все популярные платформы для хостинга git, как публичные, так и приватные:
- Github
- Gitlab
- Gitea
- Gogs
- Bitbucket
- Onedev
- Sourcehut
В качестве источников для сохранения или копирования поддерживает их же, плюс:
- локальная директория
- S3 хранилище
Настройка источников и приёмников отражена в документации. Там всё кратко и по делу. Список параметров невелик. У меня сразу всё получилось.
Очень простой и быстрый способ копировать репозитории в одно или несколько мест одновременно. Дополнительно gickup умеет отправлять уведомления о своей работе в ntfy, gotify и apprise. Также может локально логи писать и отправлять метрики в Prometheus. Правда не очень понял какие. Не проверял это.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#git #backup #devops
У меня уже были заметки про фишки LVM, сегодня расскажу про ещё одну, которая может пригодиться. С помощью LVM и снепшотов можно делать консистентные бэкапы баз данных Mysql на уровне файлов, а не дампов, практически без простоя. Для таких задач в СУБД Percona есть инструмент под названием XtraBackup, а вот если у вас обычная бесплатная MySQL или MariaDB, то с бэкапами на уровне файлов там не так всё просто, особенно если вы уже не можете делать дампы из-за их больших размеров.
Идея там вот в чём. Мы закрываем все открытые таблицы, сбрасываем кэш, блокируем изменение данных, после этого делаем снепшот раздела с базами данных и сразу отключаем блокировки. Это занимает буквально пару секунд, на которые блокируются все базы, а потом спокойно копируем файлы сервера, примонтировав снепшот.
Это всё хорошо работало до появления движка InnoDB. У него есть нюансы, когда блокировки не предотвращают изменение данных в таблицах. Нужно дополнительно сбрасывать на диск так называемые dirty_pages. Покажу всё это на практике. Способ немного костыльный и вряд ли подойдёт для прода, так как есть много нюансов. Но в каких-то ситуациях может помочь быстро снять консистентную копию без остановки сервера.
Для того, чтобы всё получилось, раздел, где хранятся данные MySQL сервера, должен располагаться на LVM, а в Volume Group должно быть свободное место для снепшотов. Проверяем так:
Если места нет, надо добавить. Не буду на этом останавливаться, рассказывал ранее. Первым делом заходим в консоль mysql, сбрасываем кэш и включаем блокировки:
Если база не сильно большая и нагруженная, кэш быстро сбросится. Наблюдать можно так:
Следим за значением
После этого возвращаем обратно настройку с dirty_pages в исходное значение (по умолчанию 90) и снимаем блокировки:
Когда это делается автоматически скриптом, всё это происходит быстро. Но есть нюансы. Команда блокировки дожидается завершения всех запросов. Если у вас там есть какие-то очень длинные запросы, то вся база будет заблокирована, пока они не завершатся. Так что имейте это ввиду.
Монтируем снепшот и копируем данные:
После копирования снепшот надо обязательно удалить.
Получили консистентный бэкап всех баз данных практически без остановки сервера, но с кратковременной блокировкой изменений.
Я собрал всё это в скрипт и протестировал на сервере с MariaDB и Zabbix Server. Сохранил бэкап локально, потом остановил MariaDB, полностью удалил директорию
Скрипт особо не отлаживал, так что аккуратнее с ним. Просто убедился, что работает. Сначала немного накосячил, так как после включения блокировки закрывал сессию, делал снепшот и подключался снова. Так нельзя, потому что команда
Такой вот небольшой трюк в копилку LVM, который можно применять не только к СУБД, но и другим данным.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#lvm #mysql #backup
Идея там вот в чём. Мы закрываем все открытые таблицы, сбрасываем кэш, блокируем изменение данных, после этого делаем снепшот раздела с базами данных и сразу отключаем блокировки. Это занимает буквально пару секунд, на которые блокируются все базы, а потом спокойно копируем файлы сервера, примонтировав снепшот.
Это всё хорошо работало до появления движка InnoDB. У него есть нюансы, когда блокировки не предотвращают изменение данных в таблицах. Нужно дополнительно сбрасывать на диск так называемые dirty_pages. Покажу всё это на практике. Способ немного костыльный и вряд ли подойдёт для прода, так как есть много нюансов. Но в каких-то ситуациях может помочь быстро снять консистентную копию без остановки сервера.
Для того, чтобы всё получилось, раздел, где хранятся данные MySQL сервера, должен располагаться на LVM, а в Volume Group должно быть свободное место для снепшотов. Проверяем так:
# pvsЕсли места нет, надо добавить. Не буду на этом останавливаться, рассказывал ранее. Первым делом заходим в консоль mysql, сбрасываем кэш и включаем блокировки:
> SET GLOBAL innodb_max_dirty_pages_pct = 0;> FLUSH TABLES WITH READ LOCK;Если база не сильно большая и нагруженная, кэш быстро сбросится. Наблюдать можно так:
> SHOW ENGINE INNODB STATUS\G;Следим за значением
Modified db pages. Оно должно стать 0. После этого можно делать снэпшот:# lvcreate --size 5G --snapshot --name mysql_snapshot /dev/vgroup/rootПосле этого возвращаем обратно настройку с dirty_pages в исходное значение (по умолчанию 90) и снимаем блокировки:
> SET GLOBAL innodb_max_dirty_pages_pct = 90;> UNLOCK TABLES;Когда это делается автоматически скриптом, всё это происходит быстро. Но есть нюансы. Команда блокировки дожидается завершения всех запросов. Если у вас там есть какие-то очень длинные запросы, то вся база будет заблокирована, пока они не завершатся. Так что имейте это ввиду.
Монтируем снепшот и копируем данные:
# mkdir /mnt/mysql_backup# mount /dev/vgroup/mysql_snapshot /mnt/mysql_backup# rsync -avz --delete /mnt/mysql_backup/var/lib/mysql/ user@10.20.1.5:/mnt/backup/mysql/После копирования снепшот надо обязательно удалить.
# umount /mnt/mysql_backup# lvremove -f /dev/vgroup/mysql_snapshotПолучили консистентный бэкап всех баз данных практически без остановки сервера, но с кратковременной блокировкой изменений.
Я собрал всё это в скрипт и протестировал на сервере с MariaDB и Zabbix Server. Сохранил бэкап локально, потом остановил MariaDB, полностью удалил директорию
/var/lib/mysql и восстановил из бэкапа. Потом запустил СУБД. Запустилось без проблем, никаких ошибок. Бэкап получается консистентный.Скрипт особо не отлаживал, так что аккуратнее с ним. Просто убедился, что работает. Сначала немного накосячил, так как после включения блокировки закрывал сессию, делал снепшот и подключался снова. Так нельзя, потому что команда
FLUSH TABLES WITH READ LOCK живёт, пока открыто соединение. Надо в рамках него делать всё необходимое. Запустил lvcreate через SYSTEM. Такой вот небольшой трюк в копилку LVM, который можно применять не только к СУБД, но и другим данным.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#lvm #mysql #backup
Закончил на днях настройку одиночного выделенного сервера для внешнего бэкапа. Расскажу кратко, как это сделал. Как обычно, поясняю, что это не руководство, как правильно и как делать вам. Рассказываю, как сделал я в сложившихся обстоятельствах.
Нужен был бюджетный дедик для хранения 2-3 ТБ данных. Я обычно в Селектеле бюджетные сервера заказываю, но там сейчас некоторые проблемы в этом плане. Они вывели из работы все бюджетные сервера, где можно было использовать 4 диска. Остались только платформы с двумя дисками. Под бэкапы это не очень подходит, так как там в основном установлены диски небольших объёмов. Долго прикидывал и решил попробовать сервер с двумя 2 ТБ NVME дисками. Мне только такая конфигурация по объёму подходила, поэтому решил обойтись без рейда. Это будет не единственная копия бэкапов.
Как обычно поставил туда Proxmox Virtual Environment (PVE). И в этот раз решил сюда же на железо установить Proxmox Backup Server (PBS). Я обычно его в виртуалку ставлю, но тут для более удобного управления дисковым пространством решил развернуть прямо на хосте. Соответственно, его же и подключил сразу к PVE. Забегая вперёд скажу, что это удобно и никаких проблем не не доставило.
В PBS собираются бэкапы виртуалок на отдельный диск. Так как на сервере быстрые диски, ОЧЕНЬ УДОБНО их тут же на PVE разворачивать из бэкапов и проверять или использовать для каких-то тестовых целей. Отдельно отмечаю скорость. Обычно под бэкапы отдаются большие медленные хранилища для экономии средств. Мне ни разу не приходилось работать с бэкапами на таких быстрых дисках.
Отдельно поднял LXC контейнер с Debian и добавил в него Mount Point с директорией с хоста. Это тоже для удобной утилизации дисков. Получается, что и PBS, и контейнер используют обычные хостовые директории на разных дисках. Этот контейнер ходит по серверам и забирает оттуда сырые данные в виде файлов с хранением инкрементов и дампы баз данных.
В итоге на одном сервере я храню копии виртуальных машин с возможностью их тут же развернуть и проверить. И сырые данные в виде файлов и дампов баз, которые собираются через LXC контейнер скриптами по крону. Получилось комплексное решение два в одном, которое хранит и виртуалки, и на всякий случай сырые данные, если с запуском виртуалок или просмотра данных в них возникнут какие-то проблемы.
Ещё раз отмечу скорость дисков. Очень удобно работать с бэкапами на быстрых дисках. Сравнение бэкапов, распаковка, проверка объёма, восстановление виртуалок. Всё происходит очень быстро. Сами сервера на обычных SSD дисках работают. Когда смотришь размер директории на пару сотен тысяч файлов и объёмом в 300-400 ГБ разница в подсчёте занимаемого места по времени раз в 5 отличается.
Я обычно подсчёт размера директорий с файлами веду скриптом по крону, записываю вычисленные значения и потом передаю в Zabbix. Несмотря на то, что у Zabbix есть специальный ключ для этого vfs.dir.size, подсчёт может вестись очень долго для больших директорий. Надо большие таймауты ставить, что не очень хорошо для мониторинга в целом. Не должен он напрямую выполнять длительные задачи. Здесь же можно использовать vfs.dir.size, так как размер вычисляется за считанные секунды.
Идеально 2 таких одинаковых сервера иметь, тогда можно вообще не переживать за отсутствие рейда для отказоустойчивости на уровне дисков. Это не сильно дороже, так как в бюджетных платформах диски могут стоить половину, а то и больше от всего сервера, но так намного удобнее.
Ниже на скрине пример восстановления виртуалки с диском на 450 ГБ, где занято примерно 85% места. Она восстановилась за 16 минут из инкрементной копии прошлой недели. На момент восстановления пришлось создание бэкапов с одного из серверов, которое длилось 4,5 минуты в то же время, когда восстанавливалась виртуалка. Это немного затормозило процесс.
#backup
Нужен был бюджетный дедик для хранения 2-3 ТБ данных. Я обычно в Селектеле бюджетные сервера заказываю, но там сейчас некоторые проблемы в этом плане. Они вывели из работы все бюджетные сервера, где можно было использовать 4 диска. Остались только платформы с двумя дисками. Под бэкапы это не очень подходит, так как там в основном установлены диски небольших объёмов. Долго прикидывал и решил попробовать сервер с двумя 2 ТБ NVME дисками. Мне только такая конфигурация по объёму подходила, поэтому решил обойтись без рейда. Это будет не единственная копия бэкапов.
Как обычно поставил туда Proxmox Virtual Environment (PVE). И в этот раз решил сюда же на железо установить Proxmox Backup Server (PBS). Я обычно его в виртуалку ставлю, но тут для более удобного управления дисковым пространством решил развернуть прямо на хосте. Соответственно, его же и подключил сразу к PVE. Забегая вперёд скажу, что это удобно и никаких проблем не не доставило.
В PBS собираются бэкапы виртуалок на отдельный диск. Так как на сервере быстрые диски, ОЧЕНЬ УДОБНО их тут же на PVE разворачивать из бэкапов и проверять или использовать для каких-то тестовых целей. Отдельно отмечаю скорость. Обычно под бэкапы отдаются большие медленные хранилища для экономии средств. Мне ни разу не приходилось работать с бэкапами на таких быстрых дисках.
Отдельно поднял LXC контейнер с Debian и добавил в него Mount Point с директорией с хоста. Это тоже для удобной утилизации дисков. Получается, что и PBS, и контейнер используют обычные хостовые директории на разных дисках. Этот контейнер ходит по серверам и забирает оттуда сырые данные в виде файлов с хранением инкрементов и дампы баз данных.
В итоге на одном сервере я храню копии виртуальных машин с возможностью их тут же развернуть и проверить. И сырые данные в виде файлов и дампов баз, которые собираются через LXC контейнер скриптами по крону. Получилось комплексное решение два в одном, которое хранит и виртуалки, и на всякий случай сырые данные, если с запуском виртуалок или просмотра данных в них возникнут какие-то проблемы.
Ещё раз отмечу скорость дисков. Очень удобно работать с бэкапами на быстрых дисках. Сравнение бэкапов, распаковка, проверка объёма, восстановление виртуалок. Всё происходит очень быстро. Сами сервера на обычных SSD дисках работают. Когда смотришь размер директории на пару сотен тысяч файлов и объёмом в 300-400 ГБ разница в подсчёте занимаемого места по времени раз в 5 отличается.
Я обычно подсчёт размера директорий с файлами веду скриптом по крону, записываю вычисленные значения и потом передаю в Zabbix. Несмотря на то, что у Zabbix есть специальный ключ для этого vfs.dir.size, подсчёт может вестись очень долго для больших директорий. Надо большие таймауты ставить, что не очень хорошо для мониторинга в целом. Не должен он напрямую выполнять длительные задачи. Здесь же можно использовать vfs.dir.size, так как размер вычисляется за считанные секунды.
Идеально 2 таких одинаковых сервера иметь, тогда можно вообще не переживать за отсутствие рейда для отказоустойчивости на уровне дисков. Это не сильно дороже, так как в бюджетных платформах диски могут стоить половину, а то и больше от всего сервера, но так намного удобнее.
Ниже на скрине пример восстановления виртуалки с диском на 450 ГБ, где занято примерно 85% места. Она восстановилась за 16 минут из инкрементной копии прошлой недели. На момент восстановления пришлось создание бэкапов с одного из серверов, которое длилось 4,5 минуты в то же время, когда восстанавливалась виртуалка. Это немного затормозило процесс.
#backup
К моим заметкам на тему бесплатных программ для бэкапа Windows систем постоянно упоминали Iperius Backup. Она же упоминается и в комментариях к статье, где все подобные программы собраны в одном месте. Никогда не пользовался этой программой, так что решил посмотреть.
У программы есть несколько редакций, в том числе полностью бесплатная. Основное её ограничение в том, что может бэкапить только директории и файлы, а складывать их локально или на сетевые диски. Никаких тебе образов дисков, восстановления системы, бэкапов на S3 и т.д. Это только в платных редакциях.
Программа на вид добротная, довольно старая, но развивается и по сей день. Нашёл даже материалы, как её скрещивают с Zabbix для мониторинга бэкапов на множестве серверов и компьютеров. Идея мониторинга в том, что на PowerShell пишется автообнаружение текстовых логов заданий и на основе их анализа передаётся информация в Zabbix Server.
📌 Перечислю основные возможности бесплатной версии:
▪️полный и инкрементный бэкап директорий и файлов с автоматическим удалением старых копий;
▪️шифрование и zip сжатие бэкапов;
▪️расписание и возможность без ограничения по количеству создавать задания;
▪️умеет выполнять команды или внешние скрипты до или после бэкапа по заданным условиям, например, если размер бэкапа получился меньше заданного;
▪️умеет выстраивать цепочки выполнения бэкапов, запускать следующий после успешного предыдущего, удобно для серверов;
▪️результат работы заданий пишет в подробные лог-файлы;
▪️аутентификация на сетевых ресурсах;
▪️поддержка серверных версий Windows;
▪️уведомления на email с расширенной настройкой условий, например, отправить уведомление, если бэкап меньше определённого размера или выполнялся дольше заданного интервала.
В целом, ничего особенного, кроме настроек выполнения внешних скриптов и уведомлений. Там нетипично много настроек для бесплатной версии.
С помощью Iperius Backup можно настроить в фоне бэкап пользовательских данных на их компьютерах куда-то на сетевой диск. Причём для каждого пользователя можно сделать отдельную директорию, куда Iperius Backup будет проходить аутентификацию по заданным учётным данным. На что-то большее она не способна в бесплатной редакции.
⇨ 🌐 Сайт
Среди подобных решений из знакомых мне, наиболее функциональной и удобной является Hasleo Backup Suite Free. Для своих нужд лично я использую Veeam Agent for Windows or Linux Free. Но там в плане функциональности бесплатной версии всё грустно, хотя лично мне хватает. Я бэкаплю разом всю систему. Есть ещё похожая программа Cobian Backup, но на неё не раз видел негативные отзывы, что зависает, или не восстанавливает после бэкапа. Плюс, она не развивается, а на сайте пишут "Слава Украине! Долой рашистов и Z-орков!". Так что от использования я бы воздержался.
#windows #backup
У программы есть несколько редакций, в том числе полностью бесплатная. Основное её ограничение в том, что может бэкапить только директории и файлы, а складывать их локально или на сетевые диски. Никаких тебе образов дисков, восстановления системы, бэкапов на S3 и т.д. Это только в платных редакциях.
Программа на вид добротная, довольно старая, но развивается и по сей день. Нашёл даже материалы, как её скрещивают с Zabbix для мониторинга бэкапов на множестве серверов и компьютеров. Идея мониторинга в том, что на PowerShell пишется автообнаружение текстовых логов заданий и на основе их анализа передаётся информация в Zabbix Server.
📌 Перечислю основные возможности бесплатной версии:
▪️полный и инкрементный бэкап директорий и файлов с автоматическим удалением старых копий;
▪️шифрование и zip сжатие бэкапов;
▪️расписание и возможность без ограничения по количеству создавать задания;
▪️умеет выполнять команды или внешние скрипты до или после бэкапа по заданным условиям, например, если размер бэкапа получился меньше заданного;
▪️умеет выстраивать цепочки выполнения бэкапов, запускать следующий после успешного предыдущего, удобно для серверов;
▪️результат работы заданий пишет в подробные лог-файлы;
▪️аутентификация на сетевых ресурсах;
▪️поддержка серверных версий Windows;
▪️уведомления на email с расширенной настройкой условий, например, отправить уведомление, если бэкап меньше определённого размера или выполнялся дольше заданного интервала.
В целом, ничего особенного, кроме настроек выполнения внешних скриптов и уведомлений. Там нетипично много настроек для бесплатной версии.
С помощью Iperius Backup можно настроить в фоне бэкап пользовательских данных на их компьютерах куда-то на сетевой диск. Причём для каждого пользователя можно сделать отдельную директорию, куда Iperius Backup будет проходить аутентификацию по заданным учётным данным. На что-то большее она не способна в бесплатной редакции.
⇨ 🌐 Сайт
Среди подобных решений из знакомых мне, наиболее функциональной и удобной является Hasleo Backup Suite Free. Для своих нужд лично я использую Veeam Agent for Windows or Linux Free. Но там в плане функциональности бесплатной версии всё грустно, хотя лично мне хватает. Я бэкаплю разом всю систему. Есть ещё похожая программа Cobian Backup, но на неё не раз видел негативные отзывы, что зависает, или не восстанавливает после бэкапа. Плюс, она не развивается, а на сайте пишут "Слава Украине! Долой рашистов и Z-орков!". Так что от использования я бы воздержался.
#windows #backup