Нормальный nas с дисками стоит баксов 200-300 + доступ в инет + статический ip. Либо если статик ip не дают, можно сделать через ipv6 и через сервис типа tunnelbroker. По моему опыту самая годная связка. Ибо если делать в облаке, то либо ценник конский, либо ограничений куча. А так и ssh и SFTP и что-то спецом для бекапов поднять можно и owncloud для фоток с телефона.
Где вы храните бэкапы
- Автор темы suphler
- Дата начала
Вопрос был про бэкапы в целом, но у меня это еще зависит от сохраняемого контента. Например, если есть веб-сайт с подгружаемыми изображениями, возможно - изменяемыми страницами, и базой данных, то я автоматически сохраняю все это в git. Ежесуточно делается дамп базы в SQL + какие-то картинки добавились, что-то поменялось. Все это коммитится в гит репо, который потом дублируется на удаленный сервер (push/pull - как кому удобнее). Достоинства - сохраняются только дельты, что привычно. Но для базы данных выигрыш куда интереснее - дельты, как правило, гораздо компактнее всей базы. И при этом при достаточного размера базе и умеренном количестве добавлений в сутки репозиторий базы за год может быть размера пары дампов (гит сжимает контент) - но при этом можно достать базу по состоянию на любые сутки за всю ее историю. Иногда очень выручает. А компактность такого представления и то, что репозитории git легко клонируются, снимает вопрос о месте хранения - можно хранить где угодно - на своем же сервере git, например, на коммерческим git провайдере. На удаленном диске (обновление - git pull - и новая копия у нас в кармане).
bolivarnsk
Создатель
- Регистрация
- 1 Авг 2009
- Сообщения
- 20
- Реакции
- 20
у git отталкивающий интерфейс командной строки, вы как опытный пользователь этой системы думаю не испытываете сложности с обращением с ней, но не для всех однозначно
Могу согласиться, что git надо понимать для полноценной работы с ним. Но в данном случае речь идет о разовой настройке. После чего по крону просто вызываются
pushd "$site"
git add -A
git commit -m "$timestamp auto backup"
git push origin master
popd
И все.
pushd "$site"
git add -A
git commit -m "$timestamp auto backup"
git push origin master
popd
И все.
Все таки гит это не инструмент бекапа. Никто не запрещает держать систему контроля версий для исполняемых (например .php) файлов, но для бекапа он громоздкий и медленный. Старый добрый rsync (с небольшой обвязкой-скриптовкой) практически покрывает основные потребности файлового бекапа для среднего проекта. Базы сложнее, иногда приходится что-то костылить ради легкого бекапа.
Еще с интересом наблюдаю за развитием rclone, нравится в работе, хоть и со своими тараканами.
Еще с интересом наблюдаю за развитием rclone, нравится в работе, хоть и со своими тараканами.
Можно посмотреть чуть иначе: git - это эффективный механизм для инкрементального копирования данных, в частности, хорошо сжимаемых, со сквозным контролем контрольных сумм, со 100% сохранением предыдущих версий (бесконечное количество прошлых копий) и с простым механизмом дублирования полного бэкапа (git clone).
Я не случайно писал выше, что все зависит от задачи. Использовать гит для резервирования файлопомойки я бы точно не стал. Но если данные имеют определенные свойства, то этот механизм весьма эффективен. rsync хорош, но он не обеспечивает инкрементальности сам по себе, то есть, копии всегда будут занимать пространство, а при хранении в N поколений - большое пространство.
Я не случайно писал выше, что все зависит от задачи. Использовать гит для резервирования файлопомойки я бы точно не стал. Но если данные имеют определенные свойства, то этот механизм весьма эффективен. rsync хорош, но он не обеспечивает инкрементальности сам по себе, то есть, копии всегда будут занимать пространство, а при хранении в N поколений - большое пространство.
Можно посмотреть иначе: rsync - это эффективный механизм для инкрементального копирования данных (он изначально копирует только дельту), хорошо сжимаемых, с надежным контролем целостности данных, построенным на контрольных суммах. Он написан в лучших традициях unix-way, имеет низкий порог вхождения, поддерживается туевой хучей дистрибутивов и сервисов, великолепно ложится в любую скриптовую обвязку, не ресурсоемок. Это позволяет быстро развернуться и заниматься другими задачами.
Гит же, да можно. Но микроскопом тоже никто не запрещает гвозди забивать.
Не холивара ради, но сколько сервисов для резервных копий поддерживают гит? )
Гит же, да можно. Но микроскопом тоже никто не запрещает гвозди забивать.
Не холивара ради, но сколько сервисов для резервных копий поддерживают гит? )
rsync дельту копирует - но не хранит. Сервис для хранения резервной копии гита - это любой сервер поддержки git (GitHub, GitLab, собственный gitolite, и так далее). Спорить не вижу смысла - каждый инструмент хорош для своей задачи. Просто приведу на примере небольшой базы данных конкретные цифры:
MySQL дамп базы имеет текущий размер 28MB (*.sql).
Git repo того же дампа занимает 35MB.
В этом репозитории хранятся 2023 ежесуточных версии дампа всей базы - с 2013 года по текущий момент (база на тот момент не была пустой, просто с того момента я начал ее бэкапить в гит). И любую из версий можно поднять в том виде, как она была по состоянию на тот день.
Небольшой веб-сайт, на котором ежедневно менялись несколько мелких файлов и подгружались изображения товаров.
Размер сайта с картинками - 440MB
Размер репозитория - 418MB (php хорошо сжимаемый)
Количество сохраненных ежесуточных копий - 1178.
Мне просто показалось, что в теме не ставилось ограничений в виде "бэкап-решения для чайников" с низким порогом вхождения.
MySQL дамп базы имеет текущий размер 28MB (*.sql).
Git repo того же дампа занимает 35MB.
В этом репозитории хранятся 2023 ежесуточных версии дампа всей базы - с 2013 года по текущий момент (база на тот момент не была пустой, просто с того момента я начал ее бэкапить в гит). И любую из версий можно поднять в том виде, как она была по состоянию на тот день.
Небольшой веб-сайт, на котором ежедневно менялись несколько мелких файлов и подгружались изображения товаров.
Размер сайта с картинками - 440MB
Размер репозитория - 418MB (php хорошо сжимаемый)
Количество сохраненных ежесуточных копий - 1178.
Мне просто показалось, что в теме не ставилось ограничений в виде "бэкап-решения для чайников" с низким порогом вхождения.