Главное меню
Мы солидарны с Украиной. Узнайте здесь, как можно поддержать Украину.

Почините форум…

Автор Wolliger Mensch, апреля 5, 2018, 22:36

0 Пользователи и 1 гость просматривают эту тему.

Red Khan

Цитата: RawonaM от января 23, 2019, 11:11
Каждые три дня это редко. Сколько таких бекапов хранится?
Один. Но это бесплатно, нам хватает. Но можно настроить хоть каждые 6 часов и вплоть до десяти копий, но это уже за дополнительные деньги.

Цитата: RawonaM от января 23, 2019, 11:11
Ну да, можно настроить incremental backups, это как раз то, что я называю морока.
Банальные rsync? Если уже совсем заморачиваться - какую-нибудь систему типа Bacula. Мы как-то пытались её внедрить, но отказались за сложностью и излишности. Для одной папки это тем более будет излишне.

mnashe

Incremetal backups для аттачментов — колоссальная экономика места и трафика.
Может быть, проще даже не incremetal backups, а тупо фильтры по дате. Забэкапить все файлы со вчерашней датой, например.
А для домашнего компьютера 4 ГБ и даже 40 ГБ — пустяк.
Можно скопировать все нынешние аттачменты на домашний компьютер, и затем бэкапить на бекап-сервер файлы по дате.
Через полгода повторить процедуру: скопировать всё, что есть, домой и стереть бекапы аттачментов на бекап-сервере.
Кажется, вполне приемлемое решение для бэкапов. Если, конечно, такой скрипт (бекап только файлов с определённой датой) несложно написать. Я не знаю линукса, поэтому и этого не знаю, просто предполагаю, что это должно быть просто.
Тем более если мы в дальнейшем запретим заливать фотографии и bmp в аттачменты.
Вот с местом на основном сервере проблема остаётся... :???
Адепт единственного числа и безродового склонения
שָׁלוֹם עֲלֵיכֶם!

Red Khan

Цитата: mnashe от января 23, 2019, 11:32
Если, конечно, такой скрипт (бекап только файлов с определённой датой) несложно написать.
Несложно. Но легче rsync в cron запихать.
Или даже накидать скрипт, который всё это архивирует tar'ом. Для картинок разницы не будет, но другие файлы сожмёт.

Цитата: mnashe от января 23, 2019, 11:32
Тем более если мы в дальнейшем запретим заливать фотографии и bmp в аттачменты.
Прикрутить что-то типа MIME. У меня на одной системе, используемой на работе (GLPI) такое есть.

RawonaM

Цитата: wandrien от января 23, 2019, 11:22
4Гб это не много.
Ну кому как, это все где-то надо хранить и заниматься этим, ради чего? Что бы картинки котиков смотреть через 10 лет? На многих форумах аттачменты удаляются через какое-то время, я же предпочитаю их хранить навсегда, т.к. там может быть что-то необходимое.
Если это сейчас немного, то это только потому, что мы их стали очень сильно ограничивать. Ввелось ограничение на размер файла, тогда уже и нужные аттачменты не получалось загрузить.
Правильное решение было постфактум запретить загрузку картинок еще лет 8 назад - если что-то необходимое приаттачивать в архиве.

RawonaM

Вот наверное и решение - картинки запретить, а остальное rsync-ом бэкапить будет как раз хорошо.

wandrien

Цитата: RawonaM от января 23, 2019, 11:54
Ну кому как, это все где-то надо хранить и заниматься этим, ради чего? Что бы картинки котиков смотреть через 10 лет? На многих форумах аттачменты удаляются через какое-то время, я же предпочитаю их хранить навсегда, т.к. там может быть что-то необходимое.
Интересно было бы взглянуть на статистику:
картинки: столько-то файлов, занимающие столько-то МБ
не картинки: столько-то файлов, занимающие столько-то МБ

Если картинок разумное количество, при этом занимающее неразумно много места, можно их просмотреть и поудалять вручную. Условных котиков.

А остальное — как раз:
Цитата: RawonaM от января 23, 2019, 11:54
Вот наверное и решение - картинки запретить, а остальное rsync-ом бэкапить будет как раз хорошо.

wandrien

Еще проблема в том, что не все аттачи публичны, насколько я понимаю. Часть находится в разделах с ограниченным доступом.
Если бы аттачи были публичны, то их бэкапы можно было бы хранить... да хоть средствами ZeroNet, например.

TestamentumTartarum

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

P.S. Мнение опубликовано. ГКК.
P.P.S. Осторожно, ругаюсь бронетанками!

Bhudh

У меня в аттачах в основном скриншоты, емнип.
Можно поставить разные ограничения на разные MIME.
Пиши, что думаешь, но думай, что пишешь.
MONEŌ ERGŌ MANEŌ.
Waheeba dokin ʔebi naha.
«каждый пост в интернете имеет коэффициент бреда» © Невский чукчо

RawonaM

Цитата: wandrien от января 23, 2019, 12:04
Интересно было бы взглянуть на статистику:
картинки: столько-то файлов, занимающие столько-то МБ
не картинки: столько-то файлов, занимающие столько-то МБ
Сам заинтересовался, покрутил парочку запросов в MySql.

SELECT COUNT(*), ROUND(SUM(size)/1024/1024,1) FROM `lf_smf_attachments` WHERE attachment_type=0

26971 3186.0 Mb

SELECT COUNT(*), ROUND(SUM(size)/1024/1024,1) FROM `lf_smf_attachments` WHERE attachment_type=0 AND mime_type LIKE 'image%'

23114 2393.2 Mb

SELECT COUNT(*), ROUND(SUM(size)/1024/1024,1) FROM `lf_smf_attachments` WHERE attachment_type=0 AND mime_type NOT LIKE 'image%'

3857 792.9 Mb

SELECT COUNT(*), ROUND(SUM(size)/1024/1024,1) as size, Mem.member_name FROM `lf_smf_attachments` as A JOIN lf_smf_messages as M ON A.id_msg=M.id_msg JOIN lf_smf_members as Mem ON M.id_member=Mem.id_member WHERE attachment_type=0 GROUP BY M.id_member ORDER BY size DESC

countsizemember_name
1469168.3mnashe
1578126.9SIVERION
1121101.6Bhudh
122692.0RawonaM
32181.9Драгана
72278.7Neeraj
72267.6Сергий
31365.2Iyeska
74261.5Ion Bors
33657.9Leo
38856.7Türk
36143.3Tibaren
36243.2Pinia
39342.8Joris
31141.4_Swetlana
43240.5Валентин Н
17638.3Easyskanker
31137.6Red Khan
31836.3Tys Poc
24933.3Iskandar
38432.5langust
21831.9Oleg Grom
36230.5Тайльнемер
25528.8Alexandra A
12927.5I. G.
Простите таблицу лень оформлять :)

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

Bhudh

Пиши, что думаешь, но думай, что пишешь.
MONEŌ ERGŌ MANEŌ.
Waheeba dokin ʔebi naha.
«каждый пост в интернете имеет коэффициент бреда» © Невский чукчо

RawonaM

Чтоб я не копался в документации, может у кого-то есть готовый ответ, как rsync-ом получить инкрементальную часть? По сути добавления и изменения понятны, можно список составить, а вот как он поступает с удаленными файлами?

RawonaM

Цитата: RawonaM от января 23, 2019, 12:13
SELECT COUNT(*), ROUND(SUM(size)/1024/1024,1) FROM `lf_smf_attachments` WHERE attachment_type=0 AND mime_type NOT LIKE 'image%'
Касательно этого я сейчас вспомнил, что mime добавились где-то потом, от первых аттачментов нет мимов, поэтому картинок больше, чем тут показывает. Впрочем, картинок с тех времен не много, тогда в РФ через модем ходили в инет.

RawonaM

Цитата: RawonaM от января 23, 2019, 12:13
У меня ощущение, что файлов больше, чем записано в БД, хотя я удалял уже непринадлежащие никому аттачменты, надо еще проверчить точнее.
find . -type f | wc -l
50002

Файлов в два раза больше, чем в БД...  :???

du -h .
12K ./attachments3.5
467M ./attachments
448M ./attachments4
1,2G ./attachments2
1,4G ./attachments3
503M ./attachments5
4,0G .

Где-то там 800 МБ оверхеда получается.

wandrien

Цитата: RawonaM от января 23, 2019, 12:18
Чтоб я не копался в документации, может у кого-то есть готовый ответ, как rsync-ом получить инкрементальную часть? По сути добавления и изменения понятны, можно список составить, а вот как он поступает с удаленными файлами?
Инкрементальность rsync основана на опции --link-dest.
На ФС с хардлинками он физически линкует имена в новом бэкапе к неизменившимся файлам в старом бэкапе. Удаленные файлы он просто не линкует.

wandrien

Цитата: wandrien от января 23, 2019, 12:28
На ФС с хардлинками он физически линкует имена в новом бэкапе к неизменившимся файлам в старом бэкапе. Удаленные файлы он просто не линкует.
Т.е. если каждый следующий бэкап делать в новый каталог, и в --link-dest указывать предыдущий каталог, то получится "git для бедных" средствами ФС. Каждый бэкап выглядит как полный, а все в совокупности - дедуплицированы.

RawonaM

Цитата: wandrien от января 23, 2019, 12:28
Инкрементальность rsync основана на опции --link-dest.
Понял, так у меня и было, но если надо на другой бэкап сервер загрузить, что делать? С rsync можно список сделать, но вот парсить его вручную надо будет.

wandrien

Цитата: RawonaM от января 23, 2019, 13:02
Цитата: wandrien от января 23, 2019, 12:28
Инкрементальность rsync основана на опции --link-dest.
Понял, так у меня и было, но если надо на другой бэкап сервер загрузить, что делать? С rsync можно список сделать, но вот парсить его вручную надо будет.
???

Так рсинком и того, разницы нет. При выполнении rsync с удаленного адреса, он будет оттуда получать списки файлов, сравнивать дату и размер с локальными, и если различаются, запрашивать пересылку содержимого.

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

wandrien

да, вот как он работает, когда запуск команды выполняется той стороной, откуда бэкап, я не знаю. --link-dest может на удаленный адрес указывать или нет?...

Просто не использовал такой кейс ни разу.

Red Khan

Я что-то не пойму, разве rsync по умолчанию уже не копирует только изменённые файлы?

RawonaM

Цитата: wandrien от января 23, 2019, 13:08
Так рсинком и того, разницы нет. При выполнении rsync с удаленного адреса, он будет оттуда получать списки файлов, сравнивать дату и время с локальными, и если различаются, запрашивать пересылку содержимого.

Он by design клиент-серверный. Даже при копировании в пределах локалхоста запускается два процесса, просто клиент-серверность  скрыта от пользователя в этом случае.
Немножко потерялся. Бэкап доступен только по фтп, там нет rsync.

Что я бы хотел это вот:
inc_back attachs --since 24h > //attachs-fri.zip
send-by-ftp //backup.server.com //attachs-fri.zip

В зипе будут изменения только за последние 24 часа. Ну и как-то нужно еще учитывать, что удалилось.

Задача конечно решаемая просто find-ом, но так руки и не доходили. Как-то потом это еще все это нужно реализовать и уметь из этой всей каши восстановить состояние на определенный момент.

wandrien

Цитата: Red Khan от января 23, 2019, 13:17
Я что-то не пойму, разве rsync по умолчанию уже не копирует только изменённые файлы?
Да.

Я насчёт --link-dest сомневался.

Погуглил, и пишут, что если указать там относительный путь (относительно целевого каталога на удаленной машине), rsync понимает, что от него хотят.

wandrien

Цитата: RawonaM от января 23, 2019, 13:22
Бэкап доступен только по фтп, там нет rsync.
:what:
Тогда лучше поискать готовые решения именно для ftp.
Я-то исходил из того, что на всех машинах есть возможность поднять нужные службы...

mnashe

Цитата: RawonaM от января 23, 2019, 13:22
В зипе будут изменения только за последние 24 часа.
Это, наверно, не очень надёжно. На стыках будут пересечения или пропуски.
Я предлагал чуть иначе: допустим, в 5 утра 24/01/19 запускаем бэкап. В него включаем все аттачменты с датой 23/01/19, независимо от времени.
Тогда никаких проколов не должно быть.
Адепт единственного числа и безродового склонения
שָׁלוֹם עֲלֵיכֶם!

RawonaM

Цитата: mnashe от января 23, 2019, 13:34
Цитата: RawonaM от В зипе будут изменения только за последние 24 часа.
Это, наверно, не очень надёжно. На стыках будут пересечения или пропуски.
Ну это примерно, можно точное время последнего бекапа указывать, не в этом суть.

Быстрый ответ

Обратите внимание: данное сообщение не будет отображаться, пока модератор не одобрит его.

Имя:
Имейл:
Проверка:
Оставьте это поле пустым:
Наберите символы, которые изображены на картинке
Прослушать / Запросить другое изображение

Наберите символы, которые изображены на картинке:

√36:
ALT+S — отправить
ALT+P — предварительный просмотр