mysql, static files, repos на отдельных разделах для Redmine

2013-08-08 Thread Владимир Скубриев

mysql, static files, repos на отдельных разделах для Redmine.

Корень уже на отдельном разделе.

Возник у меня спор с начальством по поводу Redmine.

Я за то, чтобы mysql (50Мб), static files(1Гб), repos(5Гб) были на 
отдельных разделах для Redmine. ФС на отдельных ЛВМ разделах - в любой 
момент могу увеличить.


Начальство уверяет что это излишне. Мол кончиться место может - пока 
выясним что и как времени много пройдет. Да и вообще зачем все разделять 
- спрашивают.


Я хочу отделить все чтобы можно было по отдельности делать снапшоты и 
сохранять. Хотя мне ни чего не мешает сделать один снапшот всех данных и 
потом по отдельности все сохранить.


Так даже как то лучше будет - все данные в один определенный момент 
времени сохраняться. Чем если бы я по отдельности делал снапшоты для 
базы, реп, и статик файлов.


Кто что скажет на этот счет ?


Спасибо.

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru



Re: mysql, static files, repos на отдельных разделах для Redmine

2013-08-08 Thread Stanislav Vlasov
9 августа 2013 г., 12:07 пользователь Владимир Скубриев <
vladi...@skubriev.ru> написал:

> Я за то, чтобы mysql (50Мб), static files(1Гб), repos(5Гб) были на
> отдельных разделах для Redmine. ФС на отдельных ЛВМ разделах - в любой
> момент могу увеличить.
>
> Начальство уверяет что это излишне. Мол кончиться место может - пока
> выясним что и как времени много пройдет. Да и вообще зачем все разделять -
> спрашивают.
>
> Я хочу отделить все чтобы можно было по отдельности делать снапшоты и
> сохранять. Хотя мне ни чего не мешает сделать один снапшот всех данных и
> потом по отдельности все сохранить.
>
> Так даже как то лучше будет - все данные в один определенный момент
> времени сохраняться. Чем если бы я по отдельности делал снапшоты для базы,
> реп, и статик файлов.
>
> Кто что скажет на этот счет ?
>

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

А в остальном - без разницы, пока места достаточно.

-- 
Stanislav


Re: mysql, static files, repos на отдельных разделах для Redmine

2013-08-09 Thread Mikhail A Antonov
09.08.2013 10:07, Владимир Скубриев пишет:
> Я за то, чтобы mysql (50Мб), static files(1Гб), repos(5Гб) были на
> отдельных разделах для Redmine. ФС на отдельных ЛВМ разделах - в любой
> момент могу увеличить.
А что делать, если "любой момент" настал во время твоего отпуска или ты
просто недоступен?

> Начальство уверяет что это излишне. Мол кончиться место может - пока
> выясним что и как времени много пройдет. Да и вообще зачем все
> разделять - спрашивают.
Я вот тоже спрашиваю. Расскажи аргументы "за" для разделения.
ИМХО, разносить в разные тома удобно если они на разных физических
дисках или используются разные ФС\опции ФС.
Например btrfs умеет опцию compress. Хранить кино на таком разделе -
нафиг не надо, а вот txt-документы или логи - вполне можно сэкономить места.
Ну или файлопомойку ограничить томом, чтоб не сожрала всё что можно.
В ситуации с редмайном - имхо, это лишнее, но если у тебя есть весомые
аргументы - хочу послушать.
Весомые это не вида "мне кажется" или "я где-то слышал" или "ну я
недавно познал крутость lvm и теперь хочу всё что можно разделить и
вообще максимально засунуть lvm везде где можно".

> Я хочу отделить все чтобы можно было по отдельности делать снапшоты и
> сохранять. Хотя мне ни чего не мешает сделать один снапшот всех данных
> и потом по отдельности все сохранить.
Как правильно заметил Станислав, при разном времени создания снапшота
файлов и базы - возможны расхождения между данными и базой.
А ещё базу не стоит сохранять файлами. Её-то как раз лучше сохранять
средствами БД (mysqldump например).


-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature