1. Нельзя не делать бэкапы
В недавнем посте Backblaze приведены данные годового опроса, который показал, что всего 8% респондентов делают резервные копии каждый день (пару лет назад эта цифра была больше), 16% делают бэкап раз в год, а 25% не делают вообще. В начале лета мы также проводили опрос, результаты которого не менее пугающие – 90.6% респондентов не готовы потерять данные, при этом лишь 74% опрошенных делают резервные копии важных данных (из которых 57.9% используют для этого лишь внешний накопитель).
Ничего не делать – это один из самых худших подходов. Вы надеетесь, что независимо от ваших (или посторонних) действий всё будет работать идеально, но ни один компьютер не сможет вам этого гарантировать – рано или поздно вы потеряете данные и будете об этом жалеть.
2. Нельзя полагаться на средства и сервисы восстановления данных
Если вы случайно удалили файл с вашего макбука, есть вероятность, что его можно восстановить, воспользовавшись специальными программами для восстановления данных. Если этого сделать не удалось (например, если был повреждён сам накопитель), то остаётся надежда лишь на специализированные компании по восстановлению данных. Однако полагать, что вы сможете воспользоваться одним из этих способов, попросту глупо. Иногда причиной утраты данных становится кража или внеплановый метеоритный дождь, в результате чего у вас попросту не будет диска, над которым можно было бы провести все вышеперечисленные операции.
3. Не надейтесь на автосохранение
Действительно, некоторые приложения выполняют автоматическое сохранение документов, давая вам возможность начать с того места, где вы остановились, даже если файл так и не был сохранён с именем (пример такого приложения – BBEdit). Однако не все приложения работают подобным образом. Но даже если работают, всегда возникают ситуации, когда пользователи случайно или по ошибке удаляют файлы автосохранения. Не секрет, что большинство систем резервного копирования предполагают, что пользователь как минимум сохранит и назовёт файл – часто автосохранение включается только после этого шага.
4. Не стоит делать бэкапы вручную
Есть множество людей, которые выполняют бэкап всей системы (или, как минимум, части файлов) когда их душе угодно, создавая клонов или копируя файлы на другой диск вручную. Конечно, это лучше, чем ничего, но это очень ненадёжный и непостоянный подход – найдётся тысяча и одна причина не сделать однажды бэкап. И по закону подлости вполне может случиться так, что вы потеряете данные именно в тот день, когда забудете или не успеете выполнить бэкап. Поэтому автоматические бэкапы – это более надёжный вариант. Даже, пожалуй, лучший.
5. Нельзя полагаться только на Time Machine
Time Machine является замечательным (бесплатным) инструментом, встроенным в OS X – Apple сделали верную ставку на упрощение процедуры бэкапа. Time Machine – это хорошо. Но не стоит целиком и полностью доверять данному приоложению. Например, в статье «Why I Don’t Rely on Time Machine» («Почему я не доверяю Time Machine») автор рассказывает, как столкнулся с неисправимой ошибкой Time Machine, в результате которой ему пришлось очистить все резервные диски и начать копировать всё заново. Диски были в порядке, а вот данные – нет. Даже хвалёные инструменты восстановления не помогли. Time Machine может идеально работать годами, но стоит ему хоть раз споткнуться… Хотя Time Machine и надёжная утилита (и хорошо справляется со своей работой как вспомогательный бэкап-инструмент), но лучше не делать ставку только на нее.
Ещё кое-что о Time Machine: если у вас «полетел» диск целиком, то единственным выходом станет его форматирование или замена с последующим восстановлением бэкапа – этот процесс может занять долгие часы. Во время выполнения процедуры вы не сможете пользоваться своим Mac, поэтому настоятельно рекомендуем делать загрузочные копии системы или «клоны». Но это приводит к ещё одной проблеме…
6. Нельзя пользоваться только клонами
Клоны – это отличная вещь. Если что-то пошло не так, они позволяют вам вернуться к работе практически мгновенно (перезагрузите систему, удерживая Option, и выберите клона). Также клоны дают возможность откатить систему до предыдущих версий OS X, если обновление прошло с ошибками.
Проблема в том, что клоны не дают вам возможность восстановить случайно удалённые файлы или получить доступ к их более ранним версиям, если клон был обновлен (некоторые приложения предоставляют возможности архивации файлов, но тут нужно понимать, что вы делаете). Ещё одна проблема – клон хранится на вашем макбуке, поэтому, если что-то случится с компьютером (торнадо, грабёж), то вместе с ним пропадёт и единственный бэкап. Эта проблема ведёт нас к следующему заключению…
7. Нельзя хранить бэкапы на одной машине
Гипотетический метеорит может уничтожить дом в Калифорнии, но вряд ли сможет одновременно с этим уничтожить ещё и дата-центр CrashPlan в Миннесоте и в других местах, где вы можете хранить свои данные. Это касается и данных, утерянных в результате кражи, прорыва труб, пожара – несчастий гораздо более вероятных, чем падение метеорита. Если ваши бэкапы хранятся на локальной машине, то они защищены только от определённого круга опасностей. Эту проблему легко решить, просто отдав бэкапы другу или, например, поместив их в ячейку банка. Вы также можете воспользоваться облачными сервисами типа CrashPlan, Backblaze или DollyDrive. Короче, сделайте так, чтобы у вас был бэкап на стороне.
Но, как ни странно, обратное утверждение тоже верно. Не стоит…
8. …иметь только онлайн-бэкапы
Они идеально подходят для огромного количества ситуаций, вот только восстановление многогигабайтного куска данных из облачного хранилища (забудем пока про целый диск) может занять длительное время. В такой ситуации вы ограничены пропускной способностью канала связи интернет-провайдера. А некоторые провайдеры до сих пор имеют лимит скачиваемых данных, так что процедура восстановления может солидно затянуться. Именно поэтому помимо «облачных», стоит всегда хранить локальные бэкапы (разумеется, если вы хотите загрузиться с клона, он должен быть на локальном жестком диске).
Следующие две ошибки также относятся к онлайн-бэкапам.
9. Не стоит использовать исключительно Dropbox (или похожие сервисы)
Dropbox – это отличный и очень удобный инструмент, хотя многие другие облачные хранилища (iCloud Drive, Box, Amazon Cloud Drive, Google Drive, Яндекс.Диск, Microsoft OneDrive и т.д.) обладают примерно тем же набором функций. Большинство из них даже предлагают примитивную бэкап-функцию, восстанавливающую старые или удалённые файлы (если им не более месяца).
Всё это хорошо, однако, подобные сервисы больше подходят для хранения небольшого количества файлов, нежели для полноценного резервного копирования системы или всего диска. К тому же в большинстве сервисов бесплатное место довольно скромное по размерам, в то время как дополнительное место для хранения большого объёма данных будет регулярной и ощутимой статьёй расходов.
10. Не стоит думать, что веб-приложения не нуждаются в бэкапах
Вы используете Google Docs, Office 365, iWork для iCloud или другие веб-приложения (коих бессчётное количество) для создания и совместного использования документов? Многие из нас пользуется этими сервисами, по крайней мере, изредка. Это хорошо, но делаете ли вы локальные копии этих документов? Если ответ – «Нет», то это плохо.
Можно перечислить множество случаев, когда люди открывали Google Docs (или что-то ещё) и обнаруживали, что важный документ исчез по непонятной причине. И что делать в такой ситуации – непонятно. Подобные ситуации возникают нечасто, но поверьте, они возникают. Не стоит рассчитывать на то, что облачный сервис адекватно восстановит утраченные данные, или что вам удастся сделать это самостоятельно (даже при наличии данных в облаке вы не всегда сможете получить к ним доступ из-за проблем с сервером или с вашим интернет-соединением, и случится это в самый неподходящий момент). Поэтому лучше делать собственные бэкапы облачных документов. Можно использовать специальные утилиты, например, CloudPull (посмотрите статью «Back Up Your Google Data with CloudPull» («Делаем бэкап документов Google с помощью CloudPull»), хоть она и старенькая уже).
11. Не думайте, что RAID и бэкап – это синонимы
RAID объединяет несколько жёстких дисков в один логический том. Одним из вариантов настройки RAID является зеркальный RAID (RAID 1), который наиболее часто путают с бэкапами. Суть RAID 1 в том, что каждый блок записывается на два разных физических диска, тем самым обеспечивается 100% избыточность (RAID 5 и 6 также обеспечивают избыточность, но другими способами). Это не совсем клонирование, потому что данные всегда актуальны и обновлены. Это же замечательно?
На самом деле, не всегда. Именно постоянные обновления являются частью проблемы. Если вы случайно удалили файл, то удалится он с обоих дисков зеркального RAID. Если была повреждена директория или файл, к вам проник вирус или возникла ещё какая-нибудь проблема, то это одинаково отразится на обоих дисках. Разумеется, если массив был украден или повреждён, то файлы будут утеряны. RAID 1 защищает ваши данные только в случае выхода из строя одного из жёстких дисков (такое случается) и не более того. Так что запомните, что дисковый массив – не синоним слову «бэкап».
Нормально делай – нормально будет!
Здорово, если во время чтения этого списка нелепых ошибок вы убедились, что ваша стратегия резервного копирования данных совершенна и лишена описанных недостатков. Если это так – надеемся, вам было интересно взглянуть на то, как живут остальные 92% населения.
Однако если вы узнали себя хотя бы в одном из пунктов, не спешите расстраиваться – мы как раз и делали эот пост, чтобы помочь вам это исправить. Мы все через это проходили. Нужно понимать ошибки и исправлять их, тем более когда речь идёт о сохранности важных данных. Просто сделайте резервную копию прямо сейчас, после прочтения статьи, учитывая упомянутые выше ошибки – после этого вы можете быть уверены, что никакие метеориты не разрушат ваши данные, и сможете направить усилия на более важные задачи, например, на защиту от зомби :)
Анонс
Данная статья является переводом зарубежной статьи «11 stupid strategies of backup», автор которой не имеет к нашей компании никакого отношения. Однако мы решили опубликовать её, когда поймали себя на мысли, что наши новые продукты (в лице Acronis True Image 2016 и Acronis True Image Cloud) позволяют делать резервное копирование данных с учётом всех вышеперечисленных советов и рекомендаций. В ближайшем обозримом будущем мы подготовим обзоры наших новинок, а пока можете изучить их самостоятельно – по подробному обзору в журнале «Хакер» или скачав приложения с сайта.
Ну и да, сделайте бэкап важных данных прямо сейчас. Успехов!
Комментарии (77)
EndUser
02.12.2015 18:39Мда… Если вы про персоналку, то сколько денег потребуется на исполнение всех ваших рекомендаций? Сравнимо с двухкратной ценой этой персоналки?
yosemity
02.12.2015 19:01-2Тоже так подумал сначала, но оказалось, что ценник для Acronis True Image 2016 вполне адекватный. Вот только зачем если есть… :)
EndUser
02.12.2015 19:39+1TCO какой с NAS, тарифом Cloud, запасными HDD, включая и ценник Акрониса?
yosemity
02.12.2015 21:13Подождите, конкретно с каким пунктом вы не согласны? Конечно, необходимость бекапа не удешевляет стоимость владения, но мы сейчас говорим совсем про другие вещи. Почти всегда стоимость носителей на порядки ниже стоимости информации на них находящейся. Естественно, в случае с виндой, есть альтернатива, но это не отменяет того факта, что продукты Acronis очень качественные.
DaylightIsBurning
02.12.2015 20:53Да, дорого, но вы эту цену и так платите, и даже больше, просто «в кредит». Когда сломается — придётся этот кредит отдавать.
foxmuldercp
03.12.2015 11:24Любая авария с данными — это а) стоимость железа, б) нервы, в) стоимость человекочасов, потраченных на наработку утерянного — у меня у многих знакомых программистов есть десятки гигабайт наработок за десятилетия их работы, документация, куски кода, и на всё это потрачены годы работы, ошибок и опыта. Так вот, ни первое, ни второе не стоит и тысячной доли того, что стоит третий пункт.
Я уже не говорю про всякие исторические архивы…
Goodkat
02.12.2015 22:08Насколько дороги вам ваши данные?
EndUser
02.12.2015 23:31Насколько дорога политика резервирования и, что важно, восстановления — на 10% от стоимости терабайта моих данных (рабочих и личных файлов), на 50% или на 150%? И сколько простоя создаст восстановление?
Конечно, если считать, что в комп и внешний HDD попадёт метеорит, то мне, сидящему рядом с этим же компом, вопрос дороговизны данных будет уже не важен.
В остальных случаях лаптоп с диском в охапку – и данные в шоколаде, причём с сохранением всего софта и всех настроек этого софта.
Когда я изучал для себя предлагаемые Акронисом политики, я не нашёл лёгкого восстановления состояния операционки со всем софтом и документами «на вчера». Всё там какое-то шаманство с offline загрузкой, с перетыканием дисков, нарезанием DVD (причём регулярным, как ни странно), с многочасовым ожиданием процесса…
Поэтому для себя выбрал политику «горячего» клонирования. Это не требует выключения винды. А для восстановления всё равно отвёртка нужна так или иначе. Но время восстановления — одна операция по замене диска на 5 минут, и — вуаля — я снова в бизнесе.
Это конечно, если не стирать сдуру важные файлы и бегать со всякими Undelete.
Преимущества клонирования:
1) полное восстановление занимает 5 минут и требует только отвёртки и диска той же модели.
2) полный клон умрёт при записи на битый резервный диск — это сигнал к подмене резерва.
Недостатки клонирования:
1) Где нужна версионка — её надо организовать своими руками. Это решаемо и не влияет на время и полноту восстановления.
2) При загрузке с клона слетает лицензия винды. Это не мешает мгновенному началу работы после сбоя. Хотя я не нашёл доказательства, что у Акрониса не слетает.
VenomBlood
03.12.2015 04:45+1В остальных случаях лаптоп с диском в охапку – и данные в шоколаде, причём с сохранением всего софта и всех настроек этого софта.
Потоп, пожар, удар молнии, короткое замыкание, в случае с HDD — удар который может вывести диск из строя, кража, и т.д. — все эти варианты делают бесполезными бекап находящийся физически в одном компьютере. Бекап на NAS с развязкой через сетевой фильтр от части проблем спасает, от остальной части спасает бекап бекапа в облако.
PS. Инкрементные бекапы нужны для случаев «неделю назад удалил папку, а оказывается там была нужная фотка» — причем «удалил» — это может быть и сам и ребенок и что-то вредоносное и кто угодно, а может вообще ошибка в инсталляторе которая что-то трет. Одним «горячим» бекапом не обойтись.
Alexeyslav
03.12.2015 10:30+2Да, реальный кейс… Как-то в антивирусе нажал кнопку «почистить систему», ну она должна была поидее удалить временные файлы, историю браузера и т.д. по какой-то причине туда попали ссылки на системные папки. Угу… антивирусник, с системными правами потёр ВСЁ до чего дотянулся(и систему и даже программы!). Я еще подумал чего-то он долго и слишком интенсивно чистит… потом винда начала возмущаться что отсутствует нужный системный файл, ни одна программа не запускается по причине отсутствия файла…
И как на зло — последняя резервная копия сделана месяц назад(ага, хранилище резервных копий переполнено и уже месяц как некуда ложить свежие бэкапы). да, свежей версией акрониса, а загрузчик записанный на диске предыдущей версии и не может восстановить… Зато есть копия системы годичной давности. Вот так и пришлось восстановить хоть что-то в несколько этапов, на каждый из которых ушло примерно по 2 часа(пока проверится копия перед восстановлением, пока восстановится и сам загрузчик запускается минут 10).
Вот кстати камень в огород Акрониса — его загрузчик крайне костыльный и загружается очень долго, хотя казалось бы наоборот должен грузится секунды как это делает виндовс после выхода из спящего режима — какая проблема сделать слепок памяти запущенного загрузчика просто восстанавливая его?
sledopit
02.12.2015 23:41Ну если сравнивать с нормальным самостоятельным решением, то сильно дешевле.
Правда, я не могу сказать про качество их решения, т.к. не пользовался.
Сам я себе организовал схему бэкапа следующим образом:
1.Важные данные, которые нужно бэкапить (рабочие проекты, фото/видео с отдыха и тому подобная фигная) влезает в 500Гб и всегда есть на ноутбуке. Правда, я уже очень близок к превышению этого порога. (в стоимость бэкапа не входит)
2. Домашний NAS, собранный своими руками (raid1 на 640Гб для системы и бэкапов) + по совместительству файлопомойка на отдельных дисках 3Тб (10000 рублей разовое вложение. собирал года 3 назад, поэтому сейчас цена будет существенно выше. стоимость интернетов считать сюда не будем). Сюда раз в сутки всё бэкапится с ноута, при условии, что он в домашней сети. Из поездок, к сожалению, всё это ест много трафика, который не всегда есть под рукой.
3. Сервер в ДЦ где так же есть около 500Гб под мои бэкапы + по совместительству рабочая площадка под пару своих (и товарищеских) проектов. Сюда раз в сутки бэкапится с домашнего nas'а всё. (40000р разовое вложение + 2500 ежемесячно).
Если всё сложить, получается 50к разово + 30к / год я плачу за возможность качественного бэкапа своими руками, где каждый важный элемент находится под моим личным контролем. По сравнению с этим 70 баксов в год, что просит акронис — копейки.
Раз уж мне всё равно нужен сервер под проекты, а бэкап особой нагрузки не даёт, то меня всё устраивает. И у меня нет ощущения, что я столько денег отдаю просто за возможность делать бэкапы так, как мне нравится (:
Но в целом, это крайне недешёвое удовольствие.
зы. Правда, я бэкаплю исключительно файлы. Бэкапить систему и настройки я смысла не вижу. Всё можно аписать тем же ansible и он прекрасно восстановит всю систему вместе с настройками без лишних заморочек.
umputun
02.12.2015 23:09+3Я ничего не имею против Acronis True Image 2016 и Acronis True Image Cloud. Однако, утверждение что они "… позволяют делать резервное копирование данных с учётом всех вышеперечисленных советов и рекомендаций", и идея, что встроенный в ОС TM это то, чему «не стоит полностью доверять» и всего лишь «вспомогательный бэкап-инструмент», а ваш продукт то, чему стоит — мне кажется маркетинговым… преувеличением. Я не знаю вашего продукта, и необходимости его знать у меня нет, однако, я сильно сомневаюсь в его идеальности. Не потому, что вы программы писать не умеете, а потому, что никто не умеет писать идеальные программы.
Совет «пользуйтесь только нашими продуктами» — это очень плохой совет. Привязать бэкапы к единому стороннему поставщику — это очень плохая идея.
Что касается практических рекомендаций от меня (для дома) — делать бэкап TM на два устройства (локальный диск и nas) и завести альтернативный бэкап в облако (я для этого пользую arq).
yar3333
02.12.2015 23:23Мой опыт: чем проще — тем лучше. Поэтому могу посоветовать open-source программу для бекапов часто (и не очень) меняющихся данных — www.areca-backup.org, которая жмёт в zip-ы. А для снэпшотов системы отлично подходит бесплатный для личного пользования Paragon Backup & Recovery.
Gendalph
02.12.2015 23:28Я просто оставлю это здесь:
Куда:
www.hetzner.de/ot/hosting/produktmatrix/storagebox-produktmatrix
xenpower.com
hosthatch.com/storage-vps
www.hardkernel.com/main/products/prdt_info.php?g_code=G143599699669
Чем:
rsnapshot.org
www.aboutmyip.com/AboutMyXApp/DeltaCopy.jspzapimir
03.12.2015 03:31А почему именно указанные «куда», а не какие-нибудь облачные хранилища типа Amazon S3, Selectel или OVH?
foxnet
03.12.2015 09:34Для регулярных длительных бэкапов по-моему идеально подходит glacier
aik
03.12.2015 09:56Только для регулярного восстановления не подходит. :)
У амазона есть же за 60 баксов безлимит. Правда родной клиент там жуткий.foxnet
03.12.2015 13:46Ну я так понимаю, речь о катастрофоустойчивости за минимальные деньги, а не регулярном восстановлении. Для частого восстановления косяков прекрасно подходит использование теневых копий.
aik
03.12.2015 15:04А там цены не такие уж и маленькие на больших объемах. К примеру, хранить терабайт в год будет стоить больше сотни баксов (130 примерно). А уж за сотню можно найти терабайт с халявным даунлоадом. Хоть дропбокс тот же.
foxnet
03.12.2015 15:52Цены там не маленькие только на трафик. Хранение будет дешевле всех аналогов.
А по поводу халявного даунлоада, то все халявные имеют либо крайне паршивую скорость либо ограничивают объем бесплатного трафика.aik
04.12.2015 02:27+1Бэкапы надо обновлять — так что вы будете платить, в основном, за запросы на аплоад.
Как ниже сказали — ледник для архивов нужен. Засунули и не вспоминаете.foxnet
04.12.2015 08:38-1А зачем еще бэкап нужен? Копия документов, которые закинул и не обращаешься к ним пока не произойдет какая-то катастрофа. Стоимость аплоада, кстати не на столько дорого выходит. Там относительно дорого выходит их скачивание из старых копий.
Это не отменяет raid, заметим. И теневые копии для восстановления мелких косяков в течение работы.aik
04.12.2015 10:02+2Бэкап должен быть актуальным, поддерживать версионность и периодически проверяться на целостность.
А glacier — это просто архив. То есть закончили работу — все материалы сложили в архив. И больше не обновляете. То есть там хорошо держать то, что окончательно удалять жалко, но регулярного обновления не происходит. Ну или только добавление материалов, без изменения уже сохраненного.
А raid вообще к резервному копированию слабо относится.foxnet
04.12.2015 11:09Вы упорно игнорируете очень важную технологию, которая позволяет восстанавливать данные «на лету». А именно, теневые копии.
raid не относится к бэкапу, он относится к защите данных.
Для важных данных слои должны быть следующие, что касается только сохранности данных:
1 Защита от изменений, откат версий, защита от случайного повреждения
2 Защита от отказа или уничтожения носителя
3 Защита от отказа или уничтожения компьютера/сервера
4 Защита от уничтожения помещения вместе с данными
Каждый из слоев должен быть рассчитан в зависимости от того, какую часть работы допустимо потерять в случае катастрофы.
В моем понимании прекрасно справляются с этим следующие технологии, если речь идет о типичных средне-важных данных:
1. shadow
2. raid
3. Ежедневная копия на другой компьютер или хранилище рядом
4. Периодическая копия на компьютер в другом здании или в облаке. И вот тут я предлагаю Glacier. Не для сброса ежедневной работы, а для защиты от катастрофы. Не панацея, конечно, каждый использует то что ему удобно, но, мне кажется, это решение имеет место быть.aik
04.12.2015 11:41Почему игнорирую теневые копии? Активно пользуюсь, первая линия защиты.
Если по вашей шкале, то у меня так устроено (для себя, на работе другие реалии).
1. Теневые копии
2. Автоматическое дублирование важных папок на нескольких дисках (raid не хочу, не нравится, как он с местом обращается)
3. Копия важных данных на соседнем компьютере.
4. Копия в данных в обычном облаке. С версиями, доступом в любое время и т.п.
И пятая степень — архивы. Куда я раз в месяц сбрасываю полную копию. Вот тут как раз можно и ледник использовать, потому что это именно что на черный день делается.
zapimir
03.12.2015 19:45+1Ну glacier всё же для архивирования больше подходит, а не для бэкапа. Т.е. когда к примеру нужно хранить документацию за много лет, и не нужно к ней быстрого доступа.
А так у того OVH есть Public Cloud Storage там €0.01 за гиг в месяц.aik
04.12.2015 02:35Цена не то чтобы очень уж низкая. Терабайт будет стоить как у дропбокса.
Хотя вот их облачная файлопомойка hubic предлагает 10 терабайт за 50 евро в год…
antonbatenev
03.12.2015 02:59А шифровать резервные копии на удаленные хранилища (и не доверять проприетарному шифрованию) никто же не забывает?
VenomBlood
03.12.2015 04:48Я бы добавил — не пользоваться стандартным встроенным облаком, т.к. программе бекапящая в «родное» облако будет знать пароль и потенциально это источник утечки.
kacang
03.12.2015 05:46Для домашних пользователей действительно нет хорошего решения. Облака не предлагать, так как заливка туда гигабайтов без гугль файбера в доме займёт ну очень долго.
Для себя развернул Бакулу (на Малинке с внешним HDD). Таким образом бэкапю локальный сервер (всегда вкл), сервер на vps (через firewall, итд), и домашние лаптопы (не всегда вкл). Операционки: Win, Linux.
Если бы делал заново, то попробовал бы Burp, но после долгой возни с Бакулой начинать всё заново не хочется.aik
03.12.2015 08:33заливка туда гигабайтов без гугль файбера в доме займёт ну очень долго.
Долго займет только первоначальная заливка. Терабайт вполне можно засунуть за неделю-другую (если у вас не крашплан, конечно :)). А потом только изменения заливать.
Ну и далеко не всем надо бэкапить терабайты.
PS. За burp спасибо, надо глянуть.kacang
03.12.2015 08:45Неделю, хех, не, спасибо. Дело даже не в том сколько займёт, а сколько раз разорвётся. Иногда приходится заливать ~1-1.5 Гб в дропбох и это занимает часов таки 12-18, разлетевшиеся файлы приходится пере-посылать. То еще удовольствие. Интернет у меня сносный для down-link (2Мбпс), но очень херовый для up (не помню сколько). Но если у вас 1Мбпс ап или выше, может и можно онлайном пользоваться.
aik
03.12.2015 09:22А в чем проблемы, куда вам торопиться-то? Да и докачку давно уже изобрели.
На счет же скоростей интернетов… Тут уже у кого что. Если уж совсем хреново, то можно сходить туда, где быстрый интернет для закачки начальных объемов.kacang
03.12.2015 09:27Ну, не спорю — можно и на 56к пару гигабайт залить. Главное терпение :)
aik
03.12.2015 09:56А куда торопиться? Онлайновые бэкапы, как правило, нужны, когда у вас сдохли все локальные варианты. Потому большие скорости им не слишком нужны. Так что, на мой взгляд, неделя-другая на первоначальную заливку — нормально.
kacang
03.12.2015 10:44Время — деньги (с) банк Империал
aik
03.12.2015 10:54Если деньги, то надо просто сходить туда, где интернет быстрый и залить данные оттуда.
Хотя, конечно, если вы живёте в Норильске или Магадане, то это будет сложновато… Хотя Норильску, по слухам, через годик-другой будет праздник — таки дотащат туда оптику.kacang
03.12.2015 11:05Приходит чувак в интернет кафе, за собой санки тащит. На санках стоит десктоп. Снимает шубу, и спрашивает у бармена: «Где тут у вас быстрый вай фай?» ;)
aik
03.12.2015 11:13LAN-парти конца девяностых начала нулевых помните? Когда ноутбуки были дорогими и народ нередко на выходные у кого-нибудь собирался со своими системниками и мониторами… :)
kacang
03.12.2015 11:23Ну дак я не спроста — я самостоятельно через сибирскую метель на санках ХТшку+монитор завернутую в одеяла катал. Поближе к телефону, чтобы чёнить закачать.
Alexeyslav
03.12.2015 10:48И потом выясняется что при заливке флипнулся один бит и вся резервная копия летит к чёрту(избыточность данных для восстановления? не, не слышали)
aik
03.12.2015 10:52А вы что, пакуете все свои данные в один контейнер и не добавляете туда информацию для восстановления? Я пофайлово в облако пихаю. Правда большие объемы у меня не сильно приватные — там только фотки из отпуска, потому их не шифрую. А документы, которые считаю приватными, места занимают немного и их перекачать несложно, если контейнер побился.
Alexeyslav
03.12.2015 14:31Мне не по силам разработать свою систему архивирования данных, а большинство существующих такую функцию не предоставляют. В лучшем случае — проверка контрольной суммы перед восстановлением. А те которые предоставляют, о них я не знаю от слова совсем. Не любят пиариться, или попросту недоступны простым смертным или неудобны для применения в быту.
aik
03.12.2015 15:05Зато версии файлов имеются. Испорчена последняя версия — откатитесь на предпоследнюю.
Alexeyslav
03.12.2015 15:27Не всегда это может быть приемлемым. За день в исходниках можно такого понапридумывать что потом в случае катастрофы за неделю не восстановишь.
aik
03.12.2015 16:12А системы контроля версий для кого придуманы?
Alexeyslav
03.12.2015 17:57Только если внешняя, и работаешь с ней очень аккуратно. А если как раз из бэкапа требуется восстановить само состояние файлов СКВ?
Там много ньюансов…
Да и банально может быть неудобно ежеминутно делать коммит. А у нас еще и требование выставлено не коммитить нерабочие изменения т.к. ночью происходит сборка проекта и на утро все пользуются свежей версией. Т.е. коммит происходит только когда всё окончательно сделал и проверил.aik
04.12.2015 02:25И какой системой бэкапа вы тогда пользуетесь, чтобы не потерять всё, нажитое непосильным трудом за день? Если боитесь, что при перекачке повредится один бит, а cvs пользоваться не можете.
Alexeyslav
05.12.2015 00:01Дома с трудом пополам через нехочу трудится Акронис, а на работе… на ленточку всё сливается по ночам а база данных в непрерывном режиме. Собственно, большая часть рабочих изменений происходит в рамках базы данных.
tazepam
03.12.2015 14:43Зря вы так.
Все сильно зависит от того, что бэкапим и с чем работаем.
Если монтируете видео — наверное и правда облака не вариант.
А если работа в основном с Ms Office то и проблем нет.
У меня все рабочие файлы — меньше 10 гб.
Все это автоматом льется в дропбокс, а дропбокс каждый день пакуется и заливается на рабочий NAS.
Дистрибутивы программ, фильмы и прочее — не бэкапятся — можно перекачать.
Вот с фото веселее — 300 гиг лежат на RAID 1 из серверных хардов + еще на одном харде плюс еще в облаке.
Те все важные файлы всегда лежат минимум в 3х местах.
Провернуть такую же штуку дома не сложно, но дороговато.
Впрочем, судя по статьям, NAS за 20-30к мало кого пугают, так что вообще не вижу проблем для обычного человека.kacang
04.12.2015 06:25Все это автоматом льется в дропбокс, а дропбокс каждый день пакуется и заливается на рабочий NAS
А как из дропбокса в НАС? На НАСе тоже дропбох-клиент стоит?
Кстати, интересная идея. Я тоже о чём-то похожем думал. План был такой:
1. Поднимаем OwnCloud на малине
2. На всех хостах устанавливаем клиент, шарим нужные папки
3. По ночам, малина делает rsync OwnCloud-a в резерв.
Но в конце концов решил не городить велосипед, хотя может быть и стоило…tazepam
04.12.2015 12:39На НАСе тоже дропбох-клиент стоит?
Зачем так сложно?
Дропбокс же просто папка на компе.
Exiland backup её пакует в 9 вечера в пароленный rar и кладет на куда скажут :)
Scf
03.12.2015 11:13Кто-нибудь пользовал ZPAQ?
А то я в свое время поискал-поискал, и, страшно сказать, написал собственную софтину, делающую инкрементальные бэкапы на внешний HDD в формате zipScf
03.12.2015 11:21Собственно причины, по которым я это сделал:
— не требует установки, вся конфигурация в одном месте (чтобы всё не перенастраивать при переустановке системы)
— поддержка инкрементальных бэкапов
— возможность исключать файлы и каталоги по маске (очень актуально при бэкапе своих исходников, чтобы артефакты сборки не захватывать)
ITLav
03.12.2015 15:10Да. и даже написали средство создания резервных копий eterbackup, основанное на zpaq.
Scf
03.12.2015 20:47Посмотрел по-быстрому — описание выглядит очень вкусно. Обязательно поиграюсь. Спасибо за наводку :-)
ivanych
05.12.2015 00:39Считаю, что для домашнего применения самый лучший вариант — это онлайн-бекап типа Крэшплана.
У вас получаются два географически разнесенных хранилища. Сломать оба сразу практически не реально.
Крэшплан при этом хранит инкрементальные бекапы, поэтому на компе можно смело грохнуть файл, он останется в бекапе и в любой момент может быть восстановлен.
Связь с бекапом получается по сети, поэтому скорость не фантастическая, но для домашнего применения это не критично.
При этом весь процесс полностью автоматизирован, лень и забывчивость не помешают регулярному созданию бекапа.
yosemity
Есть еще третья группа — те, кто проверяет бекапы.
Apathetic
Вы имеете ввиду необходимость проверки возможности восстановления из сделанного бекапа?
RicoX
Без этого можете считать что бэкапов у вас нет вообще, особенно если пользуетесь инкрементальными бэкапами, снэпшотами, дедубликацией данных и прочими инструментами, помогающими уменьшить объем бэкапа, но и для полных бэкпов систематическая проверка восстанавливаемости необходима.
Goodkat
А как проверять, кроме как раз в неделю делать полное восстановление на чистый комп?
RicoX
На своем примере. Есть кластер виртуализации на нем куча виртуалок, которые бэкапятся целиком, есть отдельный сервер с гипервизором который из бэкапов периодически стаскивает бэкап каждой из виртуалок скриптом разворачивает у себя, входит внутрь и запускает определенные действия (ansible сценарий) при условии что сценарий выполнен успешно переходит к следующему образу, если сценарий крашится — пишет админу и отдает оповещение в мониторинг. Для БД сценарий похожий, разворачиваем бэкап на специальном тестовом серваке делаем пару контрольных запросов в базу, выполнились — ОК, не выполнились — алярм. Ситуация когда образ побился в процессе бэкапа или переноса не такая частая, но регулярная — пару битых образов в год имеем по разным причинам, без этой проверки можно неожиданно для себя обнаружить, что после факапа или совсем нечего восстанавливать или последний живой бэкап годовой давности.
Goodkat
Я не про энтерпрайз.
Как быть обычному домохозяину с условными ноутбуком, NAS-ом и Dropbox-ом?
Собственно, в статье я и ожидал увидеть ответ на этот вопрос, а там какие-то общие слова и реклама Акрониса.
Gendalph
Бекапить файлы, а не снимать образы.
powerman
1. Определиться с каталогами, которые имеет смысл бэкапить.
Бэкап домашней системы может не позволять вернуть «всё как было» одним нажатием кнопки — это обычно требует слишком много места и/или времени и/или денег — но он должен позволить восстановить все важные файлы и настройки ОС/приложений. Можно позволить себе потерять то, что без проблем можно заново выкачать с торрентов, но не результаты своей работы и не то, восстановление чего потребует слишком много личного времени.
Подбор каталогов для бэкапа потребует некоторого времени, возможно понадобится даже как-то реорганизовать что где лежит на винте. Но в результате можно получить достаточно скромный размер полного бэкапа системы — у меня это порядка 5-6GB (на 3TB винт). Ежедневные инкрементальные бэкапы занимают в 10-20 раз меньше места. Такой объём можно заливать в любое облако достаточно быстро, как и скачивать в случае необходимости.
2. Настроить любую утилиту, которая по расписанию будет раз в сутки делать полные и инкрементальные бэкапы этих каталогов. И крайне желательно — в любом стандартном формате, для распаковки которого не требуется использовать исключительно какую-то одну конкретную утилиту! Особенно платную и/или с закрытыми исходниками — добровольно делать вендор-лок своим бэкапам может только ССЗБ.
3. По тому же расписанию желательно эти бэкапы шифровать (аналогично, какой-нить стандартной и открытой утилитой) и заливать в облако.
4. После чего обязательно необходимо убедиться, что из облака бэкапы удаётся скачать, и у них совпадает контрольная сумма с залитыми файлами (я использую 4shared.com через DAV, так вот, вы удивитесь, как часто после скачивания обнаруживается проблема, и не думаю, что это уникальная «фишка» 4shared).
Alexeyslav
Для простых смертных, даже в том же Акронисе есть функция «проверить бэкап» которую так же можно запланировать. Она пытается восстановить резервную копию «вникуда» и сверяет контрольную сумму результата.
nitro80
У Акрониса раньше (а возможно и сейчас) была распространена проблема, когда архив просто признавался битым спустя некоторое время. А так же, tib-файл сделанный в одной версии, запросто отказывался открываться в другой версии Акрониса. И в-третьих, используют закрытый формат файла, и в случае проблемы из первого пункта вы получаете просто напросто ненужный никому файл, из которого ничего не извлечь.
Alexeyslav
Собственно так и произошло с бэкапом на ленте… полетел винт на сервере, заменили. При восстановлении данных — облом… лента с последним бэкапом не читается. В итоге потеряли все изменения за последние 2 недели.
Apathetic
Интересно, за что мне минусов накидали :)
Я просто задал уточняющий вопрос, потому что из первого комментария не совсем ясно, что имел ввиду его автор. А так да, разумеется бекапы нужно периодически пытаться восстановить.
Greendq
Есть ещё четвёртая категория — те, кто делает бэкапы бэкапов.
yosemity
Кстати, я делаю. Но это уже относится не к категории, а просто к многоуровневому резервному копированию.