The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Компания AMD рассматривает возможность более открытой разраб..."
Отправлено Аноним, 27-Мрт-14 17:43 
> Ну, не знаю. Лично у меня Запущенный Firefox с X'ами не крашатся,
> когдя я их перекомпилирую и обновляю используя для этого терминал Xfce.

Казалось бы, при чем тут бэкапы и даже ФС?

> При этом идёт вполне реальная подмена занятых/работающих файлов приложений на их
> новые версии. ;)

Софт обычно или вгружает данные в RAM и ему до лампочки стирание файла, или файл остается открытым пока он используется. Если стереть открытый файл, он не уничтожается. У него пропадет имя, новый файл может занять имя. Но старый файл продолжит существовать пока его не закроют все, он будет доступен по существующим дескрипторам. Деаллокация занимаемого файлом места будет отложена до момента когда файл перестанут использовать. Поэтому глюков меньше чем можно ожидать: старая копия удержит старые используемые файлы, ставшие невидимыми, а новая будет использовать новые копии. Тем не менее, если ты думаешь что на глюки при этом совсем невозможно нарваться - а фиг тебе. Я иногда по мелочи выигрывал в такие лотереи, хотя ничего особо ужасного не случалось. Но это в принципе рандом. За корректность работы произвольной программы при таких фокусах никто не поручится головой.

>> Только вот прерывание сервиса имеет место быть.
> Хомячку открыли глазки и показали, а ему этого не надо,

Ты немного путаешь ситуацию ;). Корм тут - ты. Не кошачий, а троллиный. Почему? Я не стану настаивать что я гуру: есть куда более крутые специалисты. Но я понимаю базовые основы семантики работы с файлами, почему они такие, как это трансформируется в активность ФС, ОС и железа, etc. Поэтому для меня оно как раз вполне логично и предсказуемо, в отличие от изенов и нагуалов. И уж поверь, я в состоянии правильно сбэкапать мои данные без твоих подсказок из разряда "долбани в бубен 3 раза, потом камлай шибко". Мои действия осмысленны и обоснованы. Этим мы и отличаемся. Я компоную мои действия не на основе чтения какого-то древнего шита 1991 года, а на основе моего понимания того как все это работает.

> так как достаточно rsync и dd (и tar) в большинстве его невыразительных случаях.

А какие у меня должны быть выразительные случаи? Ты ожидал увидеть у меня крутую СУБД? Или чего? Ну я тебе пример с диском виртуалки подогнал.

> Ничего — линукс можно ведь просто переустановить — хуже точно не будет!

Это изен пытается троллить, чтоли? Или просто тупит, как обычно?

> А если электричество вырубится, виртуалке всё, кранты? :))

Примерно на том же уровне что и обычному компьютеру, если не наглеть с unsafe буферизацией диска-в-файле.

> Я, как последовательный в своих действиях админ, внутри виртуалки средствами её же
> утилит сделаю dump/restore её ФС (конечно, если она это поддерживает),

Честно говоря, в именно этом случае мне проще бэкапнуть виртуалку целиком - в отличие от основной системы диск VM относительно небольшой. А рестор состояния виртуалки в нормальной ситуации делается за несколко секунд, путем отката на снапшот. Бэкап надо лишь на случай когда диск побился, etc. Нужно не чаще чем запасной парашют. Только вот фигово если запасной парашют потребовался, а его нет.

> по файлам СУБД, редактируя неверные с моей точки зрения пользовательские данные.
> Так и тут. ;)

Флаг в руки. Как на мой вкус - многовато возни с одним хостом. Если системный 80Гб раздел с SSD дампить целиком меня ломает, то бэкапнуть 2Гб диск-в-файле виртуалки я могу. И рестор займет в случае чего разумное время. Хотя в VM большинство факапов откатывается снапшотной механикой, бэкап лишь на случай если это не получилось. В данном случае я считаю что минимизация сущностей ("один файл = бэкап всей VM") перевешивает некую неэффективность. К тому же бэкапаются и все снапшоты, что позволяет быстрый рекавери виртуалки в нужное состояние из любой позы.

> Я привёл почти все варианты решения проблем с несуществующим dump/restore на Ext4.

А самый очевидный, логичный и универсальный tar почему-то забыл.

> имеет смысла, потому как ты даже не задумывался о такой возможности,
> существующей ШТАТНО в немногих классических (да и новых) ФС, используемых в
> продакшене даже под Linux. ;)

Если честно, при бэкапировании чего либо я не очень хочу себе греть голову вопросом какая там ФС и на какую ФС это потом можно будет отресторить без головняка.

Если ты в танке, мои требования к бэкапам:
1) Простота бэкапа/рестора. Эти операции не должны требовать много моего внимания. Я не full-time бэкап-оператор. Поэтому вот так.
2) Разумная эффективность. Я не гоню на пожар, но рестор 10Гб в течение 2 часов меня не устроит. И размер одного бэкапа по 80Гб на машину - тоже. Так что влобовую dd SSD я делать не буду. А вот 2Гб диск-в-файле виртуалки могу и целиком бэкапнуть.
3) Доступность данных. Если все умерло и вообще выгорело синим пламенем, я должен иметь возможность вынуть файл на соседнем компе, etc, используя то что там есть за минимальное время. Вдруг там вопрос на миллион?

> Речь зашла о крутости Ext4, которая не имеет фич, присущих классическим промышленным ФС.

Твой UFS2 так работает, что ему никакие фичи не помогут. Тормозилово без экстентов? В 2014 году? В номинации дисковых технологий фрибздюкам присуждается EPIC FAIL. Делать настолько похабно устроенные ФС в 2014 году - инженерный позор в чистейшем, рафинированном виде, господа.

> Прости пожалуйста. Я всю дорогу талдычу о такой пустяковине, как быстрый, простой
> и очевидный бэкап файлов и метаинформации ФС стандартными средствами.

Я никогда не буду считать это "стандартными средствами" для бэкапов. Просто потому что оно зависит от ФС и ОС. Вот tar, который не парится относительно типа ФС и ОС - на стандартное средство уже может претендовать. Если прижало - вынуть файл из tar'овского бэкапа можно даже на какой-нибудь, простите, винде, если все умерло, файлик надо срочно, а ничего лучше под рукой нет. Или там с использованием ливфлехи какого-то дистра, попавшейся под руку. Может с ограничениями, чихая, коптя и на одном крыле, но миссия будет выполнена. Это - первый приоритет. А расовая вернота может катиться к бздюкам в берлогу. Бжкапы делаются не для того чтобы расовую верноту прокачивать, а для того чтобы в пиковой ситуации не словить большой факап.

> Бэкапиться на ленты совсем необязательно. Можно забэкапить дамп файловой системы в файл.

Вот только дамп файловой системы - штука весьма нишевая. Я такое практикую только для VM, бэкапя целиком диск-в-файле, сугубо потому что так минимизируется сущность ("1 файл на виртуалку"). Для более жирных сущностей типа ФС хоста - tar.

> Кстати, файлы можно пометить флагом "nodump", если их не нужно включать
> в дамп — так будет сохраняться только то, что нужно.

А уж сколько у tar фич есть для включения и исключения файлов...

> tar работает медленнее dump.

А автомобиль ездит медленнее чем ракета летает. Но если мне надо в супермаркет в 2 километрах от дома - я таки не буду готовить стартовую площадку для ракеты. Даже если время в пути можно сократить.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру