Фото: independent.co.uk
На днях пользователь сайта Serverfault разместил на ресурсе интересный вопрос. Марко Марсала (Marco Marsala) спросил у других пользователей, можно ли после запуска команды rm -rf {foo}/{bar} оперативно восстановить данные. Как оказалось, Марсала является владельцем небольшой хостинг-компании, обслуживающей около 1500 клиентов. Для управления данными и автоматизации процессов он использовал Ansible.
В один из вечеров Марсала случайно ввел команду rm -rf {foo}/{bar}, запустив ее на всех серверах. Переменные {foo}/{bar} пользователь не задал. Изначально Марсала хотел удалить определенные директории на различных серверах, но из-за указанной выше проблемы удалилось все. При этом носители с бэкапами были подключены физически и подмонтированы, поэтому и эти данные были удалены.
Ответов на вопрос было много, и большинство из них указывали на невозможность возвращения всех файлов сколь-нибудь оперативно. Да, что-то восстановить можно, говорили комментаторы, но о восстановлении всех данных можно забыть. В одном из ответов Марко Марсала советовали забыть о восстановлении файлов и обратиться к юристу для предотвращения негативных последствий исковых заявлений клиентов, чьи сайты были уничтожены.
Некоторые комментаторы считают, что данные можно спасти, поскольку «rm -rf» просто помечает блоки данных, как пустые. И если поверх ничего не записывалось, в теории, восстановить можно почти все. Тем не менее, на восстановление понадобится много времени и денег.
Интересно, что два года назад на этом же ресурсе был задан аналогичный вопрос. Тогда за помощью обратился системный администратор, запустивший вот такую вот команду:
sudo rm -rf --no-preserve-root /mnt/hetznerbackup /
По словам незадачливого сисадмина, он осознал ошибку через несколько секунд, но было уже поздно, все данные потихоньку уничтожались. Тогда оказалось, что большинство важных данных были уничтожены, и восстановить их не удалось.
Что же, совет здесь может быть только один — делать бэкапы. Много бэкапов не бывает, при этом они должны храниться так, чтобы не быть случайно уничтоженными, как в этом случае.
UPD. Владелец обратился за помощью к компании, которая занимается восстановлением данных. Как оказалось, все файлы на месте. Но вот позволить себе восстановить эти файлы хостинг-провайдер не в состоянии — слишком большие требуются средства на проведение такой работы для дисков с 1500 серверов.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (83)
MeGaPk
15.04.2016 11:54+1надо быть параноиком. Берем btsync и 2-3 сервера. И эти «бекапные слевы», помечаем как READ ONLY, т.е только скачивание, а удаленные архивы, поместит в скрытую папку.
У меня была похожая ситуация. Вводил команду chown www-data:www-data /var /www
Первым умер PostgreSQL, затем и всё остальное. К Счастью у меня была полная копия другой впс и по ней снял копию правил директорий и файлов, обошлось.
martin74ua
15.04.2016 14:13+2вот за что я и люблю rpm ;)
rpm -a --setperms
rpm -a --setugids
и получаем на всех файлах и каталогах, входящих в состав пакетов правильные права и владельцев.
andrijn
15.04.2016 11:54Нужно использовать бэкапы бэкапов.
alexws54tk
15.04.2016 12:49+4<Kerz> насколько хриново хранить рисунки в базе? <Kerz> давайте все аргументы, я буду шефа переубеждать <Kerz> я уже все тпл в базу зугнал ) * boda если-б мог, даже пхп код загнал в базу. <mex> и саму базу - тоже в базу <boda> дада, и операционку - туда-же <boda> и клаву с мышью, и сам бы залез в базу, и бекапился бы каждый день
bash.im/#470
RusTech
15.04.2016 11:54+1Подскажите, после удаления из под винды, файлы обычно без проблем восстанавливаются софтом вроде GetDataBack итп, а как действует rm -rf /? Там записывается что-то поверх или есть какая то особенность файловой системы, препятствующая восстановлению?
Barsukk
15.04.2016 12:04+2rm это обычная команда удаления файлов с каталогами (-rf), ничего поверх не пишется
Даже на единственном винчестере GetDataBack имеет проблемы, так как пользователю непонятно, когда был удален файл — год назад или только что. Восстановить можно, но какая каша получится в итоге с учетом количества уничтоженных данных.
То есть проблема не восстановить стертые файлы, а потом разобраться в этом месиве.
Alexeyslav
15.04.2016 13:32+2Там проблем особых нет с восстановлением непосредственно файлов, просто в процессе восстановления возникают разного рода неоднозначности, которые решать надо вручную и при помощи дополнительной информации, автоматизировать процесс практически невозможно. И это при условии что информация по цепочкам кластеров файлов не уничтожена.
А это означает что восстановить можно, но чрезвычайно много ручного труда — отсюда и дороговизна операции по восстановлению. Если бы хоть где-то остался слепок таблицы каталогов файлов, то задача по восстановлению файлов легко бы автоматизировалась и прошла за пару часов. Но команды удаления в первую очередь уничтожают её, и даже двойная копия как это происходит с FAT-таблицей уже не поможет. На NTFS мелкие файлы хранятся в некотором роде базе данных, и восстановить их можно в автоматическом режиме, но есть ещё и другие виды файловых систем, где с этим делом всё гораздо хуже.
п.с. надо бы тоже каталог с резервными копиями на NAS подключать только во время резервного копирования. А то чего-то лень, хотя я с самогоначала догадывался о данной возможности. И даже один звоночек был, когда Avast безобидной чисткой мусора выкосил всю винду потому что ему где-то попалась ссылка на С:\Windows и он её посчитал мусором… я ещё подумал что-то он слишком долго очищает мусор, потом полезли ошибки что не хватает такой-то библиотеки, диспетчер задач — а его уже нет… командная строка — интерпретатор не найден… восстанавливать резервную копию, а оказалось они уже 2 месяца не делаются по какой-то причине(Acronis будь он неладен, иногда у него повреждаются задания и соответственно перестают работать). А ещё загрузчика не оказалось свежего, он отказывался понимать бэкапы более новой версии. Пол дня потратил чтобы восстановить систему. Пришлось восстановить бэкап свежеустановленной системы, поставить новый акронис и с его помощью восстановить нужный бэкап. Ох уж эти несовместимости версий.
iTaurus
15.04.2016 11:57+2Учитывая это:
Интересно, что два года назад на этом же ресурсе был задан аналогичный вопрос. Тогда за помощью обратился системный администратор, запустивший вот такую вот команду:
sudo rm -rf --no-preserve-root /mnt/hetznerbackup /
Я выбираю третий вариант в голосовалке
Bytamine
15.04.2016 12:23+2Первые два пункта правильные, но победил последний.
@kkaosninja we consulted a data recovery company who analyzed one of our 1500+ server disks for a reasonable fee, and after diagnoses, sent you a list of recoverable files. All files are here. Now we're finding the money to pay the recovery service for all our servers. – bleemboy 10 hours ago
Todd we exultaded too early. simply we cannot afford the expense for all the servers, because we don't have such amount. game over. – bleemboy 41 mins ago
mr_brain1979
15.04.2016 12:40+1Как показывает практика, нужно не бэкапы делать, а иметь стратегию восстановления после сбоев.
Maklaut
15.04.2016 12:41+6Похоже это троллинг.
На serverfault его уже заподозрили в этом после того как он спросил «I swapped if and of while doing dd. What to do now?».
ValdikSS
15.04.2016 13:03+14Да с самого начала было понятно, что это тролль, что за фигня, нафига все это постят? На опеннете, tjournal, теперь здесь.
- Ни один клиент хостинга не писал, что он пострадал.
- Ansible не даст выполнить команду с неинициализированной переменной.
- rm бы не удалил ничего без --no-preserve-root
SarganSaor
15.04.2016 12:51Какая-то мутная история. Попробовал воспроизвести, у меня это не сработало. Но версия ansible 2.0.1.
Что касается голосования, я все же ответил 1 пунктом. Вытащить данные можно, другой вопрос — размер стораджа для операций. Если речь идет об одном диске это одно, если о хостинг компании… ну не знаю.
centur
15.04.2016 14:02+1Хмм, если почитать комментарии к вопросу на ServerFault — автор — тот еще тролль — «я сделал dd но перепутал if и of».
Вообще afaik, после знатного вопроса про perl (еще с 2004 года) дистибутивы или явно запретили rm -rf / или требуют дополнительного ключа. А уж тем более такой дистриб как CentOS 7 (судя по тегам на вопросе на который ссылается Independent (http://serverfault.com/questions/769357/recovering-from-a-rm-rf)
У кого есть CentOS 7 в виртуалке под рукой — проверьте.
Sild
15.04.2016 19:22Проверил, с --no-preserver-root система очень оперативно становится нерабочей.
Без этого флага команда запускаться отказывается.
Но это всё не на столько нелепые истории, как хотелось бы. Сам по молодости за 2 недели до сдачи курсовой перепутал эти злополучные if\of.
ghostinushanka
15.04.2016 20:06+1marks будьте добры, ^ комментарий centaur в апдейт новости, а то я уже сам хотел написать «что за хрень это» (простите)
rm -rf /
не сотрёт ничего уже много лет как, и если мне не изменяет память ещё и выплюнет в stderr инструкцию КАК это сделать правильно.
Я помнится пару лет назад на спор показывал что «эрэм эрэф рут» — байки.
К слову,
rm -rf /*
Отличается принципиально результатом
aaalllsss
15.04.2016 14:39+1а почему не попробовать восстановить только бекапы? там же будут адекватные имена архивов и уже с них все остальное восстановить
vidyacat
15.04.2016 14:39а мог бы использовать chattr +i, или просто не лезть в рут под рутом
Barafu
15.04.2016 15:09+6Ага. Поясню тем, кто не в теме:
rm -rf удаляет файлы в порядке сортировки, то есть почти по-алфавиту. В корне и в юзерской папке создаём файлы с именем вроде aaaaaaaaaa, то есть чтобы они были первыми в списке на удаление. Делаем каждому
chmod 000 aaaaaaaaa
chattr +i aaaaaaaa
и теперь их не может удалить даже рут. rm -rf будет падать с ошибкой и не удалять ничего. Увы, так нельзя защититься от find -delete. Но виноват обычно именно rm -rf и именно из-за лишнего пробела до/после пути.
moooV
15.04.2016 15:49+7Тянет на отдельный пост, но у меня была похожая история три года назад — я убил базу и многомиллионный бизнес почти накрылся. Причем считаю, что идиоты они, а не я — при организации компании как 10+ менеджеров и один программист/админ этого следовало ожидать рано или поздно.
В общем, есть некая баннерная сеть (сейчас проверил — еще жива), а у нее ушел единственный программист — у них полный ахтунг, попросили через знакомых меня помочь (само собой, без договора и всего такого). Начал разбираться — не документировано вообще ни чего, даны только исходники системыи логин-пасс от дедика. Соответственно, моей задачей было именно разобраться и задокументировать что и как для новых программистов.
Поковырял исходники, полез смотреть в бд. Работал ночью, был упорот, перепутал две одинаковые вкладки phpmyadmin и сделал из продакшен-базы тестовую базу. Жопу обнаружил только когда запустил на продакшене mysqldump и понял, что он как-то быстро завершился.
Побежал за бекапами — а их нет. Пишу в скайп старому программисту с вопросом «Куда делаются бекапы?», он ответил, что вообще не парился с этим, они не предусмотрены, и ему вообще плевать.
Понял, насколько случилась жопа, когда у них на утро встал бизнес и мне позвонили и сказали: «Мы знаем, что у тебя есть квартира — продавай и возмещай.»
Мне чудом повезло, что они использовали стороннюю SAAS систему подсчета кликов/лидов, из которой я сумел вытащить данные за последний месяц. Они потеряли бд за несколько лет, но их волновал только последний месяц и от меня отстали.
Я тогда чуть не поседел, после чего решил уйти из веб-разработки (7 лет опыта на стартапах и хайлоаде к тому моменту) и сделать из хобби работу (3д-графика) — нервы целее будут.
Пару месяцев назад тут тоже была веселая история с кастомной рендер-фермой, но это уже другая история и все решилось намного менее нервно. Но теперь я знаю, что в области 3д влететь на стоимость хаты тоже можно (не влетел).JerleShannara
15.04.2016 16:03+1«Фигово работать с [ЛунаУтка]ми и идиотами, постарайтесь избегать этого»
Hellsy22
15.04.2016 16:04+2Мне кажется, что выводы были некорректные, нужно было менять не область работы, а страну проживания. На такую, где невозможен звонок типа «продавай и возмещай», если материальная ответственность не была прописана в договоре в полном объеме.
moooV
15.04.2016 16:30+1Да давно пытаюсь, но кто бы пригласил (свободный английский плюс два высших).
Сейчас делаю фриланс-заказы для нескольких иностранных студий (две европейских и две японских) — приглашать не торопятся. Если так и дальше пойдет, то поднакоплю и выделю полгода на какую-нибудь короткометражку — чтобы заметил хоть кто-то. А то занавес опускается и надо эвакуироваться как можно быстрее.
Jump
15.04.2016 17:32+5Такой страны нет.
Если материальная ответственность не прописана в договоре, по закону тебе нечего предьявить.
А вне закона — если это бизнес, и там крутятся деньги, и есть злые люди, то они приедут, ибо им пофиг на закон.Hellsy22
15.04.2016 18:37+1Это зависит от цены вопроса. Если послать «злых людей» стоит дороже, чем компенсация, которую можно получить с их помощью, то компания будет искать другие методы решения вопроса. Например, перестанет экономить копейки на бэкапах.
exfizik
15.04.2016 23:11+2А можно без драматизма, просто делать бэкап перед тем, как начинаешь работать с чужими данными.
Dum_spiro_spero
16.04.2016 01:45В лохматых 90-х перед работой с чужими данными сделал бэкап штатными средствами. Поработал. Стал разворачивать бэкап… А бэкап не захотел разворачиваться — причем с крэшем системы — какой-то сбор произошел во время э… «бэкапанья». По счастью нашлись резервные диски месячной давности и дальше вся контора восстанавливала бухгалтерию за месяц. Некий драматизм во всем этом таки присутствовал.
Gorthauer87
15.04.2016 15:51+1Вообще всё зависит от файловой системы, от того как она с файлами работает.
Anshi85
15.04.2016 17:46+1Бэкапы делают только трусы…
А по факту все пишут что нужно делат бэкапы, а еще нужно их проверять, а еще нужно делать полные, частичные бэкапы.
olegkrasnov
15.04.2016 20:27«Клево. Наши админы 5 лет делали бекапы sql, которые невозможно развернуть.
Легко догадаться как это выяснилось.»
bash.im
EmmGold
15.04.2016 18:33А меня на столько прёт после курение мануалов по гиту, что делаю бекапы гитом и бекапы бекапов гитом. Базы не большие ~30-50ГБ Всё вполне сносно работает и за ночь по локалке резервируется.
Разве что сам гит через крон запускаю…Barafu
15.04.2016 23:58А если в файле на 4 гига поменять метаданные — база гита вырастет на 4 гига или на несколько килобайт? И как полностью удалить ненужный большой файл, чтобы место не ел?
EmmGold
18.04.2016 21:50Вырастит только на разницу.
Полностью удалить только из гита, мол — больше не индексировать. Плюс можно взять некое текущее состояние и плясать от него, не таская с собой всё, что было до.Barafu
18.04.2016 22:05Если файл просто удалить из гита — его предыдущие версии останутся в истории гита. Покажите, пожалуйста, команду, которой делаете волшебное полное удаление.
Alexeyslav
18.04.2016 23:24+1Что-то мне подсказывает, что файл весом в 4 гига — двоичный, а значит автоматически не подлежит версионированию, только если его специально назначить таковым… но тогда ССЗБ. Если ГИТ попытается построить разностную версию этого файла, скорей всего он будет гораздо больше оригинала, во много раз и процедура будет длится довольно долго, ведь в двоичных файлах такого размера редко меняются одиночные байты.
Sanes
15.04.2016 18:581500 клиентов или серверов? Если серверов, то это не мелкий хостинг-провайдер, а приличный ЦОД.
Equin0x
15.04.2016 20:54А ведь, раз такой ленивый, достаточно было монтировать бэкапы через autofs. Большую часть времени пути к бэкапу просто бы не было.
servekon
15.04.2016 23:57Помню была веселая ночка после того как решил сделать резервную копию папки /etc на VDS:
gzip -r /etc
Сначала было все в порядке, первым отвалился ssh, а потом и все остальное. Благо были бекапы для дропбоксе.
3ton
Совет «делайте бэкапы» в данной статье как минимум странно звучит, ведь из текста следует что бэкапы были сделаны, но были удалены и они.
alex_shpak
имеется в виду «делайте бэкапы так, чтобы их нельзя было удалить»
Dal
Ага, вон они, лежат в сейфе, попробуй удали консольной командой.
eugzol
Бэкапы в сейфе с 1500 серверов. Не очень удобно :)
sHaggY_caT
Современная ленточная библиотека :)?
Кстати, гигабайт стоит дешевле, чем на HDD
Foolleren
мораль сей басни такова, бэкапы надо не только делать и проверять, а ещё размонтировать после бэкапа.
chaloner
я думаю было бы еще эффективно иметь в штате специалиста, а не специально обученную обезьянку
yefrem
Пару лет назад была история с одним украинским провайдером, у которого произошел пожар. Бекапы были, но они были на серверах в соседних стойках в том же помещении.
Foolleren
Вот что значит поленились сделать нормальное пожаротушение с датчиками открытого пламени, у нас поставили такое, при виде сварки засыпает всё порошком нафиг, а благодаря кривой установке ещё и просто так засыпает время от времени, хотя в любом случае хранить бэкапы в том же городе не безопасно, ну мало ли какое стихийное бедствие приключится.
PKav
Порошок — это ладно. У нас от из-за слегка накосячивших во время протяжки проводки «джамшутов» система пожаротушения пустила в ЦОД газ. Люди еле успели убежать, вонища потом стояла весь день.
А бэкапы лучше тогда хранить в другой стране — кто знает в какой момент компанию, хранящую бэкап, прикроют.
AndreyBerezhnoy
Если комментатор выше говорил про hosting.ua, то в тот момент система пожаротушения вообще была отключена. Им надоели ложные срабатывания :)
orosz
Возможно, идея статьи в следующем: не храните все backup в одном месте.
Делайте три одновременных типа backup:
1) на жесткий диск,
2) на переносной диск
3) в три независимых друг от друга облачных сервиса.
Aksiom
ssneg
Сегодня бывает сложно сказать, какие облачные сервисы от кого независимы. Лучший вариант для профи — ленты.
rstepanov
Если ленты в том же помещении — можно ушатать и их тоже.
Noa69
Достаточно поднять на сервере бекапов механизм создания снапшотов файловой системы. На основных серверах это тоже может быть весьма полезно.
Wesha
https://docs.oracle.com/cd/E23824_01/html/821-1448/gbciq.html
Neuronix
Как насчт бекапов размеров под 300 Тб?) Это будет оооочень дорого)
rstepanov
Со сжатием и дедупликацией — не очень.
Neuronix
Не всё можно жать и данные вполне себе могут слабо дедуплицироваться… Ну ок, 295 Тб — это не сильно меняет вопрос.
izzholtik
Ну данные же типовые, почему бы и нет? Даже если хостер бэкапит только файлы сайтов, без операционок и файлов HTTP сервера, то все сайты, построенные на одинаковых CMS, радостно дедуплицируются. К тому же, на сайтах много текстовых файлов, так что и жаться замечательно будет.
ainu
Там же 95% места — картинки. Которые не сжимаются и уникальные.
sleeply4cat
А что со сжатием у дампов БД?
ainu
Сжимаются примерно в 200 раз. Но если мы имеем большой каталог на стотыщ товаров, то один товар займёт в БД 2-3 kB места, а его картинки 600-900 kB. Опять имеем пресловутые 95%.
Исключение есть — во всяких форумах, вордпрессах, джумлах, битриксах логи посещений и защиты, сессии, пользователи, которые до гигабайт разрастаются, если сайт под атакой ботов-спамеров. В этом случае база может стать основным поедателем места, но такие сайты с хостингов выкидываются — или из-за абуз, или место заканчивается само собой.
JerleShannara
А зачем такой объём писать на ЖД? Лет 12 назад видел презентацию от HP и SUN про ленточное хранилище на какой-то сумасшедший объем,, причём измеряемый в десятках единиц, и это были не Тб. Тогда эта система стоила как боинг, но с тех пор уже поколение стримеров и кассет сменилось, и кажется не один раз.
saboteur_kiev
300 тб? Около 10 килобаксов это дорого для провайдера?
Lorien_Elf
Правило 3-2-1.
tUUtiKKi13
Есть такая поговорка: не клади все яйца в одну мошонку.
fireSparrow
«Если у вас только один бэкап — у вас нет бэкапа.»
и ещё:
«Бэкап нужно хранить отдельно от данных».
MartinX
Бэкапы должны быть распределенные. Если убили локально подмонтированные диски, то где-то в шкафчике должны лежать нетронутые.