У вас очень гипотетический вопрос, так как вы даже не написали какой у вас домен, чтобы хотя бы извне посмотреть spf, dkim, обратную зону, блек листы, где ваш домен находится. Так же для четкого ответа не хватает самого письма со служебной информацией и письма попавшего в спам со служебной информацией.
1) Дедики после не уплаты можно выключать и кушать ничего не будут
2) 2 юнита в стойке сервера занимать будут в любом случае есть клиент, нет клиента, есть новый клиент. Это уже общий расход хостера, который размазывается на всех клиентов.
3) просто 10 суток для хостера тоже не много так как у хостера всегда есть запас серверов и они тоже все простаивают и в данном случае удалив клиента через 10 дней хостер и клиента теряет и 10 дней оплаты, в данном случае если тех. поддержке хостера не плевать можно даже позвонить клиенту - трата на звонок будет 10-50 рублей зато лишний клиент останется.
Ошибка мне кажется том, что в договоре 10 суток, а в уведомлении на 3 дня больше пишет, то есть они этим уведомлением свой же договор нарушают - называя это логической ошибкой, а клиент может быть ждал своей зп, ожидая что вот-вот оплатит, тем более ещё 3 дня в запасе. А потом выходит, что сам дурак, должен был помнить весь договор наизусть.
О, да в одной папке это ахтунг - знаком с этим :))
Тут я даже про бэкап не говорю, хотя наверное все равно делать бэкап и в таком запущенном случае нужно.
Это в случае демонов и того же акроникса и r1soft наверное, если же демона отслеживающего нет, то жопа, а таких жоп наверное 90% потому как локальные недоадмины просто пытаются обычным rsync это сделать и вот при нем и получают мега скан. И даже не rsync, а tar с архивированием.
Но так часто и бывает к сожалению :) На апгрейд сервера денег нет или это сложно, или не хочется делать апгрейд сервера потому что ну пока вроде как хватает, а то что на бэкап задачу не хватает, ну значит бэкап - плохой. :)
Так никто не спорит что второй прогон инкремент не большой будет для передачи его куда-либо.
Я поднимаю два вопроса:
1) Что делать если первый прогон просто не влезает в оперативку сервера из-за большого числа файлов?
2) Что делать если второй прогон передача данных будет не много - но просканировать 200-400 млн файлов на предмет изменений задача такая же ресурсоемкая и опять может скучать недостающей оперативки на сервере - ведь я уже сказал что сервер рабочий и под нагрузкой.
Я лично знаю только костыль, он работает хорошо, но не универсален и под каждого такого клиента приходится затачивать индивидуально.
Мне интересно кто как делает в сложных ситуациях бэкап, а не в рядовых. Я например знаю людей которые в таких ситуациях просто не делают бэкап вообще потому что при бэкапе сервер у них тупит, без бэкапа работает и так на пределе.
Откуда вы знаете какая у меня практика? :)
Конечно не дают, вы пробовали сделать инкрементальный бэкап при 200-400 млн файлов - представляете себе сколько rsync съедает оперативки на сервере клиента при такой процедуре?
про то что надо делать бэкапы tar'ом я ниразу не писал
Да блин сожмите 200-400 млн файлов плюс их инкременты!
Зачем делать слепок потом его поднимать где-то, потом с него делать дамп, если можно перконой тот же слепок делать и его хранить?
Я не фанат закрытых решений под линукс.
Да не нужно мне это у меня свой сервис бэкапов:) Зачем мне писать отзывы о чужих :)---------- Добавлено 12.09.2019 в 22:48 ----------
Да видел, могу даже боллее точно сказать 6 серверов по 1.2 тб база MySQL при этом таблицы ещё и с сжатием ROW_FORMAT=COMPRESSED
1 терабайтную базу софтом от базы бекап вы не сделаете, хуже того потом из дампа восстанавливать такого будете более суток - что не приемлемо.
tar+gzip - супер мега лишняя нагрузка на сервер, плюс если с удаленного FTP из архива в 100 гиг нужно вытащить 1 файлик это тоже супер мега проблемой становится - потому что долго и не удобно.
1) Бинарные снимки это чтение всего диска и большая нагрузка на диск
2) Сжатие - нагрузка и на CPU + так же на диск
3) верификация - дополнительная нагрузка на cpu
4) При бинарном снимке базе mysql и таблицам типа innodb при восстановлении из такого бэкапа бинарного - кирдык
5) Акроникс классно делает бэкап 1-2 терного домашнего диска, но ни как не 200-400 млн файлов и ему так же наплевать, что сервер может от его действий тормозить.
В итоге доп. нагрузка на сервер приведет к глюкам на рабочем сервере, а задача не допустить таких глюк от слова совсем.
А если бэкап настроить на каждый день, то может выйти так что бэкап будет делаться круглосуточно без перерыва.
И добавьте к этому хреновый канал, например от сервера в хетзнера до сервера в москве - хреновый ну как допустим больше 100 мегабит не поднимется из-за посредников.
Какие ещё варианты ?
Вот ответ на ваш вопрос
Если у вас база 100 мег в архиве, и файлов 1 гигобайт, то вариантов море вплоть до домашнего компа.
Но расскажите мне как правильно бэкапить при таких условиях (вопрос ко всем):
1) база MySQL 1 терабайт и постоянно обновляется и добавляются записи
2) файлов порядка 200-400 млн общим объемом 5 терабайт
3) При бэкапе не положить сервер дополнительной нагрузкой.
4) В ответе исключаем вариант - меняем сервер на сервер в 2-10 раз более производительный и тогда бэкап не влияет на рабочую нагрузку сервера.
P.S. Если кого интересует ответ пишите мне в личку, так как здесь это превратится в демагогию, и думаю ответа не дождемся:) *интригую*
Бэкап как услуга - это проверка как сделался бэкап, это отчеты какие ошибки были при создании бэкапа - да да они бывают, например на файле стоят права 000 и бекап в целом сделался, за исключением этого файла, то есть проще говоря, должны быть отчеты уведомления и контроль как сам процесс бэкапа идет. Если этого нет - это не бэкап услуга, это просто, а ля ftp, ssh место и что как там хранится, сохраняется, ротируется и так далее большой большой секрет.
Большинство хостинг компаний бэкап услугу предоставляют просто как место для хранения - поэтому такой бэкап, иногда приводит к безвозвратным потерям данных.
Софт от ISP делает бэкапы - и это лучше, чем ничего, но при этом при создании таких бэкапов создает чрезмерные нагрузки на диски и проц - любовь архивировать весь бэкап в один файл. Если у вас есть запасы мощности на сервере - то это не плохой условно бесплатный вариант.
Битрикс - так же в кавычках шикарно делает бэкап самого себя. И даже любит делать бэкап бэкапов своих же так что место иногда кончается. Возможно это проблема настройки Битрикса, но я такое видел, и опять же любовь делать каждый день архив.
Базы данных MySQL бэкапятся просто шикарно - кто как хочет тот так и делает. Наплевать на кодировку базы, наплевать на кодировку каждой конкретной таблицы, наплевать на триггеры. Сразу 500 таблиц в один дамп файл и если нужно восстановить 1 табличку потом нужно танцы с бубном устраивать.
Ну и самое главное к бэкапам и пользователи и хостеры и админы относятся по остаточному принципу, в кроне настроили вроде делается и забыли.
А то что бэкап это по сути инвестиции ваш собственный проект, а не лишние траты никто почему-то не думает.
