Где вы храните бэкапы

Тема в разделе "Администрирование серверов", создана пользователем suphler, 27 мар 2016.

?

Где вы храните бэкапы

  1. Вообще не делаю бэкапов

    5 голосов
    3,4%
  2. Периодически вручную сохраняю важную информацию на флешки, диски,...

    9 голосов
    6,2%
  3. В отдельной папке того-же компьютера (автоматически)

    9 голосов
    6,2%
  4. На внешннем диске

    14 голосов
    9,6%
  5. На другом своем сервере

    55 голосов
    37,7%
  6. В облаках

    54 голосов
    37,0%
Модераторы: mefish
  1. daex

    daex Создатель

    Регистр.:
    17 июл 2007
    Сообщения:
    22
    Симпатии:
    13
    Нормальный nas с дисками стоит баксов 200-300 + доступ в инет + статический ip. Либо если статик ip не дают, можно сделать через ipv6 и через сервис типа tunnelbroker. По моему опыту самая годная связка. Ибо если делать в облаке, то либо ценник конский, либо ограничений куча. А так и ssh и SFTP и что-то спецом для бекапов поднять можно и owncloud для фоток с телефона.
     
  2. koticik

    koticik Создатель

    Регистр.:
    6 июл 2018
    Сообщения:
    16
    Симпатии:
    0
    Убунти (меньше вероятность подхватить что то типа пети) с дешевым рейд контроллером, абы увеличить количество сата дырок.
    Бекапы за разные дни расползаются на разные винты.
     
  3. osnwt

    osnwt Писатель

    Регистр.:
    8 авг 2018
    Сообщения:
    9
    Симпатии:
    0
    Вопрос был про бэкапы в целом, но у меня это еще зависит от сохраняемого контента. Например, если есть веб-сайт с подгружаемыми изображениями, возможно - изменяемыми страницами, и базой данных, то я автоматически сохраняю все это в git. Ежесуточно делается дамп базы в SQL + какие-то картинки добавились, что-то поменялось. Все это коммитится в гит репо, который потом дублируется на удаленный сервер (push/pull - как кому удобнее). Достоинства - сохраняются только дельты, что привычно. Но для базы данных выигрыш куда интереснее - дельты, как правило, гораздо компактнее всей базы. И при этом при достаточного размера базе и умеренном количестве добавлений в сутки репозиторий базы за год может быть размера пары дампов (гит сжимает контент) - но при этом можно достать базу по состоянию на любые сутки за всю ее историю. Иногда очень выручает. А компактность такого представления и то, что репозитории git легко клонируются, снимает вопрос о месте хранения - можно хранить где угодно - на своем же сервере git, например, на коммерческим git провайдере. На удаленном диске (обновление - git pull - и новая копия у нас в кармане).
     
  4. bolivarnsk

    bolivarnsk Создатель

    Регистр.:
    1 авг 2009
    Сообщения:
    15
    Симпатии:
    6
    у git отталкивающий интерфейс командной строки, вы как опытный пользователь этой системы думаю не испытываете сложности с обращением с ней, но не для всех однозначно
     
  5. osnwt

    osnwt Писатель

    Регистр.:
    8 авг 2018
    Сообщения:
    9
    Симпатии:
    0
    Могу согласиться, что git надо понимать для полноценной работы с ним. Но в данном случае речь идет о разовой настройке. После чего по крону просто вызываются

    pushd "$site"
    git add -A
    git commit -m "$timestamp auto backup"
    git push origin master
    popd

    И все.
     
  6. Stesh

    Stesh

    Регистр.:
    3 фев 2009
    Сообщения:
    252
    Симпатии:
    99
    Все таки гит это не инструмент бекапа. Никто не запрещает держать систему контроля версий для исполняемых (например .php) файлов, но для бекапа он громоздкий и медленный. Старый добрый rsync (с небольшой обвязкой-скриптовкой) практически покрывает основные потребности файлового бекапа для среднего проекта. Базы сложнее, иногда приходится что-то костылить ради легкого бекапа.
    Еще с интересом наблюдаю за развитием rclone, нравится в работе, хоть и со своими тараканами.
     
  7. osnwt

    osnwt Писатель

    Регистр.:
    8 авг 2018
    Сообщения:
    9
    Симпатии:
    0
    Можно посмотреть чуть иначе: git - это эффективный механизм для инкрементального копирования данных, в частности, хорошо сжимаемых, со сквозным контролем контрольных сумм, со 100% сохранением предыдущих версий (бесконечное количество прошлых копий) и с простым механизмом дублирования полного бэкапа (git clone).

    Я не случайно писал выше, что все зависит от задачи. Использовать гит для резервирования файлопомойки я бы точно не стал. Но если данные имеют определенные свойства, то этот механизм весьма эффективен. rsync хорош, но он не обеспечивает инкрементальности сам по себе, то есть, копии всегда будут занимать пространство, а при хранении в N поколений - большое пространство.
     
  8. Stesh

    Stesh

    Регистр.:
    3 фев 2009
    Сообщения:
    252
    Симпатии:
    99
    Можно посмотреть иначе: rsync - это эффективный механизм для инкрементального копирования данных (он изначально копирует только дельту), хорошо сжимаемых, с надежным контролем целостности данных, построенным на контрольных суммах. Он написан в лучших традициях unix-way, имеет низкий порог вхождения, поддерживается туевой хучей дистрибутивов и сервисов, великолепно ложится в любую скриптовую обвязку, не ресурсоемок. Это позволяет быстро развернуться и заниматься другими задачами.

    Гит же, да можно. Но микроскопом тоже никто не запрещает гвозди забивать.

    Не холивара ради, но сколько сервисов для резервных копий поддерживают гит? )
     
  9. osnwt

    osnwt Писатель

    Регистр.:
    8 авг 2018
    Сообщения:
    9
    Симпатии:
    0
    rsync дельту копирует - но не хранит. Сервис для хранения резервной копии гита - это любой сервер поддержки git (GitHub, GitLab, собственный gitolite, и так далее). Спорить не вижу смысла - каждый инструмент хорош для своей задачи. Просто приведу на примере небольшой базы данных конкретные цифры:

    MySQL дамп базы имеет текущий размер 28MB (*.sql).
    Git repo того же дампа занимает 35MB.
    В этом репозитории хранятся 2023 ежесуточных версии дампа всей базы - с 2013 года по текущий момент (база на тот момент не была пустой, просто с того момента я начал ее бэкапить в гит). И любую из версий можно поднять в том виде, как она была по состоянию на тот день.

    Небольшой веб-сайт, на котором ежедневно менялись несколько мелких файлов и подгружались изображения товаров.
    Размер сайта с картинками - 440MB
    Размер репозитория - 418MB (php хорошо сжимаемый)
    Количество сохраненных ежесуточных копий - 1178.

    Мне просто показалось, что в теме не ставилось ограничений в виде "бэкап-решения для чайников" с низким порогом вхождения.
     
  10. osnwt

    osnwt Писатель

    Регистр.:
    8 авг 2018
    Сообщения:
    9
    Симпатии:
    0
    Уточнение: по сайту там не ежесуточные копии, а копии, когда хоть что-то в нем изменялось. Если изменений нет, то дельта нулевая, и копия просто не делалась, оставляя предыдущую версию репозитория.