Как лучше организовать резервное копирование?

Question

[Сергей Золотарёв]

Добрый день.
Досталась мне в наследство следующая структура: 2 города, в каждом из городов терминальный сервер+сервер БД и резервный сервер (на случай поломки/конфискации основного сервера БД), находящийся в другом месте. На сервере работает программа Акцент 7.0 под управлением MS SQL, резервные копии создаются ею же (файлы в формате *.bak): раз в сутки полная копия и каждые 3 часа разностные. В Городе1 размер файла полной копии уже достигает 7 Гб, в Городе2 - 5 Гб.
Стоит следующая задача: в каждом из городов резервная копия базы должна быть на: 1) сервере БД; 2) на резервном сервере в этом городе; 3) на резервном сервере другого города. Раньше это достигалось при помощи Google Drive (скриптом файл копировался в папку Google Drive, после синхронизации с облаком тем же скриптом удалялся). Основная проблема этого метода в том, что после удаления файла на ПК файл в облаке помещается в корзину, а не удаляется безвозвратно, продолжая занимать место в облаке. Приходилось периодически заходить и чистить вручную корзину. При нынешнем размере файла это приходится делать ежедневно.
Подскажите, пожалуйста, как уйти от этой кривой схемы или хотя бы как-то оптимизировать.
Спасибо.

Answer 1

[АртемЪ]

Насколько я понял основная задача состоит в том чтобы автоматически перекидывать довольно крупный файл архива в другой город. Так?

Для этого можно воспользоваться например программой BtSync - cинхронизация по протоколу битторент без всяких облаков, напрямую между устройствами.

Хотя если соединения не очень скоростные, и сложно прокачивать большие объемы ежедневно, то можно использовать Branch Cache

Comments

[Сергей Золотарёв]

Говорят, BtSync уже пытались использовать, но из-за него начинала "тормозить база", поэтому отказались. Попробую ещё раз, возможно, неправильно настраивали.
А как Вы думаете, имеет смысл докупить места в GoogleDrive и продолжать использовать старую схему или это уж очень коряво?

[АртемЪ]

Сергей Золотарёв: Смысла в гугл драйв не вижу, зачем в данной схеме лишний элемент в виде облака?
Я использую BtSync для синхронизации приличных объемов информации (до 100Гб) в день и ничего.
Как из за него может база тормозить вообще не представляю - у вас что бэкапы и рабочая база лежат на одном диске?

Ну и поскольку у вас каждый день приходится качать фактически одно и то же с небольшими изменениями, то посмотрите в сторону Branch Cache

[Сергей Золотарёв]

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

[АртемЪ]

Сергей Золотарёв: И еще один момент - BtSync тоже сохраняет удаленные при синхронизации данные и хранит их 30 дней по умолчанию.
Вам насколько я понял это не надо, поэтому зайдите в настройки и подредактируйте параметр "максимальный возраст архива"

Answer 2

[NRinat]

Извините, что не совсем по вопросу.
Для отказоустойчивости и надежности не думали использовать резервное копирование Azure? С вашим размером резервных копий, это будет стоить копейки, а надежность будет супер.
Можно организовать, чтобы копии ваших бекапов хранились на разных континентах.