HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...
Task #561959
open
Task #563567: Предложения по системе
Облачное резервирование
50%
Description
Выполнять фоновое, т.е. без участия пользователя/администратора бэкапирование базы данных 1с и базы данных звонков, а также их копирование на облачный сервер.
В настоящее время бэкапы создаются вечером и сохраняются на локальном диске на сервере.
Files
Updated by Anatoly Kim over 8 years ago
Подготовительные работы:
Какие файлы для резервного копирования нам необходимы?
Сама база 1с – примерный размер 576 Мб
База, в которой хранятся все звонки с АТС - примерно 375 Мб
Все вместе в заархивированном виде 951 Мб. На Яндекс можно загрузить файл размером до 10 ГБ. Чтобы загружать большие файлы надо пользоваться специальными программами.
Какие сервисы для облачного хранения существуют?
Yandex, Mail.ru, Dropbox, Amazon и т.д.
Из приведенных выше нами предварительно протестированы Yandex. Mail.ru, Dropbox. Более подробно остановились на Yandex.Диск
Условия хранения.
Яндекс возлагает отвественность за содержимое в файлах на пользователей.
Яндекс может самостоятельно, без предварительного уведомления пользователей менять правила хранения, устанавливать любые лимиты и ограничения.
Яндекс нигде не написал, что гарантирует сохранность файлов пользователей, но заявляет что предпримет все разумные меры направленные на обеспечение сохранности данных.
Весь список условий находится здесь: https://legal.yandex.ru/disk_termsofuse/
Сколько времени хранятся файлы?
Файлы хранятся на сервере до тех пор, пока вы сами их не удалите. Яндекс удаляет все ваши данные, когда вы удаляете свою учетную запись.
Утилита для организации автоматического копирования
Протестировали разные утилиты. В первом приближении многие похожи, из них была выбрана HandyBackup for YandexDisk. В Альтернативы утилите имеются в избытке, при необходимости можно подобрать. Но на первый взгляд - нет нужды.
Описание облачного резервного копирования (Как это будет сделано)
1. Задачи резервного копирования базы данных 1С и базы данных postgresql выполняются в прежнем режиме - по расписанию, в локальную папку на диске на сервере.
2. Дополнительно, в скрипт добавляется копирование последних файлов резервной копии в специально созданную локальную папку CloudBackup. Перед началом резервного копирования эта папка очищается.
3. Утилита HandyBackup настраивается на выполнение резервного копирования папки CloudBackup на Яндекс.Диск. В утилите настраивается количество предыдущих резервных копий, которое должно сохраняться на Яндекс.Диске.
Вообще Яндекс что если на диске закончится место, то вы не сможете загружать новые файлы.
4. При наличии сотрудника, ответственного за мониторинг и контроль функционирования резервного копирования, в HandyBackup настраивается отправка протокола работы утилиты на электронную почту этого сотрудника.
5. Таким образом, при реализации описанной схемы резервного копирования мы приближаемся к выполнению правила "3-2-1". Не хватает ещё одной резервной копии, например, внутри сети предприятия.
Updated by Anatoly Kim over 8 years ago
До 10 Гб Яндекс.Диск предоставляет бесплатно.
Цены на дополнительное место для Яндекс.Диск
10 ГБ - 300 рублей в год
100 ГБ - 800 рублей в год
1 ТБ - 2000 рублей в год
Оплата Яндекс.Деньги или банковская карта.
Исходя из этого, без пилотного тестирования предполагаем, что возможно нам хватит и бесплатного аккаунта на Яндекс.Диске.
В целом, нужно будет запустить пилот, оценить потребности в пространстве, при необходимости скорректировать план резервного копирования или купить дополнительное место.
Updated by Anatoly Kim over 8 years ago
Реализация
Система является дополнением для уже имеющейся системы локального резервного копирования. Для копирования только что созданных файлов резервной копии в облако, реализован следующий алгоритм:
• По окончании создания локальной копии файлы копируются в выделенную для облачной синхронизации папкуCloudBackup
• Запускается задача синхронизации папки CloudBackup с облаком
Синхронизация выполняется программой «Handy Backup for Yandex Disk», которая позволяет бесплатно синхронизироваться с Яндекс.Диск. Исходя из этого, для облачного хранения выбран Яндекс.Диск.
Настройки программы «Handy Backup» следующие:
• Глубина хранения – 10 версий
• Размещение – Яндекс.Диск
• Исходная папка на нашем сервере – D:\CloudBackup
• Тип копирования – полная копия
• Расписание выполнения – ручной запуск (запуск из скрипта)
Updated by Anatoly Kim over 8 years ago
- File Backup.png Backup.png added
В настоящий момент, система облачного резервирования полностью развернута на сервере и работает в штатном режиме. Однако после длительного наблюдения за работой, сбором статистики и анализом полученных данных в том числе каждого неудачного случая выявлена следующая проблема.
Проблема текущей реализации
В текущей реализации синхронизации с облаком фиксируются неудачные попытки синхронизации, как полный отказ (ничего не попало в облако), так и отказ в процессе выполнения (какая-то часть информации загружена в облако).
Протоколирование продукта «Handy Backup» не позволяет точно выявить, из-за чего вызван сбой - из-за прерывания связи, или же из-за проблем самой программы.
Любой из этих статусов означает, что резервная копия за этот день не размещена полностью в облаке.
Иначе говоря, третью копию не удалось разместить вне офиса, доступны только две копии в офисе (сами данные и их резервная копия на том же сервере). Следует отметить, что не всякий сбой связи может быть обработан, чтобы возобновить передачу и тем самым завершить задание синхронизации. Поэтому доступность третьей копии изначально не выше двух других.
Статистика синхронизации приведена в графике.
Распределение удач и неудач сведено в таблицу.
Колонка «Неудачно» говорит о том, что потенциально каждое пятое (20% из 100%) бэкапирование заканчивается неудачно или в 80% случаев все отрабатывается успешно.
Итоги
В целом, можно сделать вывод, что наличие резервной копии в облаке повышает шансы на успешное восстановление, но не является его гарантией при изначально испорченных данных. Введение промежуточного места хранения, вне офиса, но в пределах локальной сети (например, второй офис) позволило бы снизить ценность резервирования в облако, или даже при желании вообще от него отказаться.
Да и немного теории или как должно быть правильно
В дополнение ко всему прочему, наличие резервных копий без плана восстановления и периодической тренировки по их восстановлению может обернуться невозможностью восстановления данных. Этот момент нужно обязательно учитывать.
Updated by Anatoly Kim over 8 years ago
Итоги
В целом, можно сделать вывод, что наличие резервной копии в облаке повышает шансы на успешное восстановление, но не является его гарантией при изначально испорченных данных. Введение промежуточного места хранения, вне офиса, но в пределах локальной сети (например, второй офис) позволило бы снизить ценность резервирования в облако, или даже при желании вообще от него отказаться.
Да и немного теории или как должно быть правильно
В дополнение ко всему прочему, наличие резервных копий без плана восстановления и периодической тренировки по их восстановлению может обернуться невозможностью восстановления данных. Этот момент нужно обязательно учитывать.
Updated by Anatoly Kim over 8 years ago
Замечено, что на тестовом окружении утилита отрабатывает 100%, т.е. можно предположить:
Существуют проблемы на уровне боевого сервера: либо в ОС Windows Server, либо в ее сетевых компонентах, и т.д.
Так как текущая реализация - это 80% успешных из 100%, то принято решение применить не утилиту, а пакетные файлы (https://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D0%BA%D0%B5%D1%82%D0%BD%D1%8B%D0%B9_%D1%84%D0%B0%D0%B9%D0%BB) то есть использовать командный интерпретатор Windows (https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%BE%D0%BB%D0%BE%D1%87%D0%BA%D0%B0_%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B9_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B#.D0.9A.D0.BE.D0.BC.D0.B0.D0.BD.D0.B4.D0.BD.D1.8B.D0.B9_.D0.B8.D0.BD.D1.82.D0.B5.D1.80.D0.BF.D1.80.D0.B5.D1.82.D0.B0.D1.82.D0.BE.D1.80)
Следующий update по данной задаче должен быть 11 июня.
Updated by Anatoly Kim over 8 years ago
Есть конечно альтернативное решение пакетным файлам, а именно: поставить последнюю стабильную Windows Server.
Кажется, что проблема будет решена и утилита будет работать на последней Windows, но такое решение влечет не только дополнительные работы: надо заново все переустановить, но также и непридвиденные риски, которые как могут появиться, так и нет. Кроме того 100% гарантии, что утилита заработает на новой Windows тоже нет.
Поэтому эта альтернатива пока не рассматривается.
Updated by Anatoly Kim over 8 years ago
Запущен в тестовую эксплуатацию Syncovery, в нём можно выбрать используемую библиотеку SSL. Со стандартной библиотекой Microsoft SSL, как и в случае с @MaxSyncUp, возникает ошибка соединения. При использовании альтернативной OpenSSL соединение устанавливается.
В качестве места назначения для резервных копий выбран Google Drive - 15ГБ места против 10ГБ на Яндекс.Диск.
Updated by Anatoly Kim over 8 years ago
Вчера был проверен облачный бэкап - пока работает стабильно. Говорить о полноценном результате рано. Но данная стабильность выше, чем с предыдущей утилитой.
Updated by Anatoly Kim over 8 years ago
После 7 дней эксплуатации Syncovery тоже не смог соединиться с облачным сервером: не удаётся установить связь с ресурсом Google Drive. Ошибка 11001 SOCKET ERROR.
Резюме: Проект не реализуем на неисправной операционной системе.
Продолжить можно либо на другом целевом компьютере с исправной ОС, либо после починки ОС - на этом.
Updated by Anatoly Kim over 8 years ago
- Status changed from In Progress to Blocked
.