31 марта по инициативе пользователей Reddit во всём мире отмечают День резервного копирования. Лучший способ отметить этот праздник — создать резервные копии данных, проверить и протестировать свои бэкапы.
▍ Полезные советы
- Используйте сервисы с поиском по резервной копии и пофайловым восстановлением. Это поможет быстро найти нужный файл и не ждать полного восстановления системы.
- Храните данные в трёх версиях (оригинал и две резервные копии). Какая-то копия точно сохранится, если не произойдёт катастрофы вселенского масштаба.
- Чтобы сократить объёмы резервных копий, особенно в виртуальных средах, используйте технологии дедупликации.
- Храните копии минимум на двух типах носителей. Например, на внешнем жёстком диске и облачном хранилище в интернете.
- Используйте сервисы, которые автоматически создают резервные копии по расписанию. Ручные бэкапы — не самый надёжный способ сохранить данные.
▍ Наши статьи
Для нужного настроя мы собрали несколько статей о безопасности и хранении данных из нашего блога. Они будут полезны как компаниям, так и обычным юзерам.
???? С днём бэкапа! Но не бэкапом единым…
Рассказываем, что угрожает безопасности компаний в современном мире. И это далеко не всегда хакеры, вирусы, черви и прочий malware.
???? Безопасность в компании: хоть в лоб, хоть по лбу
Недавние сливы данных пользователей показали, что даже в крупных компаниях к безопасности относятся спустя рукава. И причины дырок в защите весьма банальны…
???? Цифровое хомячество и цифровой минимализм — противоположные концепции и стили жизни
В вопросе «архивирования жизни» есть два противоположных подхода: один из них говорит о необходимости сохранять все электронные письма, файлы и регулярно делать скриншоты экрана, второй, наоборот, призывает минимизировать использование гаджетов и избавиться от цифрового мусора.
???? Пожары в дата-центрах. Как выстроить надёжное резервирование?
Многочисленные аварии и пожары в дата-центрах показывают — в этом мире может произойти всё что угодно. Поэтому для максимальной сохранности своих данных лучше перестраховаться и скопировать свою VM в нескольких ЦОДах, а ещё лучше — в нескольких странах.
Пишите ваши истории про удачные и не очень бэкапы в комментариях. И с праздником!
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ????️
Комментарии (22)
johnfound
00.00.0000 00:00Я не делаю бэкапы. Потому что считаю, что важные данные никогда не теряются. А данные которые теряются, они по определению неважные. Вселенная так работает. Я не делаю бэкапы примерно уже 30 лет и никогда важные данные не терял. Зато прикиньте сколько работы я не сделал. :P
ptr128
00.00.0000 00:00От силы час сэкономили на настройке резервного копирования. Не руками же его делать?
johnfound
00.00.0000 00:00За 30 лет? Ну, ну!
У меня есть 3 компьютера которые я использую ежедневно. У жены два. У дочери два. Еще 2 севера на VPS. Давайте посчитайте сколько времени (и денег) я сэкономил за 30 лет неделания бэкапов.
ptr128
00.00.0000 00:00Я же сказал - час. Больше получаса на настройку сервера для резервного копирования точно не нужно. Даже для нескольких сотен компьютеров. А уж что Вы выбрали, Bacula, Amanda, черта лысого - уже не важно. Установка агента на клиентский компьютер и его подключение к серверу резервного копирования - 1-2 минуты.
Про деньги вопрос странен, так как сервером у меня оказывается устаревший компьютер, который уже не применим для чего-то иного. Мой, жены, сына или дочек - уже как получится.
А вот сколько времени Вы, жена и дочка потеряли из-за отсутствия резервных копий - уж точно далеко не час.
johnfound
00.00.0000 00:00А как насчет процессорного времени которое затрачивается и из за которого я жду реакцию у компьютера больше чем мог бы если бэкап не происходил вот точно сейчас?
Начните с процессора Cyrix MII PR233 который у меня был, когда я отказался от бэкапов.
Также, включите деньги, которые потратил бы не выключая компьютер чтобы он мог сделать бэкап ночью, чтобы не мешал мне работать.
Не забывайте и про расходы на хардуер (за 30 лет сервер сгорел бы несколько раз, ведь старый и никому не нужен).
Раз начали, то считайте все, а не только то что подтверждает вашу тезу. :P
ptr128
00.00.0000 00:00Для начала определитесь, резервное копирование производится когда Вы работаете или по ночам. Потом почитайте, что такое энергосбережение, чтобы компьютер оставленный на ночь не потреблял лишней энергии.
Заодно объясните, при чем тут процессорное время, если сжатие и собственно резервное копирование производится на сервере, а не на клиенте. Я очень сомневаюсь, что Вам удастся заметить изменение реакции компьютера даже на P233, если ограничить агент 10 мегабитами (для тех времен этого было более чем достаточно). Я в 1993 году жил еще на OS/2 и подобной загрузки диска и сетевого адаптера точно не замечал.
За 30 лет сервер действительно менялся несколько раз. На очередной устаревший компьютер, как я явно написал выше. А вот настройки просто копировались.
P.S. Ради интереса проверил. Первый сервер, еще на i386, не сохранился. А вот второй сервер, который на Cx486DLC - до сих включается и грузится! Как ему удалось избежать свалки - сам поражаюсь )
johnfound
00.00.0000 00:00Для начала определитесь, резервное копирование производится когда Вы работаете или по ночам.
У обоих вариантов есть недостатки, которых нет, только если отказаться от резервного копирования. Что я и сделал.
За 30 лет сервер действительно менялся несколько раз.
Я вам говорил, что вы свои слова подгоняете тенденциозно под тезу? Вы говорили что за 30 лет потратил бы час. А выходит, что сервер надо менять притом несколько раз, настройки копировать, а это все точно не влезет в ваш час. Люди часто недооценивают затраты времени на ту или другую деятельность, особенно если затраты распределенные на длительный срок. То же самое и насчет денежных затрат.
ptr128
00.00.0000 00:00У обоих вариантов есть недостатки
Какой недостаток у фонового резервного копирования, которое происходит при входе компьютера в сеть? Сейчас именно так это и живет. Но если 30 лет назад скорость ограничивалась пропускной способность ArcNet по коаксиалу, то сейчас 10% от пропускной способности сети (смотря по чему прицепился: по гигабитке или по WiFi).
И если 30 лет назад нагрузка от тоссинга почты сквидом ощущалась, за что фидошная нода и была выселена на сервер, то нагрузка от чтения диска по ArcNet - точно не была заметна,Вы говорили что за 30 лет потратил бы час.
Именно на сервер резервного копирования, без учета всех остальных функций, которые выполнял и выполняет сервер? Да. И вряд ли больше.
Копирование настроек - секунды!
johnfound
00.00.0000 00:00Какой недостаток у фонового резервного копирования, которое происходит при входе компьютера в сеть?
Огромный! Как раз сразу после включения, когда я начинаю работать компьютер будет медлить и выполнять какие-то левые таски по сети, которые мне совершенно не нужны.
ptr128
00.00.0000 00:00Прочитайте, что Вам пишут! Даже на P233 это не было заметно! Что уж говорить о современных компах и современных сетевых адаптерах?
johnfound
00.00.0000 00:00Ну-у-у, незаметно говорите. А почему тогда все еще есть песочные часы в курсорах?
Человек замечает примерно 100мс замедление.
ptr128
00.00.0000 00:00Человек замечает примерно 100мс замедление.
Именно. А при скорости чтения HDD в те времена порядка 20 мегабайт в секунду, чтение по 10 мегабитам 1 мегабайта в секунду, даже через PIO - 50 мс. А если и HDD, и сетевая карта по DMA - делите еще на 10.
Про современные SSD вообще молчу. Если грузить даже гигабитку на 10%, то задержки будут мене 1 мс.
HUB-IT
00.00.0000 00:00Я не делаю бэкапы. Потому что считаю, что важные данные никогда не теряются. А данные которые теряются, они по определению неважные.
Значит у Вас нет важных данных, которые бы вы боялись потерять!
А на практике получается иначе, как говориться «Пока жареный петух не клюнет, мужик не перекрестится». Вот пример уходящей недели, небольшой фитнес-клуб КПО стоит с 2019 г. нет не одного бэкапа, жёсткий диск приказал долго жить как итог информация потеряна (база клиентов, оплат и т.д). За прошлый год три случая шифрования баз, пожалели деньги - время, за то деньги злоумышленникам нашли от 2000 у.е )) + восстановление работоспособности системы! И таких примеров множество, при чем некоторых это не учит они продолжают пренебрегать делать бэкапы..
johnfound
00.00.0000 00:00Я вам говорю – важные данные не теряются в принципе. Если у кого-то потерялись данные, значит они не были важны. Это аксиома и не зависит от чьего-то мнения. Если данные потерялись – хорошо, уменьшился информационный шум.
А этот пример, который вы привели, я подозреваю, что на самом деле, данные не потерялись и они их восстановить сумели. Или в итоге обанкротились и все совершили суицид? Не вериться как-то.
ptr128
00.00.0000 00:00Во-первых, вопрос не в том, что данные теряются безвозвратно. Вопрос в том, что на их восстановление после однократного сбоя уходит ресурсов (трудовых и финансовых) на порядок-другой больше, чем было бы потрачено на резервное копирование между этими однократными сбоями.
Это аксиома и не зависит от чьего-то мнения
В-вторых, аксиома как раз очень даже зависит от чьего-то мнения, так как принимается верной только в рамках той теории, к которой она относится. А так как автор теории - Вы, то она принята без доказательства только Вами
Например, Вы вправе считать, что никто ничего не потерял при уничтожении Александрийской библиотеки, но в научных кругах принята совершенно противоположная точка зрения.
Даже Библия и Коран дошли до нас только потому, что они многократно копировались и переписывались. То есть, без резервного копирования, они были бы утеряны безвозвратно.
johnfound
00.00.0000 00:00ресурсов (трудовых и финансовых) на порядок-другой больше, чем было бы потрачено на резервное копирование между этими однократными сбоями.
Это еще надо доказать расчетами. Имея ввиду и вероятность сбоя. Ведь расходы на бэкапы происходят с вероятностью 100%, а сбой с вероятностью гораздо ниже.
Даже Библия и Коран дошли до нас только потому, что они многократно копировались и переписывались. То есть, без резервного копирования, они были бы утеряны безвозвратно.
Библия и Коран не копировались чтобы сохранить. Они копировались чтобы ими пользоваться. Это не было резервное копирование ни разу!
ptr128
00.00.0000 00:00Это еще надо доказать расчетами.
Вообще-то доказано практикой. Например, запросы на восстановление с ленты там, где у меня сейчас проект, регистрируются 4-5 раз в месяц (54 раза за 2022 год) . Специально проверил по JIRA.
У меня дома намного реже - 1-2 раза в год. Но и этого более чем достаточно.
Они копировались чтобы ими пользоваться. Это не было резервное копирование ни разу!
Вы телепат? До изобретения книгопечатания это было в том числе и резервное копирование. В целях сохранения копии в той же или других библиотеках. Только Ветхий завет в православии включает 51 книгу (39 канонических и 12 неканонических). А сколько еще было утеряно, кроме пяти известных - остается только предполагать.
И почему Вы обошли молчанием историю потери Александрийской библиотеки? Кстати, утерянные пять книг ветхого завета там были. Так же как и "О сфере" Архимеда и "Гемократ" Платона.
johnfound
00.00.0000 00:00Вообще-то доказано практикой. Например, запросы на восстановление с ленты там, где у меня сейчас проект, регистрируются 4-5 раз в месяц (54 раза за 2022 год). Специально проверил по JIRA.
Это ни о чём не говорит. Во первых, неясно сколько из этих случаев могли обойтись и без восстановления? Во вторых, какие были бы потери, если не было бы бэкапа? В третьих, сколько этот бэкап стоит в год. Примерно, мой хостер хочет $1.2 в месяц за бэкап, а это +20% к цене. Теперь умножьте это на весь рынок хостинг услуг и рассчитайте какие расходы на в целом бесполезное копирование информации туда сюда.
И почему Вы обошли молчанием историю потери Александрийской библиотеки? Кстати, утерянные пять книг ветхого завета там были. Так же как и "О сфере" Архимеда и "Гемократ" Платона.
Ну и что произошло? Что именно мы потеряли? Наука замедлилась? Сейчас бы имели базы на Марсе? Ну уж нет. О законе Архимеда мы ведь как-то узнали.
ptr128
00.00.0000 00:00Это ни о чём не говорит.
Еще как говорит. Пусть каждая такая потеря, пусть по минимуму, человекодень (опять по минимуму - $200 - дешевле $25 в час специалиста не представляю). Итого за год - свыше $10 тыс. Резервное копирование обходится явно дешевле, даже с амортизацией оборудования.
А так как по факту, большинство таких запросов требуют восстановления в БД информации руками нескольких десятков людей и не факт, что за день - то окупается на порядок-другой.Что именно мы потеряли?
В большинстве своем - мы не знаем.
Наука замедлилась?
Однозначно и на века. Только утеря трудов Архимеда отбросило науку на 18-19 веков. Очень может быть, что если бы эти труды не были утеряны, то промышленная революция произошла бы на несколько веков раньше, а мы бы уже летали в отпуск на Марс.
dlinyj
ZlobniyShurik
Таки на три категории. Третья - те, кто сделанные бэкапы ещё и проверяет иногда ;)