Comments 89
Совет «делайте бэкапы» в данной статье как минимум странно звучит, ведь из текста следует что бэкапы были сделаны, но были удалены и они.
имеется в виду «делайте бэкапы так, чтобы их нельзя было удалить»
мораль сей басни такова, бэкапы надо не только делать и проверять, а ещё размонтировать после бэкапа.
я думаю было бы еще эффективно иметь в штате специалиста, а не специально обученную обезьянку
Пару лет назад была история с одним украинским провайдером, у которого произошел пожар. Бекапы были, но они были на серверах в соседних стойках в том же помещении.
Вот что значит поленились сделать нормальное пожаротушение с датчиками открытого пламени, у нас поставили такое, при виде сварки засыпает всё порошком нафиг, а благодаря кривой установке ещё и просто так засыпает время от времени, хотя в любом случае хранить бэкапы в том же городе не безопасно, ну мало ли какое стихийное бедствие приключится.
Порошок — это ладно. У нас от из-за слегка накосячивших во время протяжки проводки «джамшутов» система пожаротушения пустила в ЦОД газ. Люди еле успели убежать, вонища потом стояла весь день.
А бэкапы лучше тогда хранить в другой стране — кто знает в какой момент компанию, хранящую бэкап, прикроют.
А бэкапы лучше тогда хранить в другой стране — кто знает в какой момент компанию, хранящую бэкап, прикроют.
Если комментатор выше говорил про hosting.ua, то в тот момент система пожаротушения вообще была отключена. Им надоели ложные срабатывания :)
Возможно, идея статьи в следующем: не храните все backup в одном месте.
Делайте три одновременных типа backup:
1) на жесткий диск,
2) на переносной диск
3) в три независимых друг от друга облачных сервиса.
Делайте три одновременных типа backup:
1) на жесткий диск,
2) на переносной диск
3) в три независимых друг от друга облачных сервиса.
Сегодня бывает сложно сказать, какие облачные сервисы от кого независимы. Лучший вариант для профи — ленты.
Достаточно поднять на сервере бекапов механизм создания снапшотов файловой системы. На основных серверах это тоже может быть весьма полезно.
Как насчт бекапов размеров под 300 Тб?) Это будет оооочень дорого)
Со сжатием и дедупликацией — не очень.
Не всё можно жать и данные вполне себе могут слабо дедуплицироваться… Ну ок, 295 Тб — это не сильно меняет вопрос.
UFO just landed and posted this here
Там же 95% места — картинки. Которые не сжимаются и уникальные.
UFO just landed and posted this here
Сжимаются примерно в 200 раз. Но если мы имеем большой каталог на стотыщ товаров, то один товар займёт в БД 2-3 kB места, а его картинки 600-900 kB. Опять имеем пресловутые 95%.
Исключение есть — во всяких форумах, вордпрессах, джумлах, битриксах логи посещений и защиты, сессии, пользователи, которые до гигабайт разрастаются, если сайт под атакой ботов-спамеров. В этом случае база может стать основным поедателем места, но такие сайты с хостингов выкидываются — или из-за абуз, или место заканчивается само собой.
Исключение есть — во всяких форумах, вордпрессах, джумлах, битриксах логи посещений и защиты, сессии, пользователи, которые до гигабайт разрастаются, если сайт под атакой ботов-спамеров. В этом случае база может стать основным поедателем места, но такие сайты с хостингов выкидываются — или из-за абуз, или место заканчивается само собой.
А зачем такой объём писать на ЖД? Лет 12 назад видел презентацию от HP и SUN про ленточное хранилище на какой-то сумасшедший объем,, причём измеряемый в десятках единиц, и это были не Тб. Тогда эта система стоила как боинг, но с тех пор уже поколение стримеров и кассет сменилось, и кажется не один раз.
300 тб? Около 10 килобаксов это дорого для провайдера?
Правило 3-2-1.
Есть такая поговорка: не клади все яйца в одну мошонку.
«Если у вас только один бэкап — у вас нет бэкапа.»
и ещё:
«Бэкап нужно хранить отдельно от данных».
и ещё:
«Бэкап нужно хранить отдельно от данных».
Бэкапы должны быть распределенные. Если убили локально подмонтированные диски, то где-то в шкафчике должны лежать нетронутые.
надо быть параноиком. Берем btsync и 2-3 сервера. И эти «бекапные слевы», помечаем как READ ONLY, т.е только скачивание, а удаленные архивы, поместит в скрытую папку.
У меня была похожая ситуация. Вводил команду chown www-data:www-data /var /www
Первым умер PostgreSQL, затем и всё остальное. К Счастью у меня была полная копия другой впс и по ней снял копию правил директорий и файлов, обошлось.
У меня была похожая ситуация. Вводил команду chown www-data:www-data /var /www
Первым умер PostgreSQL, затем и всё остальное. К Счастью у меня была полная копия другой впс и по ней снял копию правил директорий и файлов, обошлось.
Нужно использовать бэкапы бэкапов.
<Kerz> насколько хриново хранить рисунки в базе?
<Kerz> давайте все аргументы, я буду шефа переубеждать
<Kerz> я уже все тпл в базу зугнал )
* boda если-б мог, даже пхп код загнал в базу.
<mex> и саму базу - тоже в базу
<boda> дада, и операционку - туда-же
<boda> и клаву с мышью, и сам бы залез в базу, и бекапился бы каждый деньbash.im/#470
Подскажите, после удаления из под винды, файлы обычно без проблем восстанавливаются софтом вроде GetDataBack итп, а как действует rm -rf /? Там записывается что-то поверх или есть какая то особенность файловой системы, препятствующая восстановлению?
rm это обычная команда удаления файлов с каталогами (-rf), ничего поверх не пишется
Даже на единственном винчестере GetDataBack имеет проблемы, так как пользователю непонятно, когда был удален файл — год назад или только что. Восстановить можно, но какая каша получится в итоге с учетом количества уничтоженных данных.
То есть проблема не восстановить стертые файлы, а потом разобраться в этом месиве.
Даже на единственном винчестере GetDataBack имеет проблемы, так как пользователю непонятно, когда был удален файл — год назад или только что. Восстановить можно, но какая каша получится в итоге с учетом количества уничтоженных данных.
То есть проблема не восстановить стертые файлы, а потом разобраться в этом месиве.
Там проблем особых нет с восстановлением непосредственно файлов, просто в процессе восстановления возникают разного рода неоднозначности, которые решать надо вручную и при помощи дополнительной информации, автоматизировать процесс практически невозможно. И это при условии что информация по цепочкам кластеров файлов не уничтожена.
А это означает что восстановить можно, но чрезвычайно много ручного труда — отсюда и дороговизна операции по восстановлению. Если бы хоть где-то остался слепок таблицы каталогов файлов, то задача по восстановлению файлов легко бы автоматизировалась и прошла за пару часов. Но команды удаления в первую очередь уничтожают её, и даже двойная копия как это происходит с FAT-таблицей уже не поможет. На NTFS мелкие файлы хранятся в некотором роде базе данных, и восстановить их можно в автоматическом режиме, но есть ещё и другие виды файловых систем, где с этим делом всё гораздо хуже.
п.с. надо бы тоже каталог с резервными копиями на NAS подключать только во время резервного копирования. А то чего-то лень, хотя я с самогоначала догадывался о данной возможности. И даже один звоночек был, когда Avast безобидной чисткой мусора выкосил всю винду потому что ему где-то попалась ссылка на С:\Windows и он её посчитал мусором… я ещё подумал что-то он слишком долго очищает мусор, потом полезли ошибки что не хватает такой-то библиотеки, диспетчер задач — а его уже нет… командная строка — интерпретатор не найден… восстанавливать резервную копию, а оказалось они уже 2 месяца не делаются по какой-то причине(Acronis будь он неладен, иногда у него повреждаются задания и соответственно перестают работать). А ещё загрузчика не оказалось свежего, он отказывался понимать бэкапы более новой версии. Пол дня потратил чтобы восстановить систему. Пришлось восстановить бэкап свежеустановленной системы, поставить новый акронис и с его помощью восстановить нужный бэкап. Ох уж эти несовместимости версий.
А это означает что восстановить можно, но чрезвычайно много ручного труда — отсюда и дороговизна операции по восстановлению. Если бы хоть где-то остался слепок таблицы каталогов файлов, то задача по восстановлению файлов легко бы автоматизировалась и прошла за пару часов. Но команды удаления в первую очередь уничтожают её, и даже двойная копия как это происходит с FAT-таблицей уже не поможет. На NTFS мелкие файлы хранятся в некотором роде базе данных, и восстановить их можно в автоматическом режиме, но есть ещё и другие виды файловых систем, где с этим делом всё гораздо хуже.
п.с. надо бы тоже каталог с резервными копиями на NAS подключать только во время резервного копирования. А то чего-то лень, хотя я с самогоначала догадывался о данной возможности. И даже один звоночек был, когда Avast безобидной чисткой мусора выкосил всю винду потому что ему где-то попалась ссылка на С:\Windows и он её посчитал мусором… я ещё подумал что-то он слишком долго очищает мусор, потом полезли ошибки что не хватает такой-то библиотеки, диспетчер задач — а его уже нет… командная строка — интерпретатор не найден… восстанавливать резервную копию, а оказалось они уже 2 месяца не делаются по какой-то причине(Acronis будь он неладен, иногда у него повреждаются задания и соответственно перестают работать). А ещё загрузчика не оказалось свежего, он отказывался понимать бэкапы более новой версии. Пол дня потратил чтобы восстановить систему. Пришлось восстановить бэкап свежеустановленной системы, поставить новый акронис и с его помощью восстановить нужный бэкап. Ох уж эти несовместимости версий.
Учитывая это:
Интересно, что два года назад на этом же ресурсе был задан аналогичный вопрос. Тогда за помощью обратился системный администратор, запустивший вот такую вот команду:
sudo rm -rf --no-preserve-root /mnt/hetznerbackup /
Я выбираю третий вариант в голосовалке
Интересно, что два года назад на этом же ресурсе был задан аналогичный вопрос. Тогда за помощью обратился системный администратор, запустивший вот такую вот команду:
sudo rm -rf --no-preserve-root /mnt/hetznerbackup /
Я выбираю третий вариант в голосовалке
Первые два пункта правильные, но победил последний.
@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
@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
Как показывает практика, нужно не бэкапы делать, а иметь стратегию восстановления после сбоев.
Похоже это троллинг.
На serverfault его уже заподозрили в этом после того как он спросил «I swapped if and of while doing dd. What to do now?».
На serverfault его уже заподозрили в этом после того как он спросил «I swapped if and of while doing dd. What to do now?».
Какая-то мутная история. Попробовал воспроизвести, у меня это не сработало. Но версия ansible 2.0.1.
Что касается голосования, я все же ответил 1 пунктом. Вытащить данные можно, другой вопрос — размер стораджа для операций. Если речь идет об одном диске это одно, если о хостинг компании… ну не знаю.
Что касается голосования, я все же ответил 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 в виртуалке под рукой — проверьте.
Вообще afaik, после знатного вопроса про perl (еще с 2004 года) дистибутивы или явно запретили rm -rf / или требуют дополнительного ключа. А уж тем более такой дистриб как CentOS 7 (судя по тегам на вопросе на который ссылается Independent (http://serverfault.com/questions/769357/recovering-from-a-rm-rf)
У кого есть CentOS 7 в виртуалке под рукой — проверьте.
Проверил, с --no-preserver-root система очень оперативно становится нерабочей.
Без этого флага команда запускаться отказывается.
Но это всё не на столько нелепые истории, как хотелось бы. Сам по молодости за 2 недели до сдачи курсовой перепутал эти злополучные if\of.
Без этого флага команда запускаться отказывается.
Но это всё не на столько нелепые истории, как хотелось бы. Сам по молодости за 2 недели до сдачи курсовой перепутал эти злополучные if\of.
marks будьте добры, ^ комментарий centaur в апдейт новости, а то я уже сам хотел написать «что за хрень это» (простите)
не сотрёт ничего уже много лет как, и если мне не изменяет память ещё и выплюнет в stderr инструкцию КАК это сделать правильно.
Я помнится пару лет назад на спор показывал что «эрэм эрэф рут» — байки.
К слову,
Отличается принципиально результатом
rm -rf /
не сотрёт ничего уже много лет как, и если мне не изменяет память ещё и выплюнет в stderr инструкцию КАК это сделать правильно.
Я помнится пару лет назад на спор показывал что «эрэм эрэф рут» — байки.
К слову,
rm -rf /*
Отличается принципиально результатом
а почему не попробовать восстановить только бекапы? там же будут адекватные имена архивов и уже с них все остальное восстановить
а мог бы использовать chattr +i, или просто не лезть в рут под рутом
Ага. Поясню тем, кто не в теме:
rm -rf удаляет файлы в порядке сортировки, то есть почти по-алфавиту. В корне и в юзерской папке создаём файлы с именем вроде aaaaaaaaaa, то есть чтобы они были первыми в списке на удаление. Делаем каждому
chmod 000 aaaaaaaaa
chattr +i aaaaaaaa
и теперь их не может удалить даже рут. rm -rf будет падать с ошибкой и не удалять ничего. Увы, так нельзя защититься от find -delete. Но виноват обычно именно rm -rf и именно из-за лишнего пробела до/после пути.
rm -rf удаляет файлы в порядке сортировки, то есть почти по-алфавиту. В корне и в юзерской папке создаём файлы с именем вроде aaaaaaaaaa, то есть чтобы они были первыми в списке на удаление. Делаем каждому
chmod 000 aaaaaaaaa
chattr +i aaaaaaaa
и теперь их не может удалить даже рут. rm -rf будет падать с ошибкой и не удалять ничего. Увы, так нельзя защититься от find -delete. Но виноват обычно именно rm -rf и именно из-за лишнего пробела до/после пути.
хоть и прошёл уже месяц, я всё же напишу, чтобы случайный прохожий не был в ложной уверенности, что он в безопасности.
я «не в теме», но хотел бы пояснить пару моментов тем, кто разбирается:
rm идёт рекурсивно, как и find. если он встречает кривой неудаляемый файл, то он не останавливается на нём, а выплёвывает ошибку, пропускает его и идёт дальше.
chmod 000, кстати, тут совсем не обязателен. chattr достаточно (почитайте man что ли, чтобы понять почему).
к тому же года этак с 2006 в большинстве систем rm -rf / не работает (вот коммит в исходниках, который отключил такое поведение по умолчанию).
нужно добавлять специальную опцию --no-preserve-root, иначе выстрелить вногу голову не получится.
такие дела.
PS. можно не верить мне на слово, а сходить в консоль и элементарно проверить:
я «не в теме», но хотел бы пояснить пару моментов тем, кто разбирается:
rm идёт рекурсивно, как и find. если он встречает кривой неудаляемый файл, то он не останавливается на нём, а выплёвывает ошибку, пропускает его и идёт дальше.
chmod 000, кстати, тут совсем не обязателен. chattr достаточно (почитайте man что ли, чтобы понять почему).
к тому же года этак с 2006 в большинстве систем rm -rf / не работает (вот коммит в исходниках, который отключил такое поведение по умолчанию).
нужно добавлять специальную опцию --no-preserve-root, иначе выстрелить в
такие дела.
PS. можно не верить мне на слово, а сходить в консоль и элементарно проверить:
# mkdir -p test/{1,2}/{3,4}
# touch test/{1,2}{a,/c}
# find test/
test/
test/2a
test/1
test/1/4
test/1/c
test/1/3
test/2
test/2/4
test/2/c
test/2/3
test/1a
# chattr +i test/2a
# rm -r test/
rm: cannot remove ‘test/2a’: Operation not permitted
# find test/
test/
test/2a
— Зачем вы запустили rm -rf?
— Я случайно…
— Я случайно…
1500 серверов на 1500 клиентов?
Пост на serverfault удалили, btw.
Тянет на отдельный пост, но у меня была похожая история три года назад — я убил базу и многомиллионный бизнес почти накрылся. Причем считаю, что идиоты они, а не я — при организации компании как 10+ менеджеров и один программист/админ этого следовало ожидать рано или поздно.
В общем, есть некая баннерная сеть (сейчас проверил — еще жива), а у нее ушел единственный программист — у них полный ахтунг, попросили через знакомых меня помочь (само собой, без договора и всего такого). Начал разбираться — не документировано вообще ни чего, даны только исходники системыи логин-пасс от дедика. Соответственно, моей задачей было именно разобраться и задокументировать что и как для новых программистов.
Поковырял исходники, полез смотреть в бд. Работал ночью, был упорот, перепутал две одинаковые вкладки phpmyadmin и сделал из продакшен-базы тестовую базу. Жопу обнаружил только когда запустил на продакшене mysqldump и понял, что он как-то быстро завершился.
Побежал за бекапами — а их нет. Пишу в скайп старому программисту с вопросом «Куда делаются бекапы?», он ответил, что вообще не парился с этим, они не предусмотрены, и ему вообще плевать.
Понял, насколько случилась жопа, когда у них на утро встал бизнес и мне позвонили и сказали: «Мы знаем, что у тебя есть квартира — продавай и возмещай.»
Мне чудом повезло, что они использовали стороннюю SAAS систему подсчета кликов/лидов, из которой я сумел вытащить данные за последний месяц. Они потеряли бд за несколько лет, но их волновал только последний месяц и от меня отстали.
Я тогда чуть не поседел, после чего решил уйти из веб-разработки (7 лет опыта на стартапах и хайлоаде к тому моменту) и сделать из хобби работу (3д-графика) — нервы целее будут.
Пару месяцев назад тут тоже была веселая история с кастомной рендер-фермой, но это уже другая история и все решилось намного менее нервно. Но теперь я знаю, что в области 3д влететь на стоимость хаты тоже можно (не влетел).
В общем, есть некая баннерная сеть (сейчас проверил — еще жива), а у нее ушел единственный программист — у них полный ахтунг, попросили через знакомых меня помочь (само собой, без договора и всего такого). Начал разбираться — не документировано вообще ни чего, даны только исходники системыи логин-пасс от дедика. Соответственно, моей задачей было именно разобраться и задокументировать что и как для новых программистов.
Поковырял исходники, полез смотреть в бд. Работал ночью, был упорот, перепутал две одинаковые вкладки phpmyadmin и сделал из продакшен-базы тестовую базу. Жопу обнаружил только когда запустил на продакшене mysqldump и понял, что он как-то быстро завершился.
Побежал за бекапами — а их нет. Пишу в скайп старому программисту с вопросом «Куда делаются бекапы?», он ответил, что вообще не парился с этим, они не предусмотрены, и ему вообще плевать.
Понял, насколько случилась жопа, когда у них на утро встал бизнес и мне позвонили и сказали: «Мы знаем, что у тебя есть квартира — продавай и возмещай.»
Мне чудом повезло, что они использовали стороннюю SAAS систему подсчета кликов/лидов, из которой я сумел вытащить данные за последний месяц. Они потеряли бд за несколько лет, но их волновал только последний месяц и от меня отстали.
Я тогда чуть не поседел, после чего решил уйти из веб-разработки (7 лет опыта на стартапах и хайлоаде к тому моменту) и сделать из хобби работу (3д-графика) — нервы целее будут.
Пару месяцев назад тут тоже была веселая история с кастомной рендер-фермой, но это уже другая история и все решилось намного менее нервно. Но теперь я знаю, что в области 3д влететь на стоимость хаты тоже можно (не влетел).
«Фигово работать с [ЛунаУтка]ми и идиотами, постарайтесь избегать этого»
Мне кажется, что выводы были некорректные, нужно было менять не область работы, а страну проживания. На такую, где невозможен звонок типа «продавай и возмещай», если материальная ответственность не была прописана в договоре в полном объеме.
Да давно пытаюсь, но кто бы пригласил (свободный английский плюс два высших).
Сейчас делаю фриланс-заказы для нескольких иностранных студий (две европейских и две японских) — приглашать не торопятся. Если так и дальше пойдет, то поднакоплю и выделю полгода на какую-нибудь короткометражку — чтобы заметил хоть кто-то. А то занавес опускается и надо эвакуироваться как можно быстрее.
Сейчас делаю фриланс-заказы для нескольких иностранных студий (две европейских и две японских) — приглашать не торопятся. Если так и дальше пойдет, то поднакоплю и выделю полгода на какую-нибудь короткометражку — чтобы заметил хоть кто-то. А то занавес опускается и надо эвакуироваться как можно быстрее.
Такой страны нет.
Если материальная ответственность не прописана в договоре, по закону тебе нечего предьявить.
А вне закона — если это бизнес, и там крутятся деньги, и есть злые люди, то они приедут, ибо им пофиг на закон.
Если материальная ответственность не прописана в договоре, по закону тебе нечего предьявить.
А вне закона — если это бизнес, и там крутятся деньги, и есть злые люди, то они приедут, ибо им пофиг на закон.
А можно без драматизма, просто делать бэкап перед тем, как начинаешь работать с чужими данными.
В лохматых 90-х перед работой с чужими данными сделал бэкап штатными средствами. Поработал. Стал разворачивать бэкап… А бэкап не захотел разворачиваться — причем с крэшем системы — какой-то сбор произошел во время э… «бэкапанья». По счастью нашлись резервные диски месячной давности и дальше вся контора восстанавливала бухгалтерию за месяц. Некий драматизм во всем этом таки присутствовал.
Если не сложно, подскажите ссылку на эту историю, которая была пару месяцев назад (про ферму)
Вообще всё зависит от файловой системы, от того как она с файлами работает.
Бэкапы делают только трусы…
А по факту все пишут что нужно делат бэкапы, а еще нужно их проверять, а еще нужно делать полные, частичные бэкапы.
А по факту все пишут что нужно делат бэкапы, а еще нужно их проверять, а еще нужно делать полные, частичные бэкапы.
«Клево. Наши админы 5 лет делали бекапы sql, которые невозможно развернуть.
Легко догадаться как это выяснилось.»
bash.im
Легко догадаться как это выяснилось.»
bash.im
А меня на столько прёт после курение мануалов по гиту, что делаю бекапы гитом и бекапы бекапов гитом. Базы не большие ~30-50ГБ Всё вполне сносно работает и за ночь по локалке резервируется.
Разве что сам гит через крон запускаю…
Разве что сам гит через крон запускаю…
А если в файле на 4 гига поменять метаданные — база гита вырастет на 4 гига или на несколько килобайт? И как полностью удалить ненужный большой файл, чтобы место не ел?
Вырастит только на разницу.
Полностью удалить только из гита, мол — больше не индексировать. Плюс можно взять некое текущее состояние и плясать от него, не таская с собой всё, что было до.
Полностью удалить только из гита, мол — больше не индексировать. Плюс можно взять некое текущее состояние и плясать от него, не таская с собой всё, что было до.
Если файл просто удалить из гита — его предыдущие версии останутся в истории гита. Покажите, пожалуйста, команду, которой делаете волшебное полное удаление.
А предыдущие версии я и не трогаю. Но можно взять снимок текущего состояния, уже без файла, а не таскать с собой всю историю.
А по поводу волшебной команды, вполне легко гуглится, но я подобным не пользовался. Например:
А по поводу волшебной команды, вполне легко гуглится, но я подобным не пользовался. Например:
1. Нужно найти все коммиты, которые изменяли файл:
git log --pretty=oneline --branches -- BIGFILE.ZIP
2.1 Удалить ссылки на файл из всей истории коммитов, начиная с последнего (пусть, хеш последнего коммита - 6df7640):
git filter-branch --index-filter 'git rm --cached BIGFILE.ZIP --ignore-unmatch' --prune-empty --tag-name-filter cat -- --all
2.2 Удалить ссылки на каталог из истории коммитов:
git filter-branch --force --index-filter 'git rm -r --cached --ignore-unmatch BIG/DIR' --prune-empty --tag-name-filter cat -- --all
3. Отправляем изменения на сервер:
git push --force
Что-то мне подсказывает, что файл весом в 4 гига — двоичный, а значит автоматически не подлежит версионированию, только если его специально назначить таковым… но тогда ССЗБ. Если ГИТ попытается построить разностную версию этого файла, скорей всего он будет гораздо больше оригинала, во много раз и процедура будет длится довольно долго, ведь в двоичных файлах такого размера редко меняются одиночные байты.
Я тут узнал, что этот владелец просто решил потроллить специалистов.
testdisk утилита и вперед!
1500 клиентов или серверов? Если серверов, то это не мелкий хостинг-провайдер, а приличный ЦОД.
А ведь, раз такой ленивый, достаточно было монтировать бэкапы через autofs. Большую часть времени пути к бэкапу просто бы не было.
Помню была веселая ночка после того как решил сделать резервную копию папки /etc на VDS:
gzip -r /etc
Сначала было все в порядке, первым отвалился ssh, а потом и все остальное. Благо были бекапы для дропбоксе.
gzip -r /etc
Сначала было все в порядке, первым отвалился ssh, а потом и все остальное. Благо были бекапы для дропбоксе.
Интересно, команда
rm -rf /
Sign up to leave a comment.
rm -rf: легкий способ уничтожить свой интернет-бизнес и свою репутацию