- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко

В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
alex063, а можно просто поинтересоваться... Вот Вы каждый день ручками делаете бэкапы всех своих сайтов на домашний комп? Только честно :)
Просто когда у хостера спрашиваешь: "Сколько дней хранятся заблокированные аккаунты на сервере?"
ответ: "пару недель точно"
вопрос: "Как часто делаются бэкапы на сторонний сервер? только честно"
ответ: "раз в неделю точно"
вопрос: "точно???"
ответ: "блябуду! чо мне врать то!?"
тогда ты примерно знаешь на что можно рассчитвать в случае каких-то проблем.
Но если слышишь ответы, что "мы каждый день удаляем просроченные на пару дней аккаунты, мы вообще не заморачиваемся с бэкапами", то конечно же будешь сам делать эти бэкапы, выкачивать каждый вечер по 5-6Гб архивов и в конце концов через недельку решишь взять собственный сервер с VDS под бэкапы.
И не надо покрывать безответственность большинства хостеров, которые сначала в грудь пяткой стучат что они лучшие, а потом говорят что клиент лох и сам во всем виноват :)
🍿🍿🍿
RAID-5 например можно на одном диске собрать :) Просто нужно руки иметь...
(Например, если у Вас сейчас 1 винт, а Вам нужно будет добавить еще 2, это идельный выход - raid-5 на одном диске)
Такие руки называются "крюки"
Ваши мнения, господа?!
Это печально.
Ваша история не менее печальна, чем миллион таких же.
Скажите, теперь Вы будете делать бэкапы?
RAID-5 например можно на одном диске собрать Просто нужно руки иметь...
искренне поддерживаю мысль что нужно иметь руки чтобы собрать raid5 на одном диске :)
Ну да, крюки. Но возможность такая есть :) Нет ничего невозможного...
Я что-то не понимаю?:)
RAID по определению это массив.
Как оно может быть на одном диске?
Я что-то не понимаю?:)
RAID по определению это массив.
Как оно может быть на одном диске?
массив разделов 🤪
массив разделов 🤪
redundant array of independent disks — избыточный массив независимых жёстких дисков
Как оно может быть на одном диске?
Это может быть деградированный массив. Например, RAID 1 можно собрать на одном диске, когда заказал сервер в аренду и хостер говорит, что вот "с одним диском в течении часа, а с двумя дисками это не стандартная конфигурация и будет ставиться три дня". Тогда берём с одним диском и дозаказываем второй. Когда диск подключат - просто добавляем второй диск в массив. И это нормально. Так же и с остальными уровнями. так что про "крюки" это через чур, существуют ситуации, когда это действительно надо.
Если заявлен Raid 6, каковы шансы на восстановление?
Еще раз перечитайте свои слова. Ничего не замечаете? Вас развели как ребенка!
Давайте попробуем проанализировать. Судя по тому, что вспомнили о рейде, видимо Вам про него упомянул админ/хостер. Но если вылетел диск из рейда (какой-бы он ни был), то система либо вообще сдохнет (Raid0) либо вообще не шелохнется (Raid1,2,3,4,5,5E,6,10,20,30) - она продолжит читать с оставшегося диска(ов). Не будет такого сценария как "сюда почта отправляется, а сюда нет" или "есть ошибка от MySQL". Другими словами: если умер диск, то либо система испарится в аналах истории либо ничего не изменится кроме извещений от мониторинга.
А значит что? Рейд у Вас не ломался!
Едем дальше. Сбой файловой системы? Ок, допустимо. Но тогда почему данные начали переносить? Любой сбой файловой системы чинится в пару команд. Не чинится только полное затирание дерева с указателями на айноды и их указатели на директории, но тогда бы Вы и систему свою не увидели, а Вы часть ее работы видели как успешно сделанную. Кроме того, такие косяки бывают только с непопулярными ФС типа JFS, Reiser или XFS. Я очень сомневаюсь, что у Вас было что-то кроме ext3/4. В любом случае все это чинится легко. И они перетащили данные на другой сервер. Вы верите в то, что человек начнет перетаскивать, у него часть данных не читается, а он упорно тащит дальше? Бред!
Вывод? Сбоя файловой системы не было!
Едем дальше. Где-то промельнуло, что система не грузится. Но мы то знаем, что она есть - ведь часть писем отправлялась. А значит либо не грузилось начальное ядро либо диск не находили с которого грузится (и то и другое чинится в две команды). Это повод перетаскивать данные? Опять же нет... И даже если решили перетащить, то значит данные остались на исходном сервере? Ведь люди в такой ситуации не станут удалять ничего на всякий случай?
Так что же? Либо кто-то проявил крайне неспортивный подход либо не было этой проблемы вообще.
****
Выясняйте, что у Вас там произошло. Кто-то явно прикрывает другой косяк под предлогом "сбой файловой системы". Это распространная практика свой косяк прикрыть либо сбоем ФС либо ДДоСом. И то и другое типа как форс-мажор и никто вроде бы не виноват. Ничей профессионализм не под вопросом.