Про шкідливість бекапів

За все потрібно подбати заздалегідь, тим більше, якщо справа стосується чогось важливого. Для ІТ це, насамперед, резервне копіювання інформації. Холодним осіннім вечором вирішив нарешті зробити автоматизовану синхронізацію одного сервера з іншим, віддаленим. Щоб руцями кожен раз не копіювати. Поки розібрався, поки то сьо, нарешті запрацювало ) Ну я під рутом і схотів синхронізнути /etc, лишень переплутав і зробив це в зворотній бік.
Наслідок – етсерти порожні. Я ж бо хотів цю директорію теж зберегти від гріха подалі. Зберіг.

Сапорт не при дєлах.

Здравствуйте, мы можем лишь переустановить ОС с потерей всех текущих данных на сервере. Мы не создаем и не храним никаких бэкапов клиентских серверов.

Спокійно. Не втрачати голову. В моєму розпорядженні активне з’єднання ssh. FTP не працює, звісно. Нічого страшного, руцями з’єднатись до того резервного файлсервера і потрошки туди попереносити всі файли.
Тааак-с, ще живий апач, народ навіть не підозрює який дамокловий меч навис над ресурсами. Вебсервер це добре, запасний phpmyadmin ще краще, кожну базу акуратно скласти собі, щоб не втратити зміни за останню добу.

Хвилювання на рахунок того, щоб не втратити з’єднання ssh. Тоді буде дуже дуже зле. Упаси Господи, щоб пропало світло, щось зависло, виключився 3G. На рахунок останнього обережно, – особливо не навантажувати, і так дані всі йдуть магістральними каналами.

Бекапи є, щоправда не першої свіжості, а от бекапу системи нема. Ех, шкода як, ціла ніч піде котику під хвостик. Видать, треба розгортати свіжу систему і робити все як було якнайшвидше. Конфіги по пам’яті повідновлювати…

В цей момент рветься з’єднання, з напружених вуст зривається вигук розпачу “БЛЯ!!!” і йдеться курити :)

Сапорт знову курить бамбук

Мы не имеем доступа к клиентским данным, поэтому, к сожалению, вынуждены отказать Вам в вашей просьбе.

З живих залишається apache, mysql і nginx. Таааак, мозг, працюй. (Звісно, можна забити і обійтись тим, що є, і так більшість бекапів в адекватному стані)

Але існуючим бекапам бракує кілька каталогів з файлами, ну нічого,

wget -r -l 0 -np http://host/dir

Врятує батька російської демократії.

Оновлений код можна отримати, залишився шел JoomlaXprorer, ним і ці можна витягти… Продовжується.

Ох, як же я намахався з установкою mysql-server… З testing і unstable ну ніяк не вставав, точніше не стартував, довелось класти руцями з stable і потім оновляти. Як наслідок, безсонна ніченька і напружений день благословили сервак на подальне існування і тим самим врятували мене від сепуку.

А відтак потрібно бути -мудрішим- обережнішим.

Актуальні вакансії в сфері IT можна переглянути на сайті Jooble

Бекапи осилив таки, напишу якось.

This entry was posted in GNU\Linux, Просто інформація, Розробка web. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

6 Comments

  1. Posted 19.10.2010 at 09:57 | Permalink

    Жуть. Це така плата за голий сервачок? А якби був звичайний хостинг, то такий трабл міг би приключитися? А сапорт справді не має доступу до клієнтських даних?

    • Posted 19.10.2010 at 12:44 | Permalink

      Зрештою, досить логічно, що служба підтримки не пхається до окремих обчислювальних одиниць. Хтозна, що там за операційка, файлова система і т д. Треба подбати самому про такі штуки.
      На shared хостингу провайдер послуг, як правило, робить резервні копії. Щоправда, в інтересах себе, а не клієнта. За всіх не скажу, але цілком можлива ситуація, коли щось стається з вини хостера, він відновлює дані з бекапу, якщо клієнт щось псує, може не дати резервних даних.

      • Posted 19.10.2010 at 13:19 | Permalink

        Ммм, а тупо на файловому рівні вони не могли відновити тобі те, шо ти стер? Якщо навіть на віндузятних десктопах є такий функціонал, то на адвансед сервері і поготів мало би бути…

        • Posted 19.10.2010 at 16:27 | Permalink

          Andy, якраз на адвансед серверах все занадто адвансед, файловий рівень в ідеалі недоступний обслуговуючому персоналу це раз, а два, що не мали звідки відновлювати на файловому рівні.

          P.S. KVM теж нічим не допоможе, так як залогінитись в систему не вийде ніяк.

  2. Posted 19.10.2010 at 12:53 | Permalink

    Ще згадав одну мульку. Коли дампив бази, не довго думаючи зберіг базу “mysql”, щоб не заморочуватись з привілеями. Коли імпортнув її вже заново, отримав як наслідок набір глючків невеликих. Типу, не мож зупинити сервер, чи якийсь трабл із входом. Насправді, такі дії з сервером БД здійснює внутрішній привілейований юзер debian-sys-maint, якому я змінив пасворд. Піддивитись, щоб покласти коректний пароль можна в /etc/mysql/debian.cnf

  3. Strange_V
    Posted 20.10.2010 at 10:29 | Permalink

    Мдаа, сумно вийшло.
    Одним словом, перед налаштуванням бекапів, треба спершу вручну зробити повний бекап)

Post a Comment

You must be logged in to post a comment.