Система резервного копирования UrBackup ( http://www.urbackup.org/ )

Bacula или Bareos UrBackup

Отправить по электронной почтеНаписать об этом в блогеОпубликовать в TwitterОпубликовать в FacebookПоделиться в Pinterest
UrBackup - это эффективная клиент/серверная система резервного копирования для Linux и Windows. Клиент для Windows позволяет выполнять резервное копирование как выбранных файлов, так и разделов в целом. Инкрементные и полные резервные копии хранятся на серверах под управлением Windows или Linux. Простой в использовании веб-интерфейс позволяет оценивать место, занимаемое резервными копиями на диске, просматривать логи, настраивать программу и просматривать резервные копии. Восстановление из образов дисков может выполняться с использованием специального Linux CD на базе KNOPPIX. Подробности на сайте программы.

Возьмите старенькую машинку, гигабитную сетевую, два или более винтов. Воспользуйтесь той же ubuntu 14.04 LTS, cобрав при установке softraid уровня 1 , 5, 6, 10 (в зависимости от ваших требований). После этого разверните на ней ту же BareOS, Urbackup.

Старенькая машинка  флешка + FreeNAS + urbackup (в виде jail-контейнера).  ТЫЦ на доку.

Bacula или Bareos (http://www.bareos.com/en/)

Оброз по резервному копировани шаровых програмных продуктов ТУТ.

{jcomments on}

Почему OpenVPN тормозит?

Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием OpenVPN и получают низкую скорость, сильно ниже скорости канала. У кого-то это может быть 20 Мбит/с при канале в 100 Мбит/с с обеих сторон, а кто-то еле получает и 400 Кбит/с на 2 Мбит/с ADSL/3G и высоким пингом. Зачастую, таким людям советуют увеличить MTU на VPN-интерфейсе до чрезвычайно больших значений, вроде 48000, или же поиграться с параметром mssfix. Частично это помогает, но скорость внутри VPN все еще очень далека от канальной. Иногда все сваливают на то, что OpenVPN — userspace-решение, и это его нормальная скорость, учитывая всякие шифрования и HMAC'и. Абсурд!

Немного истории

На дворе июль 2004 года. Типичная скорость домашнего интернета в развитых странах составляет 256 Кбит/с-1 Мбит/с, в менее развитых — 56 Кбит/с. Ядро Linux 2.6.7 вышло не так давно, а 2.6.8, в котором TCP Window Scale включен по умолчанию, выйдет только через месяц. Проект OpenVPN развивается уже 3 года как, к релизу готовится версия 2.0.
Один из разработчиков добавляет код, который устанавливает буфер приема и отправки сокета по умолчанию в 64 КБ, вероятно, чтобы хоть как-то унифицировать размер буфера между платформами и не зависеть от системных настроек. Однако в Windows что-то поломали, и указание размера буферов у сокета приводит к странным проблемам с MTU на всех адаптерах в системе. В конечном итоге, в релиз OpenVPN 2.0-beta8 попадает следующий код:

#ifndef WIN32
    o->rcvbuf = 65536;
    o->sndbuf = 65536;
#endif

Немного технической информации

Если вы пользовались OpenVPN, вы знаете, что он может работать как через UDP, так и через TCP. Если на TCP-сокете установить какое-то маленькое значение буфера, в нашем случае 64 КБ, то алгоритм подстройки TCP-окна просто не сможет выйти за это значение.
Что же это значит? Предположим, вы подключаетесь к серверу в США из России через OpenVPN со стандартными значениями буферов сокета. У вас широкий канал, скажем, 50 МБит/с, но в силу расстояния, пинг составляет 100 мс. Как вы думаете, какой максимальной скорости вы сможете добиться? 5.12 Мбит/с. Вам необходим буфер размером как минимум 640 КБ, чтобы загрузить ваш 50 Мбитный канал.
OpenVPN через UDP будет работать несколько быстрее из-за собственной реализации пересылки пакетов, но тоже далеко не идеально.

Что делать?

Как вы могли уже догадаться, данный размер буфера все еще применяется в самом последнем релизе OpenVPN. Как же нам исправить ситуацию? Самый корректный вариант — запретить OpenVPN менять размер буферов у сокета.
Нужно добавить следующие строки как в серверный, так и в клиентский конфигурационные файлы:

sndbuf 0
rcvbuf 0

В этом случае, размер буфера будет задаваться настройками ОС. Для Linux и TCP это значение будет меняться согласно значениям из net.ipv4.tcp_rmem и net.ipv4.tcp_wmem, а для UDP — фиксированное значение net.core.rmem_default и net.core.wmem_default, деленное на два.

Если же по какой-то причине нет возможности поменять конфигурационные файлы клиента, следует отдавать достаточно большие размеры буферов с сервера:

sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"

UDP несколько отличается от TCP. У него нет аналога Window Scale, ему не требуются подтверждения о доставке пакета на транспортном уровне, но низкий размер буфера приема может замедлить и его, если буфер забивается раньше, чем OpenVPN успевает его считывать. Если скорость внутри туннеля кажется вам низкой даже с изменениями, описанными выше, то, возможно, имеет смысл либо увеличить размер буфера для всей системы целиком, увеличив net.core.rmem_default и net.core.wmem_default, либо всегда указывать определенный размер буфера в конфигурационном файле:

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

Но у меня Windows!

Если у вас и OpenVPN-сервер работает на Windows-машине, и все клиенты подключаются только из-под Windows, то поздравляю — вам ничего менять не нужно, у вас и так все должно работать быстро.

источник: http://habrahabr.ru/post/246953/

ссылка на материал:http://www.thin.kiev.ua/categoryblog/4594-open-vpn.html

{jcomments on}