Удалил конфиг,копии нету.Удалял через mc.

1. вдоль.
2. нанять сисадмина.

3. найти таки способ починить. :-) А вариант с конфигом из дампа мне понравился...

И что теперь делать идиотам?

1. вдоль. 2. нанять сисадмина.

3. найти таки способ починить.

NoWay

А вариант с конфигом из дампа мне понравился...

из дампа долго и неудобно. Tar - и проблема решена.

На тот момент, это было равно пьяному стрелочнику, который столкнул 2 поезда. А удалить с помощью мк весь /etc - Это надо быть просто идиотом.

Я два раза уже спасал разрабов. Обращались со словами «Ой, я там удалил один файлик, а он был таааааакой важный» :)

Короче bacula рулит и педалит!

А удалить с помощью мк весь /etc - Это надо быть просто идиотом.

При быстрой работе с клавиатурой - одно неверное движение. Даже при набирая rm -rf, можно пробел не там поставить случайно и корень снести.

Настолько быстрой, что нет полсекунды перепроверить что именно удаляешь?

Даже при набирая rm -rf,

А ты любишь рисковать. Но я имею привычку все по несколько раз проверять, перед тем как тыкнуть в Enter. Желаю тебе по-больше таких работников, будешь премии выписывать :)

у меня просто подобное оч редко,а бэкапы в основном баз данных делаем, тк уж очень они большие, и потеря их критична, сейчас вот гит сделал под сервера, именно для их настроек. теперь раз в день /etc будет в час ночи в гит пушится .

теперь раз в день /etc будет в час ночи в гит пушится

Лучшего старого tar + gzip + ftp/sftp еще ничего не придумали. Ну и rsync конечно же. Хотя пофиг чем бекапить, важна только скорость восстановления.

Ну весь /etc это перебор конечно.

а бэкапы в основном баз данных делаем, тк уж очень они большие

Пичалька

Но я имею привычку все по несколько раз проверять, перед тем как тыкнуть в Enter.

Ну невозможно человеческий фактор исключить. Вопрос стоит не в «если», а в «когда». Вот хоть как проверяй.

представь каждые 3 дня бэкапы на 18 тб....

Базы 18 тб, вы там что сырые данные собираете без агрегации? А на чем базы?

данные по торгам,ставкам,покупка,сделкам,договорам.Пока на мускуле, на следующий год переходим на oracle

Ну у оракла есть кошерный рман, с инкемент бекапами, больше не будете по 18 тб каждые 3 дня делать :)

А мускул с 18 тб базами, вообще шевелиться?

да,самая большая база 2 тб, жрёт много но живёт

Базы весом в террабайты, mySQL, боевые сервера, торги, деньги, нет бекапов основных конфигов, странный админ, удаление важных файлов «одним движением руки»...... Это не тред, а генератор энтропии какойто :)

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

Ну на коленке значит, а контора жмет деньги на норм инфраструктуру

Я не админ и знаю.

У тебя есть возможность не быть таким, значит не будь.

Если для файловой системы, существующей уже лет 30 как и лишь слегка эволюционирующей, нет адекватных, удобных и быстрых средств восстановления - значит, таки быдло таки те, кто её используют, ибо жрут то говно, которое им дают и не морщаться :)

Устранись и иди дворы подметать.

Отвлекли бомжи, случайно сгрёб весь мусор в открытый колодец. Теперь воняет на весь двор.

бэкапы в основном баз данных делаем, тк уж очень они большие, и потеря их критична

А простой не критичен? Если жизннный цикл базы отлажен, то нужно делать репликацию и настраивать pacemaker с corosync'ом на автопереключение в случае отказа одной ноды.
Для оперативных данных бэкап - это то, что эпизодически сливают со slave-ноды и по сути это архив, а не бэкап, поскольку нужен для восстановления исторических данных. Восстановление активного/актуального состояния базы из бэкапа - это даже не маразм, это за гранью добра и зла. Так можно неспешно ковыряя в носу восстанавливать базёнки размером 30Мб - никто особо и не заметит, - но крупные продуктивные системы просто обанкротятся, пока вы там с будете вытягивать свои терабайты.

Короче bacula рулит и педалит!

Бакула - унылое говно для старых пердунов, видавших VAX VMS. В описанном случае удаления файликов - хранение на VCS, которая сама по себе на отказоучтойчивой ФС с избыточностью (например, gluster подойдёт).
Вообще сама техника сливания каких-то непонятных архивов придумана теми, кому бэкап нужен для отчётности. Без снэпшотов это годится только для редко изменяемых данных, но для них хранение в VCS и подробное документирование изменений по-моему ещё более важно.

От уровня плинтуса и сразу до космоса? Ну-ну, видали мы такие проекты :)

Может для вас бакула и говно, но лично меня она спасала (точнее прогеров в моей конторе).

Если бы вы умели писать скрипты, вы бы сделали то же самое существенно проще, не вынося себе мозг талмудом документации бакулы. Бакула хороша пока она пишет на ленточный массив.

Ах если бы да кабы :) Просто я «не видал еще куськину мать» :) Наверное както так! Не могу понять зачем мне писать скрипты, если на серваке и так стоит postgres в который закинул базу bacula, подкинул готовые конфиги, чуть подправил и полетели ...

man extundelete

drvtiny@drvtiny-ot-pc00:~$ f="/home/drvtiny/DRVTIny_$(date +%s).txt"; echo "Date=$(date)" > $f; rm -f $f; sync; sudo extundelete --restore-file $f /dev/sda11WARNING: Extended attributes are not restored.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further data loss.
If the partition is not currently mounted, this message indicates 
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible.  You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n) 
y
Loading filesystem metadata ... 1537 groups loaded.
Loading journal descriptors ... 30797 descriptors loaded.
Writing output to directory RECOVERED_FILES/
Failed to restore file /home/drvtiny/DRVTIny_1398088441.txt
Could not find correct inode number past inode 2.

Не хочет что-то :(

drvtiny@drvtiny-ot-pc00:~$ sudo extundelete --restore-file /file1 /dev/loop7
WARNING: Extended attributes are not restored.
Loading filesystem metadata ... 40 groups loaded.
Loading journal descriptors ... 9 descriptors loaded.
Unable to restore inode 12 (file1): No undeleted copies found in the journal.

На /dev/loop7 - ext3. Создал на ней файлик file1, удалил, отмонтировал... И вот такая загогулина с extundelete. Чего-то не находит она, однако.

Прозреваю проблему в loop. Попробуй на винче. Тьма людей уже не раз этой утилитой пользовалась.

гугли как восстановить текстовый файл в линуксе, там способ есть, который весь текст, удалил ты его или нет сдампит в один текстовик, оттуда уже грепом вытащить. сам так тонну исходников вернул

Лови некропостера...

На Кой Хер Вообще Надо удалять Конфиги? Или это инновационный способ управления в ентерпрайзе такой - удалить один конфиг, скопировать готовый другой?