Изменить место хранения backup

[kreator]

По-умолчанию, все архивы пользователей хранятся в папке /home/backup
В целях экономии места на сервере хочу подключить webdav-диск от Яндекса (точнее уже подключил)
Он получается тут: /home/disc

Как изменить, чтобы все архивы сохранялись и восстанавливались оттуда?

Как это сделать и какие подводные камни меня могут ждать?

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

[skurudo]

Сделать можно просто - использовать davfs2, смонтировать каталог в /home/backup и собственно все. НО! Идея из разряда не плохих, а очень плохих. Дело в том, что годится она, когда у вас файликов не много (меньше пары тыщ) и стабильный канал до яндекса. К примеру из Европы-Сша фокус с монтированием оборачивается трагедией с полем из граблей. Бывает, что davfs2 повисает и рестартить его не сильно удобно (убивать процесс и монтировать заново). К тому же не стоит забывать, что кэш при архивировании все равно занимает место на диске в темпах и в случае неудачи осядет и забьет диск.

[skurudo]

http://habrahabr.ru/post/142067/
Вот статья на тему, можете попробовать.

[skurudo]

Если немного изменить ТЗ, то я бы рекомендовал использовать REST API. Получается гораздо стабильнее. К тому же есть достаточно интересная и стабильная примочка для этого - https://github.com/abbat/ydcmd

Схема правда слегка меняется при этом. Вы держите 1 бэкап на диске, остальное закачиваете в облаков в нужном количестве. Скрипты сравнительно короткие при этом. Минус в том, что при восстановлении более старых бэкапов, их нужно будет сначала скачать и потом восстановить.

[kreator]

Сделать можно просто - использовать davfs2, смонтировать каталог в /home/backup и собственно все. НО! Идея из разряда не плохих, а очень плохих. Дело в том, что годится она, когда у вас файликов не много (меньше пары тыщ) и стабильный канал до яндекса. К примеру из Европы-Сша фокус с монтированием оборачивается трагедией с полем из граблей. Бывает, что davfs2 повисает и рестартить его не сильно удобно (убивать процесс и монтировать заново). К тому же не стоит забывать, что кэш при архивировании все равно занимает место на диске в темпах и в случае неудачи осядет и забьет диск.

в моем случае, я сейчас использую vesta на довольно небольшом по размеру диска сервере (5гб) с парой десятков небольших сайтов. А яндекс диск ~250ГБ+ пустует без дела) Вот и подумал над этим.
С временными много-много-файликами в папке backup - тут согласен, поэтому от монтирования прямо в backup сразу отказался, а вот после того как файлы обработаются и заархивируются они перемещаются из temp в саму backup. Вот тут я и хотел сменить место их дислокации.

[kreator]

в rc.local также создал команду для автоматического монтирования диска при запуске сервера

На счет зависания davfs как то не подумал. Немного погоняю - пригляжусь.

[skurudo]

С временными много-много-файликами в папке backup - тут согласен, поэтому от монтирования прямо в backup сразу отказался, а вот после того как файлы обработаются и заархивируются они перемещаются из temp в саму backup. Вот тут я и хотел сменить место их дислокации.

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

[skurudo]

На счет зависания davfs как то не подумал. Немного погоняю - пригляжусь.

Пробовал на 30-70к файлах на один сайт - архивы 4-8гб... и таких несколько десятков. С такими условиями выходит треш и угар. Потестируйте, если у вас объемы поменьше, то решение вполне годное.

[moderatorh]

Действительно, нынешняя система бекапа в весте (впрочем как и в большинстве других панелей), оставляет желать лучшего.

1. В хомяках действительно не стоит хранить кучу бекапов.
2. Насчет webdev выше написаны "страшилки". Даже если у Вас у каждого пользователя по 10к файлов, то все это прекрасно работает и никаких проблем обычно не возникает, т.к. в начале все архивируется, а уже потом файл из тмп сгружается по webdev в примонтированный Вами каталог.
3. Другое дело, что хранить подобные бэкапы, это само по себе не правильно. Бекап должен быть инкрементным, а часть сэкономленного на инкриментах места следует отдать на организацию второго хранилища (то есть два хранилища в параллели в разных ДЦ). В качестве средства инкрементного бекапа можете воспользоваться например duplicity. Хорошая утилитка, умеет юзать десяток протоколов, в том числе ssh, дропбокс... и конечно же webdev из коробки. В этом случае вся головная боль по восстановлению соединения и его контролю ложиться не на дев2фс, а непосредственно на дуплисити и она с этой задачей отменно справляется. Использую уже много лет в продакшене.

Просто суете в крон баш файлик со следующим содержимым и радуетесь жизни:

Code: Select all

#!/bin/sh
export PASSPHRASE='ПАРОЛЬ'
duplicity --full-if-older-than 1M --exclude=/home/backup /home file:///mnt/backup/s1/home/
duplicity remove-older-than 1M --force file:///mnt/backup/s1/home/
unset PASSPHRASE

Обычно хватает раз в сутки бекапить, но на оживленных сайтах можно хоть каждые десять минут.
Средняя экономия места в месяц, минимум двадцать пять раз.

[skurudo]

Действительно, нынешняя система бекапа в весте (впрочем как и в большинстве других панелей), оставляет желать лучшего.

...
Другое дело, что хранить подобные бэкапы, это само по себе не правильно. Бекап должен быть инкрементным, [/quote]

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

2. Насчет webdev выше написаны "страшилки". Даже если у Вас у каждого пользователя по 10к файлов, то все это прекрасно работает и никаких проблем обычно не возникает, т.к. в начале все архивируется, а уже потом файл из тмп сгружается по webdev в примонтированный Вами каталог.

Собственно, ТС спросил про подводные камни, я рассказал о тех, которые поймал. Страшилки или не страшилки, а грабли реальны. Если у вас такое прокатывает с меньшим объемом, то это же прекрасно!