Как известно, люди делятся на две категории: те, которые еще не делают бэкапов, и те, которые уже делают.
Я был уверен, что отношусь ко вторым... В общем, дабы немного отвлечься от работы и вас отвлечь, расскажу про свои недавние злоключения.
История началась весьма внезапно и очень не вовремя, как, впрочем, и любая история про восстановление данных.
Встав в 6 утра, но до конца не проснувшись, я сел за свой ноутбук и решил быстренько довершить вчерашнюю работу, связанную с обновлением файлов на сервере, а потом уже приступить к утреннему кофе.
Первым моим действием стало удаление папки с модулями, но в момент нажатия на кнопку «удалить», я заметил, что папка sites/all/files тоже выделена... но, увы, было уже поздно. Где-то на минуту я впал в некоторый ступор, за который быстренько прошел все стандартные стадии от отрицания и гнева до депрессии и принятия. Еще раз на всякий случай проверил, не сплю ли я, — выводы были не утешительными — shit happends.
Тут стоит сказать, что я легким движением руки потер порядка 9000 файлов, это были по большей части фотографии товаров и прочие изображения, pdf-ки etc.
Но на тот момент я еще не осознавал всей серьезности ситуации, поскольку, как я уже говорил, был уверен, что отношусь ко второй категории людей.
Окончательно проснувшись и включив мозг я успокоился, открыл лайв-чат с саппортом и, как уже не раз бывало, попросил восстановить злосчастную папку из бэкапа выходного дня. Ведь мой хостер молодец и делает за меня всю грязную работу по бэкапу данных регулярно, каждую неделю по выходным. Правда, услуга восстановления стоит 15$, но это просто лишний стимул еще раз подумать, прежде чем что-то удалять.
Далее, подошла моя очередь в чате, и у нас состоялся следующий диалог:
(Alex — я, Кристофер - человек-поддержка из Америки)
Christopher Ic: Do you have a backup of your account?
Alex: No! I haven't
Alex: please restore it from your weekend backup. It was very important folder with tons of files
Christopher Ic: I apologize, but we do not take a backup of your account if you are over the disk space or inode usage limits.
Надо сказать, что мой тарифный план в своем описании имел гордую строчку «Disk Space UNLIMITED». Я, разумеется, понимал, что это с лихвой покроется другими незаявленными ограничениями, в чем быстро убедился: на хостинге имелся некий показатель inodes (количество файлов, как я понимаю), который постепенно рос, но на текущий момент не перевалил даже за половину
В общем, тут я еще раз себя ущипнул, перечитал ответ Кристофера и с разрозненными мыслями а-ля WTF!!! продолжил беседу
Alex: haven't you there trash or something like this? may be recently deleted files restoring operation?
Christopher Ic: I will make sure there are no old backups anywhere for you. Just a moment please.
Alex: thank you!
Christopher Ic: You are very welcome.
Christopher Ic: Unfortunately, we do not have any backups for your account. I apologize.
Alex: But I used backup restrore service several times in the past. It costs 15$ for last weekend backup restoration.
Christopher Ic: I checked the backup server and there are no backups for your account. It may have been overwritten.
Alex: But why you've stop making this bakckups? I was relied on this service and you've stoped it without any notification!
Christopher Ic: I apologize, but if you go over 4 GB of disk space or go over 100,000 inodes, your account will not be backed up anymore. Here is a little about that (ссылка, где действительно говорится об этом)
Тут приходит полное понимание того, что это конец. Плюс к этому по какой-то необъяснимой причине я решил, что и база данных тоже уничтожена. Эти две мысли просто разрывали мне мозг
Далее последовали слабые попытки не дать надежде умереть
Christopher Ic: No, we do not have a backup for your account.
Alex: to restore just one file (здесь я имел ввиду бэкап базы, которую, как я полагал, тоже потерял)
Christopher Ic: We do not have anything like that.
Alex: So, no way out?
Christopher Ic: Unfortunately, there is not.
Alex: ok. you should do something with your backup system or notify clients when it's disabled. bye
Christopher Ic: I apologize. Have a great day!!
Alex: great day... yepp... )
Но надежда умерла как пить дать, а меня ждал впереди great day.
Надо сказать, что все было очень плохо, но не ужасно. На локальном сервере я откапал бэкап сайта двухмесячной давности, который я сделал перед тем, как уйти в отпуск. В нем я обнаружил порядка 7000+ файлов, поставил загружаться все это на сервер. И пошел-таки выпить утренний кофе, т.к. нервы уже начали сдавать.
Стоило мне оторваться от монитора, как я осознал, что с базой все в порядке и, вообще, с чего это я взял, что она уничтожена вместе с файлами. Это значительно добавило оптимизму.
Экспресс-анализ таблицы files выдал порядка 1500 отсутствующих файлов и некоторые мысли по поводу возможностей выхода из неприятной ситуации.
Написал письмо редактору сайта, попросил скинуть все фалы (имеющие отношение к сайту), что только есть у него.
После, в течение дня написал скрипт, который делал следующие вещи:
- сканировал все многообразие присланных файлов
- копировал нужные из них (нужного типа) в специальную директорию, попутно транслитерируя имена файлов
- сканировал эту директорию, выстраивая дополнительную таблицу files_recovery с данными о новых файлах (размер, имя, путь и т.д.)
- проходился по таблице files и для отсутствующих файлов искал записи в files_recovery c таким же размером файла
- после чего с помощью нечеткого сравнения строк среди файлов равного размера (бывало, что таких находилось несколько) искал файл с похожим именем файла. По этом двум критериям делался вывод о том, что файл-кандидат подходит. После чего файл-кандидат перемещался туда, где лежал его предшественник.
Всю эту красоту периодически приходилось выводить вот в такие симпатичные таблички, чтобы глазами посмотреть, как обстоят дела:
Таким нехитрым способом удалось довольно быстро восстановить еще порядка 900+ файлов.
На текущий момент имеем потери в ~500 файлов, знаем все их поименно и готовим новую порцию для анализа и восстановления.
Такая вот история, думаю многие из вас сделают из нее полезные выводы и проверят/укрепят свои тылы.
Ну и не стоит забывать, что одно неосторожное движение может обернуться бооольшим геморроем
Комментарии
Сочувствую.
Плюс к этому по какой-то необъяснимой причине я решил, что и база данных тоже уничтожена.
//
Да, если ум в беспокойстве, то что-угодно может в него прийти. После успокоения ситуацию обычно удается стабилизировать. Так ведь во всех областях жизни...
всегда говорил
не работайте над сайтом в неадекватном состоянии
непроснувшись, засыпая, пьяным и тд
Что-то я не вкурил, почему у хостера не было бекапов?
На хостнге есть правило: если у вас больше 4 gb и/или 100 000 файлов, то ваш аккаунт перестает еженедельно бэкапится. Этот момент не сильно афишируется и так получилось, что я его упустил из виду. Хотя могли бы предупредить, когда я перевалил за 100 000.
Ухх, прочитал, аж мурашки пробежали, сам недавно случайно "нажал кнопку", но бекапы были, слава богу.
А еще как-то давно такой случай был - переносил сайт с одного хостинга на другой, работал я под виндой (это важно), переносил сайт от одного хостера к другому, но решил предварительно на локальном серваке посмотреть и что-то поправить, уж не помню что, и распаковал архивчик, а меня в процессе спрашивает так "файл с таким-то именем уже существует, перезаписать его, ну я, не долго думая, кликаю "да для всех". Вобщем открыл сайт на локалке, все, что хотел сделал, и заливаю то, что получилось на новый хостинг.
Через некоторое время замечаю, что вроде картинка была на одной страничке, а теперь нету. Потом обнаружилось, что таких картинок довольно много. Так как прошло уже достаточно много времени, чтобы забыть, что и как я тогда делал, тоже пришлось лезть в базу в таблицу files и искать причину. А оказалась она в том, что для виндоус файлы с именами, в которых отличался регистр символов только были одними и теми-же файлами, в отличие от линукс, вот их то при распаковке я и перезаписывал, а оказалось таких немало на удивление. Слава богу, что изначально полученный от старого хостера архив не был удален, все восстановил.
Вывод: при переносе сайта на другой хостинг(если оба под линуксом) желательно распаковывать архив прямо на новом сервере или быть внимательным при распаковке его под виндой.
Как вариант:
Сканировать гугл или янд и копировать файлы...
Такая же ерунда была с на американском шаред хостинге с «безлимитным» тарифом. Послед того как количество файлов (inode) достигло 50 тыс. хостер вежливо и регулярно стал «просить» уменьшить их кол-во.
Предполагаю, что причина не в объеме дискового пространства, а в том что индексировать или архивировать такое кол-во файлов (даже мелких) очень затратно.
На авто бекап хостинга, думаю никогда полагаться не стоит. Когда все бекапишь сам, как то и спится спокойней. )
Конечно, глупо ждать полностью безлимитного тарифа за небольшие деньги, несмотря на то, что все нынешние хостеры пестрят словом UNLIMITED.
Но реальные ограничения хостер обязан доносить до пользователя, а не размазывать их по форумам и разрозненным страничкам.
Тем более, когда можно вот так вот незаметно их «перешагнуть» и вляпаться в неприятности. Это, я считаю, большой минус моему хостеру, хотя других нареканий за пару лет работы не было.
Самому тоже все не переделать. Если есть такая услуга и за нее берут деньги, почему бы не воспользоваться. Тем более данные клиентов для хостера - это наикритичная штука. Во всяком случае, мне бы хотелось так думать )
Но ключевые моменты, видимо, стоит дублировать. Сейчас думаю о том, как организовать автоматические регулярные бэкапы всех проектов на Amazon EC2.
Пошел делать бэкап
Грустная история, конечно. Но описано хорошо))
Что сказать - на ошибках учимся. При чем как правило только на собственных=(
Лол, Unlimited Disk space и ограничение по inod'aм. Хостер у тебя замечательный наепшик, потому-что ограничение по кол-ву файлов это даже хуже чем по объему.
Ох вспомнил как я с бекапами оракла (Парус) веселился. Теперь бекапится каждую ночь, на три разных сервера.