Здравствуйте!
Сайт крутится на VPS с Ubuntu 22.04 в reg.ru.
Размер диска VPS - 60Гб, объём сайта уже приблизился к 30Гб и стремительно растёт (естественно, 99% размера - это загружаемые пользователями фото, видео и документы). Уже проведена большая работа по сжатию и пока мы храним все файлы вместе с сайтом на том же VPS.
Сейчас мы делаем только ежедневный бэкап БД на тот же сервер и в Яндекс Диск (просто путём синхронизации папки), и еженедельный бэкап всего сервера средствами хостера.
Хотим делать ежедневный бекап всего сайта, и, собственно, вопрос, куда.
Яндекс Диск не подошёл тем, что, во всяком случае у меня, не получилось что-либо загрузить туда по WebDAV, а хранить бэкапы на сервере и синхронизировать их с ЯД - так себе идея из-за стремительно увеличивающегося объёма данных. Пока более или менее рабочим, но весьма странным ввглядит вариант делать бэкап, синхронизировать его с ЯД и удалять - в ЯД он попадёт в корзину, где будет храниться 30 дней и затем автоматически удалится. То есть, нужно следить, чтобы половина объёма диска VPS была свободна для создания одного бэкапа ежедневно, и хранить бэкапы… в корзине яндекс-диска)
Попробовал вариант напрямую синхронизировать с ЯД все загружаемые на сайт файлы, а БД и код архивировать и тоже загружать на ЯД отдельно, но ведь получается не совсем бэкап: файлы синхронизированы в онлайн-режиме, и если, например, удалить их из Яндекса, то будет так себе ситуация - они пропадут и с сайта.
Заказчик хочет, чтобы бекапы хранились в России, поэтому у меня варианты:
- хранить их в корзине ЯД
- попробовать облако mail.ru - судя по описанию, должно работать не способом синхронизации, а именно примонтированием папки к VPS
- хранить в принципе все загружаемые файлы не на VPS, а в облаке. Непонятно, где хранить, и как делать бэкап в таком варианте.
Пожалуйста, поделитесь опытом, кто как делает бекапы и где их хранит (или в принципе хранит загружаемый контент).
может для начала разделить загружаемый контент от ядра сайта. и бэкапить по отдельности.
Тогда для самого сайта может быть хватит возможностей предоставляемых хостером.
А загрузки, если хратить отдельно в облаке, то там обычно вам уже предоставляется определенная защита от потери данных. Я имею ввиду, что облачный провайдер уже позаботился о бэкапе.
Вот-вот, можно
1) разделить на сайт+метаданные(db) и медиаданные+документы
2) хранить инкрементальные бэкапы (чтобы новые бэкапы были минимального размера). Может быть, отделив неизменяемые файлы (медиаданные) в отдельный бэкап.
В чем проблема не понятно - есть же масса услуг хостингов для бекапов. Стоят копейки, доступы самые разные. А хранить бекапы на одном сервере с сайтом - это как защищать дом от пожара промасленной ветошью.
Да, мы, естественно, используем резервное копирование средствами хостера, но для VPS по непонятной мне причине оно делается раз в неделю и доступ к резервной копии предоставляется по запросу в техподдержку ♂️
Причём хостер к вашему ВПС? Хостер только предоставляет железо и каналы. (может ещё бекапить весь ВПС, но то отдельная история). Всё что на ВПС, включая систему бекапов - это исключительно ваша забота. Наймите админа, а ещё лучше - специалиста по вашему движку со знаниями "как бекапить сайты на сторонние хранилища"
согласен, практически любой хостинг даёт норм цены на бекапы.
у нашего - 100Гб 10 долл в мес
ну или в Европе любой известный хостинг от 10 Евро в мес без проблем найти на ваш объём с запасом.
так чтоб вообще спокойно спать - взять два в разных дата-центрах с 5х объёмом в плюс. Суммарно обойдётся от 50 евро в месяц, но это уже надо будет постараться чтобы потерять на них данные ))
ну бэкапы должны быть и у разраба и у клиента, и как они эту хранилку делить будут? а как с ней связываться из внешнего мира? это удобно? а целесообразна ли её покупка только ради бэкапов сайта?
Владислав Лысков, Все решать клиенту. Белый айпишник и настроенный впн это малая цена за удобство.
В конце концов даже Хилари Клинтон держала свои письма на личном сервере
Владимир Коротенко, Белый даже не обязателен, у всех производителей nas-ов давно распространены собственные dyndns для nextcloud приложений. Для доступа пары-тройки разрабов, этого выше крыши. Ну а пара 2Тв дисков позволит хранить ежедневные 60Гб бэкапы в течении месяца
Спасибо за совет! Правильно ли я понимаю, что такую штуку можно примонтировать к VPS как сетевой диск, и настроить к ней доступ для пользователей по ftp?
Я бы рекомендовал другое.
На бэкап сервере поднять sshd там же настроить скрипты для бэкапа.
Для простоты настроить так же логин по сертификату к основному серверу.
То есть действия будут только со стороны бэкап сервера и на основном сервере вообще ничего не надо будет делать.
А к бэкап серверу сможет любой достучаться по ssh ftp сейчас не рекомендуют
Колхозно-дешманский вариант.
Берется банальный офисный системник, ставится у клиента на бесперебойник, на нем Линь с AnyDesk и бэкап по крону - любой, насколько фантазии хватит. Места - завались, гибкость - абсолютная, доступность - достаточная.
Купить пару-тройку максимально простых системников, воткнуть в них большие HDD-диски, поставить любой линукс, разнести по разным физическим местам, соединить в VPN-сеть, которая будет работать на машине с хостингом и делать бэкапы по ночам.
Если денег много, то купить у разных хостеров виртуалок с дисковым местом и бэкапить туда.
Если есть бесплатные дисковые облака, типа яндекса или мэйла, бэкапить и туда. Много бэкапов не бывает.
1.
Купите мини-пк с большим SSD, поставьте в офисе и туда бекапьте.
2.
купите или vps или готовую услугу c FTPS/SFTP для хранения бекапа.
Скриптом или соответствующим ПО бекапить туда с ротацией.
Я себе сам писал bash скрипт, который бекапит сайты/базу/выборочныеПапки в облако mega с ротацией. Удобно.
На яндекс.диске запрещено хранить регулярные бекапы сайта, это нарушение правил использования ресурса яндекс.диск, могут залочить аккаунт, останетесь без бекапов.
Доступа к гиперу хостера нет, снапшоты обычно стоят денег. Можно немного модифицировать вариант от Adamos (годный, в принципе и так) - берется банальный офисный системник, на нем линух, на котором крутится скрипт, который по крону тащит образ через dump. Образ будет размером с занятую часть диска, его можно пожать (хотя конечнео фотки и пр. жмутся не особо)
Восстановление через restore.
Вообще-то я имел в виду скорее rsync - речь вроде бы была про бэкап сайта, а не системы.
И изменения, если тянуть каждый день, отнюдь не гигабайтные...
Adamos, Как всегда, плюсы-минусы.
rsync:
Плюсы - меньше данных в бэкапе - меньше места для хранения, бэкап быстрее
Минусы - после восстановления заново все настраивать
dump:
Плюсы - восстановление "как есть" на дату бэкапа
Минусы - больше места для хранения, бэкап медленее
CityCat4, ну, тут еще кейсы, по которым понадобилось восстановление.
Для сайта это обычно либо кто-то наломал дров, либо ломанули сайт.
Перенастройка сервера под ним обычно не требуется.
Adamos, Собственно код сайта можно и в VCS держать и банально в архив сматывать, да тысячи вариантов. Но вот например хостер криворукий трындыкнул машинку - и аля улю. Тут конечно от самого хостера зависит, но у меня например дважды уже криворукий хостер VPS убивал нафиг.
Спасибо за совет!
И то же самое можно организовать, если арендовать VPS у другого хостера, и на нём по Cron делать rsync?
Не подскажите, куда гуглить, как это настроить? И может ли случиться такое, что если всё испортить на исходном VPS, то автоматический rsync всё испортит и в копии?
Алексей Поваров, Вам нужен версионный бэкап, чтобы можно было откатиться на нужную версию. rsync тут плохо подходит, нужно что-то, умеющее делать инкрементальные и дифференциальные бэкапы.
Вообще, бэкапить код сайта обычно смысла нет, его проще развернуть по новой из того же git'а. Регулярно бэкапить надо базу данных и пользовательские файлы.
Алексей Поваров, Теоретически можно, но я предпочитаю хотя бы бэкапы при себе держать :) Под "кодом сайта" я имел в виду конечно же его наполнение, а не исходники движка :) Наполнение лучше всего вести в VCS, где можно и историю изменений просмотреть и откатиться на нужное состояние.
Алексей Поваров, есть rsnapshot, который на базе rsync умеет делать дифференциальные и инкрементальные бэкапы. Но в реальности я бы смотрел в сторону чего-нить более серьёзного, типа borg.
Если просто делать наивно rsync, то да, в копии будет испорчено при очередной синхронизации.
Вообще, есть и такая стратегия, когда используется lsyncd, который держит почти моментальную копию дерева файлов в каталоге на втором сервере. Тогда даже промежуток времени между регулярными бэкапами будет закрыт - всегда будет актуальная или практически актуальная копия сайта.
Вариант - под систему или под раздел с данными подсунуть drbd с онлайн-репликацией - но это уже намного сложнее и чаще всего используется для виртуальных машин, причём лучше на "короткой" дистанции - типа два соседних сервера (можно даже подключить их по 10 Гбит/с или FibreChannel). И это умеют всякие proxmox из коробки. Но для виртуалки, купленной у хостера, это не особо годится.
Простой
