Вы находитесь в опасности (скорее всего)!

С появлением крипты их не видел только ленивый:)

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

PS на счет бекапов я подразуумивал решения для конечника , клиента , у которого задача забекапить свой сайт/сайты и БД от них. Т.е. грубо на всё про все 10-50ГБ то что я описал не подходит для хостерской тематики (со стороны хостера)

Момент с объёмом данных необходимых для восстановления - существенный. Я о нём тоже писал - мельком, но фанаты бэкапов решили для себя, что имея бэкапы в наличии (что, конечно, весьма похвально во всех случаях) можно не заморачиваться со скучной работой по поддержанию безопасности, закрытию уязвимостей и вообще любой работе в этом плане с серверами или сайтами. Я все же думаю, что нужно заботиться о текучке по секурности, потому что это даёт возможность бесперебойной работы сервисов или, уж по крайней мере, свести потенциальные даунтаймы к минимуму.

Естественно, что каждый должен выбирать стратегию работы исходя из собственных задач. VPS с каким-нибудь openvpn - вряд ли имеет смысл бэкапить, проще держать наготове конфиги с настройками и, в случае чего - проставить О/С, проставить опенвпн и заменить дефолтные конфиги на свои. От силы минут 20 займёт что вполне приемлемо. Для более существенных ресурсов, предусматриваются другие политики, вот к примеру как можно бэкапить сайт на VPS:

1) Делать локальные бэкапы с хранением в 1, 3, 7 дней и месяц. Пригодится для того, чтобы быстро поправить какие-либо ошибки сделанные на сайте, заменить хакнутый скрипт и т.п.

2) Их же копировать на удалённое хранилище и ротировать с большим периодом (неделя, месяц, несколько месяцев)

3) Раз в три месяца скачивать один из упомянутых бэкапов к себе на ПК или в отдельное хранилище.

За исключением пункта 3) все операции автоматизированы обычно, так что настроив это дело один раз, нужно будет только контролировать ход процесса раз в неделю или в месяц.

Откуда вы знаете какая у меня практика? :)

Конечно не дают, вы пробовали сделать инкрементальный бэкап при 200-400 млн файлов - представляете себе сколько rsync съедает оперативки на сервере клиента при такой процедуре?

про то что надо делать бэкапы tar'ом я ниразу не писал

Да блин сожмите 200-400 млн файлов плюс их инкременты!

Зачем делать слепок потом его поднимать где-то, потом с него делать дамп, если можно перконой тот же слепок делать и его хранить?

Я не фанат закрытых решений под линукс.

Да не нужно мне это у меня свой сервис бэкапов:) Зачем мне писать отзывы о чужих :)

---------- Добавлено 12.09.2019 в 22:48 ----------

Да видел, могу даже боллее точно сказать 6 серверов по 1.2 тб база MySQL при этом таблицы ещё и с сжатием ROW_FORMAT=COMPRESSED

По Вашим сообщениям. Практика использования CDP решений у вас не прослеживается.

Первый прогон будет долгий. Потом будут бэкапиться только изменения бинарно. И да, оно знает какие файлы были изменены и не сканирует при каждом бэкапе все ваши миллионы. Или у вас каждый день новые 200-400 миллионов?

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

Ну так Вы и не написали, все правильно. А спросили как делать. Я ответил. Вы говорите - нет, все плохо, я знаю как лучше. Но как лучше не говорите 🙄

Я предложил попробовать :)

Можно. Это создает нагрузку на файловую систему (нет дельт/изменений файловой системы и оно читает все подряд), бэкапы делаются долго, и хранятся в полном объеме.

Я тоже. Но подобного решения в open source нет.

А зачем Вы тогда спрашиваете как бэкапить? 🙄

Так никто не спорит что второй прогон инкремент не большой будет для передачи его куда-либо.

Я поднимаю два вопроса:

1) Что делать если первый прогон просто не влезает в оперативку сервера из-за большого числа файлов?

2) Что делать если второй прогон передача данных будет не много - но просканировать 200-400 млн файлов на предмет изменений задача такая же ресурсоемкая и опять может скучать недостающей оперативки на сервере - ведь я уже сказал что сервер рабочий и под нагрузкой.

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

Мне интересно кто как делает в сложных ситуациях бэкап, а не в рядовых. Я например знаю людей которые в таких ситуациях просто не делают бэкап вообще потому что при бэкапе сервер у них тупит, без бэкапа работает и так на пределе.

Делаем активно уже 8 лет через ZFS без всяких проблем. Чтобы не ложило сервер используйте lz4 для трансферов

Ну если это не 200 млн в одной папке, то обычно проблем это не вызывает. У нас есть на обслуживании одна +- известная файлопомойка, они когда к нам пришли на обслуживание, у них все складывалось чуть ли не в одну папку. Там были проблемы, и не только с бэкапами. После того как сделали нормальную иерархию - не слышал от админов о проблемах.

В любом случае, задача интересная, я бы пощупал.

А вот тут нет. Нет, не сканирует оно изменения. Только после ребута сервера, когда пропадают кеши. Или обновления агента / модуля. В нормальном режиме оно собирает изменения в момент этих самых изменений (через модуль ядра, что-то типа inotify условно говоря) и отсылает на бэкапилку только измененные дельты. Ему не надо пересчитывать все изменения.

Но в любом случае периодически надо делать полный бэкап, тут надо смотреть по факту во что и как упирается.

Условно говоря, если сервер работает на пределе ресурсов в свопе и любое действие приводит к его исчерпанию то тут проблема не в технологиях бэкапов :)

О, да в одной папке это ахтунг - знаком с этим :))

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

Это в случае демонов и того же акроникса и r1soft наверное, если же демона отслеживающего нет, то жопа, а таких жоп наверное 90% потому как локальные недоадмины просто пытаются обычным rsync это сделать и вот при нем и получают мега скан. И даже не rsync, а tar с архивированием.

Но так часто и бывает к сожалению :) На апгрейд сервера денег нет или это сложно, или не хочется делать апгрейд сервера потому что ну пока вроде как хватает, а то что на бэкап задачу не хватает, ну значит бэкап - плохой. :)

П.С. многие упускают важную особенность DR, не только бекап, но и восстановимость этого самого бекапа.