Между клиентами и AD. NTLM авторизацию поддерживают как минимум четыре. Волне достаточно одного. Настраивать отдельно каждый клиент для нескольких сотен работников — не самое интересное занятие.
Чёрт, рано отправилось.
> ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
Ни разу не сталкивались с DELETE FROM xxx без WHERE, случайно попавшим в продакшн, поскольку программер забыл проверить дописываемую фичу? Или с утечкой пароля, из-за которой кто-то нехороший поправил ненравящиеся ему данные? Поздравляю.
> но фанатизм в бекапах при использовании рейда проявлять явно не стоит
А нафига нужны два экземпляра неправильных данных?
> Плюс можно поверх рейда прикрутить LVM с ротирующимися снапшотами дня на три назад
Вот это уже ближе к истине.
> Зачем например бекап серверов без пользовательских данных — непонятно.
А зачем нужны сервера без пользовательских данных?
> Я не страдаю паранойей
А стоило бы.
> ФС восстанавливается на раз при любых ошибках
Сама ФС, скорее всего, восстановится (хотя сталкивался и с убитой напрочь ext3), только базе, которая в этот момент меняла структуру таблиц, от этого лучше не станет, если не включать журналирование данных.
> ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
RAID любого уровня может спасти только от одной угрозы — физического выхода из строя носителя из строя. А с информацией, между тем, может случиться много чего занятного: выход из строя файловой системы, ошибка ПО или пользователя, приводящая к повреждению данных, диверсия, наконец. Причём в сумме это может оказаться гораздо более вероятным, чем подыхание диска. Таким образом фраза «программный RAID — это просто простой способ делать ваши бекапы» — не более чем миф. Если у меня будет два жёстких диска и нужно будет сделать из них максимально надёжную систему, я не стану делать из них RAID1, а поставлю один диск и буду время от времени подключать второй, чтобы скинуть на него бэкапы. А до рейда дело дойдёт, когда 1) появится больше носителей и 2) потребуется кроме надёжности обеспечить ещё и высокую доступность.
У LVM есть минусы: при отвале одного из дисков сносит всю файловую систему целиком, что может быть болезненным даже при не очень критичных данных. Одно дело восстанавливать информацию с одного погибшего диска и другое — с четырёх. У RAID тоже есть минусы: во-первых, он создаёт иллюзию надёжности и про резервное копирование в итоге часто забывают (к тому же тратится место), во-вторых, его не очень удобно расширять. Я, например, не знаю, как перенести массив с дисков по 1,5 ТБ на 2 ТБ, заменяя диски по очереди, а не сразу.
Не так давно выбирал себе что-нибудь для бэкапа, и rsnapshot понравился больше, чем rdiff-backup. Настройка несколько прозрачнее и удобнее. Несколько уровней копий (ежечасные, ежедневные, и т. д.) с независимыми расписаниями, восстановление до любого состояния простым копированием, и работает, как мне показалось, быстрее.
Понимаю, что должно из коробки. Но не работает. Говорит, мол «The audio playback device HDA Intel (ALC889A Analog) does not work. Falling back to HDA Intel (ALC889A Digital)», делает вид, что что-то играет, а сам при этом молчит. А у меня пока нет бубна правильного диаметра, чтобы объяснить ему, насколько он не прав.
Я не люблю cue. Я очень не люблю cue. Но я не знаю, как без них сохранить данные о промежутках между треками.
Бывают альбомы, в которых стоят стандартные паузы в две секунды и от их изменения ничего толком не изменится. А бывает, что авторы специально меняют длину паузы или даже вставляют вместо тишины какой-нибудь фоновый звук, чтобы достичь какого-то эффекта. И что с этим делать при разбиении на треки — мне лично не совсем понятно. В принципе, можно прикрепить паузу после трека к самому треку, но тогда как восстанавливать оригинальный диск в случае чего? И что делать с паузой перед первым треком?
Поэтому пока я вынужден пользоваться cue. Но я предпочитаю встраивать его в сам файл фубаром (да, под wine, ибо приличного плейера под линукс я пока не нашёл). Был бы счастлив перестать так делать, но не знаю, что делать с гэпами.
Если пункт есть в договоре, но противоречит законодательству, он ничтожен. Подпись под договором при этом значения не имеет. Как соотносится с законом упомянутый пункт, надо разбираться отдельно, я с этой областью не знаком, но выглядит он странно.
> ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
Ни разу не сталкивались с DELETE FROM xxx без WHERE, случайно попавшим в продакшн, поскольку программер забыл проверить дописываемую фичу? Или с утечкой пароля, из-за которой кто-то нехороший поправил ненравящиеся ему данные? Поздравляю.
> но фанатизм в бекапах при использовании рейда проявлять явно не стоит
А нафига нужны два экземпляра неправильных данных?
> Плюс можно поверх рейда прикрутить LVM с ротирующимися снапшотами дня на три назад
Вот это уже ближе к истине.
> Зачем например бекап серверов без пользовательских данных — непонятно.
А зачем нужны сервера без пользовательских данных?
А стоило бы.
> ФС восстанавливается на раз при любых ошибках
Сама ФС, скорее всего, восстановится (хотя сталкивался и с убитой напрочь ext3), только базе, которая в этот момент меняла структуру таблиц, от этого лучше не станет, если не включать журналирование данных.
> ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
Амарок неплох, да. Красивый. Жаль, музыку не играет.
Бывают альбомы, в которых стоят стандартные паузы в две секунды и от их изменения ничего толком не изменится. А бывает, что авторы специально меняют длину паузы или даже вставляют вместо тишины какой-нибудь фоновый звук, чтобы достичь какого-то эффекта. И что с этим делать при разбиении на треки — мне лично не совсем понятно. В принципе, можно прикрепить паузу после трека к самому треку, но тогда как восстанавливать оригинальный диск в случае чего? И что делать с паузой перед первым треком?
Поэтому пока я вынужден пользоваться cue. Но я предпочитаю встраивать его в сам файл фубаром (да, под wine, ибо приличного плейера под линукс я пока не нашёл). Был бы счастлив перестать так делать, но не знаю, что делать с гэпами.