Где хранить бэкапы сайта?
Здравствуйте!
Сайт крутится на 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 евро в месяц, но это уже надо будет постараться чтобы потерять на них данные ))
Создайте ему хранилку у него.
Что то типа
https://www.dns-shop.ru/product/3b998ae4e314ed20/s...
или
https://www.dns-shop.ru/product/3b05cd938c583330/s...
Реально решения на земле рулят, как показали последние годы
- ну бэкапы должны быть и у разраба и у клиента, и как они эту хранилку делить будут? а как с ней связываться из внешнего мира? это удобно? а целесообразна ли её покупка только ради бэкапов сайта?
- Владислав Лысков, Все решать клиенту. Белый айпишник и настроенный впн это малая цена за удобство.
В конце концов даже Хилари Клинтон держала свои письма на личном сервере - Владимир Коротенко, Белый даже не обязателен, у всех производителей 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, ну, тут еще кейсы, по которым понадобилось восстановление.
Для сайта это обычно либо кто-то наломал дров, либо ломанули сайт.
Перенастройка сервера под ним обычно не требуется. - CityCat4, Вы ещё про расход трафика забыли, если он платный
- Adamos, Собственно код сайта можно и в VCS держать и банально в архив сматывать, да тысячи вариантов. Но вот например хостер криворукий трындыкнул машинку - и аля улю. Тут конечно от самого хостера зависит, но у меня например дважды уже криворукий хостер VPS убивал нафиг.
- Спасибо за совет!
И то же самое можно организовать, если арендовать VPS у другого хостера, и на нём по Cron делать rsync?
Не подскажите, куда гуглить, как это настроить? И может ли случиться такое, что если всё испортить на исходном VPS, то автоматический rsync всё испортит и в копии? - Алексей Поваров, Вам нужен версионный бэкап, чтобы можно было откатиться на нужную версию. rsync тут плохо подходит, нужно что-то, умеющее делать инкрементальные и дифференциальные бэкапы.
Вообще, бэкапить код сайта обычно смысла нет, его проще развернуть по новой из того же git'а. Регулярно бэкапить надо базу данных и пользовательские файлы. - Алексей Поваров, Теоретически можно, но я предпочитаю хотя бы бэкапы при себе держать :) Под "кодом сайта" я имел в виду конечно же его наполнение, а не исходники движка :) Наполнение лучше всего вести в VCS, где можно и историю изменений просмотреть и откатиться на нужное состояние.
- Алексей Поваров, есть rsnapshot, который на базе rsync умеет делать дифференциальные и инкрементальные бэкапы. Но в реальности я бы смотрел в сторону чего-нить более серьёзного, типа borg.
Если просто делать наивно rsync, то да, в копии будет испорчено при очередной синхронизации.
Вообще, есть и такая стратегия, когда используется lsyncd, который держит почти моментальную копию дерева файлов в каталоге на втором сервере. Тогда даже промежуток времени между регулярными бэкапами будет закрыт - всегда будет актуальная или практически актуальная копия сайта.
Вариант - под систему или под раздел с данными подсунуть drbd с онлайн-репликацией - но это уже намного сложнее и чаще всего используется для виртуальных машин, причём лучше на "короткой" дистанции - типа два соседних сервера (можно даже подключить их по 10 Гбит/с или FibreChannel). И это умеют всякие proxmox из коробки. Но для виртуалки, купленной у хостера, это не особо годится.
Diskstation NAS Synology например
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Хранение резервных копий (бэкапов) сайта является критически важной задачей для обеспечения безопасности и целостности данных. Существует несколько рекомендаций относительно места хранения бэкапов сайта, в зависимости от конкретной ситуации и требований:
1. Локальное хранилище: Это самый простой вариант, когда бэкапы хранятся на том же сервере, где расположен сайт. Однако, это не самое безопасное решение, так как при сбое сервера или его атаке данные могут быть утеряны.
$backupDir = '/var/www/backups';
2. Облачное хранилище: Использование облачных сервисов, таких как Google Drive, Dropbox, Amazon S3, позволяет хранить бэкапы в удаленном и безопасном месте. Это обеспечивает защиту от физических повреждений или кибератак на локальном сервере.
$backupCloud = 'https://www.dropbox.com/backups';
3. Внешний накопитель: Подключение внешнего накопителя к серверу для хранения резервных копий также является хорошим вариантом. Это обеспечивает физическую изоляцию данных и дополнительный уровень безопасности.
$externalDrive = '/mnt/external/backups';
4. Сетевое хранилище: Использование сетевого хранилища (NAS) позволяет хранить бэкапы на отдельном устройстве, подключенном к сети. Это обеспечивает гибкость доступа к данным и дополнительную защиту.
$networkStorage = 'smb://nas/backups';
Важно учитывать требования безопасности, доступности и удобства при выборе места хранения бэкапов сайта. Рекомендуется создавать регулярные резервные копии и проверять их целостность, чтобы обеспечить надежность процесса восстановления данных в случае необходимости.