Переезд хуже пожара: как перевезти 3Тб данных с Dropbox на Google Drive и выжить

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

    Поэтому ещё 5 лет назад, основав «Банду умников» и делая тестовый тираж, мы уже хранили все данные в Dropbox — благо они тогда умещались в бесплатные лимиты. За это время команда выросла с 2 до 35 человек, и в этом году мы поняли, что пора прощаться с Dropbox и переезжать на Google Drive. Это решение вызвало череду приключений, которые мы совсем не планировали.

    Для переезда с одного облачного сервиса на другой может быть куча разных причин: от риска блокировок (привет, Роскомнадзор) до потребности в каком-то принципиально новом функционале. В нашем случае причина была простой: мы сели, посчитали и поняли, что вместо 12 аккаунтов с безлимитным хранилищем у нас может быть 35 аккаунтов (то есть вся команда) — и всё это ровно за те же деньги.

    Но фраза «сказано — сделано» не случайно встречается только в сказках. Не то, чтобы мы думали, будто перенос всех данных состоится по щелчку пальцев, но всё же на берегу представляли себе переезд куда проще. А зря.

    Вот 6 важных моментов, которые мы открыли для себя в процессе смены облачного провайдера.

    1. За привычным порядком скрывается хаос


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

    Полбеды, если они заботливо сложены в папку «Макеты 2011 архив». В этом случае проще понять, что нужно, а что нет. Куда хуже, когда это «Новая папка (2)», а в ней файл «ааааааааааааасысыв.psd». Самостоятельно оценить, насколько конкретный файл важен, почти нереально: нужно каждый раз выяснять, кто пользуется тем или иным документом или папкой, насколько важно это хранить и переносить. Кроме этого, даже полезные и актуальные документы порой оказывались в неожиданных и неочевидных местах.

    image

    Поэтому мы попросили команду «причесать» существующую структуру данных: каждый брал свой блок и упорядочивал его в порядке от общего к частному, чтобы даже человеку, который никогда раньше не сталкивался с тем или иным документом, было понятно, где его найти: Актуальная общая информация \ Логотип и фирменный стиль \ Логотип (РУС и ENG).

    После этой процедуры осталось куда меньше непонятных файлов и папок — их либо удаляли, либо помещали в общую структуру. Финальное структурирование всей библиотеки данных осуществляли в последнюю очередь, когда был наведён порядок в подразделах.

    Важно, что наведение порядка — далеко не самая быстрая штука. Сначала мы распределяли зоны ответственности, потом проверяли логику новой структуры, что-то дорабатывали, разбирались с «бесхозными» файлами. Всё это делалось параллельно с текущей работой и заняло около трёх недель.

    В результате мы получили максимально прозрачную и логичную структуру папок и избавились от 1/4 объёма файлов.

    Но приключения только начинались.

    2. Автоматической миграции не существует


    После наведения порядка, нам предстояло перенести с Dropbox на Google Drive 3 терабайта данных. Первое, что пришло в голову: «Наверное, существует какой-то сервис, который позволяет сделать это автоматически — так, чтобы нажать на кнопку в пятницу вечером и пойти загорать».

    Сперва нас очень воодушевили сервисы для миграции с одного диска на другой. Но когда мы поняли, что имеем дело со сложной структурой личных и командных папок, с которыми работают 35 пользователей с разным уровнем доступа — началось веселье. Получалась трёхмерная матрица:

    • Список пользователей, которые участвуют в работе с данными;
    • Структура доступа: к каким папкам имеет доступ тот или иной пользователь;
    • Уровень доступа к той или иной папке: просмотр, комментирование, редактирование, передача прав и т.д.

    В итоге мы поняли, что ни один из рассмотренных сервисов не позволяет перенести 3 Тб данных с сохранением структуры и уровней доступа. Более того, расчётное время «переезда» с помощью таких инструментов составляло несколько месяцев. Это нас категорически не устраивало.

    3. Перенос данных — путь через тернии к звёздам


    Мы арендуем хранилище в data-центре, который работает на серверной операционной системе Windows Server 2012. Оказалось, что, в отличие от Dropbox, Google Drive её не просто не поддерживает. Наше «гениальное» решение запустить процесс копирования напрямую оказалось технически нереализуемым на существующем ПО.

    Тогда мы обратились к data-центру с просьбой: «Ребята, а вы можете развернуть на серверных мощностях образ Windows 10?» Партнёры удивились — судя по всему, наш запрос был не самым популярным. Им потребовалось время, чтобы поднять «десятку» на нашем пуле мощностей. Когда это удалось сделать, мы установили там две программы: Dropbox и Google Drive — в обеих залогинились под одним сотрудником, назначенным владельцем всех папок. Теперь можно было копировать данные.

    Проблема была в том, что за раз (например, за одну ночь) невозможно было перенести все данные: процесс занимал минимум несколько недель. Если бы мы просто запустили перенос данных, дождались завершения и успокоились, мы бы получили в новом хранилище кучу неактуальной информации, потому что во время копирования папок в них ведётся работа: вносятся изменения в существующие файлы, создаются новые.

    Поэтому за первый заход мы скопировали весь объём данных, актуальный на дату начала копирования, а потом с помощью программы xStarter ежедневно догружали только те файлы, которые были изменены или созданы. Программа видит новые файлы и обнаруживает изменения свойств всех ранее загруженных файлов, как бы подавая сигнал: «Файл создан, догрузи. Файл изменился, загрузи заново». Со временем догрузки становились всё меньше по объёму. Перед выходными мы перевели весь Dropbox в режим чтения, чтобы никто не внёс изменения, и запустили финальный перенос. Объём финальной догрузки составлял 20 Гб, вся процедура заняла несколько часов. Сравните с 3 Тб в начале.

    image

    Уже после переноса всех данных, мы заново настроили все параметры, связанные с доступом сотрудников к разным папкам и доработали структуру. В понедельник утром мы получили полностью актуальные структурированные данные на диске Google Drive.

    4. Инструктаж — всему голова


    Чтобы всем было понятно, как быстро начать работать с данными в новых условиях, мы сделали и опубликовали подробную инструкцию.

    image

    Вот основные её элементы:

    • Новая структура папок, наглядно изображённая в Mindmeister. Чтобы разобраться, что где лежит, не приходилось копаться во всех папках — достаточно было посмотреть на карту. Плюс ко всему, новая структура файлов стала максимально логичной. На условном примере это выглядело так:

    1. Полет в космос
    1.1. Постройка ракеты
    1.1.1. Архив ракет
    1.1.2. Актуальная схема ракеты
    1.2. Архив документации
    1.3. Актуальный план-график запуска


    • Инструкция по установке и работе с программой Google Drive.

    • Основные отличия в работе Google и Dropbox, чтобы позже они не стали неожиданным открытием.

    • Правила работы с личными и общими папками.

    Инструкция позволила ответить на 90% возникающих вопросов и существенно сэкономить время: как тех, кто мог бы озадачиться вопросом, так и тех, кому бы предстояло отвечать.

    Всё, хэппи энд? Как бы не так!

    5. Если не контролировать поток данных, начинается давка


    В первый же день работы в Google Drive выяснилось: мы не учли заранее, что ребятам нужно иметь у себя часть данных в офлайн-режиме, а не в виде ссылок на файлы в облаке — например, тяжёлые макеты. Когда дизайнеры стали одновременно грузить себе в папки все исходники и макеты, нашему интернет-каналу стало плохо. Очень плохо. Часть процессов в компании просто встала — не работала даже 1C. Теперь, оглядываясь назад, мы понимаем, что нам следовало предпринять заранее:

    A. Договориться с ребятами о щадящем графике загрузки. Главное правило: не грузить всё и сразу. Сначала только те файлы, с которыми прямо сейчас работаем, потом следующие по приоритетности, и так далее. По возможности делать это ночью или на выходных.

    B. Заранее попросить сисадмина настроить квоты на сетевом оборудовании, когда у каждого есть своя гарантированная полоса. Это позволяет исключает ситуацию, когда из 100 Мбит канала 90 сразу забирают трое дизайнеров, а остальные 32 человека вынуждены делить 10 Мбит.

    C. Попросить того же сисадмина сделать расписание допустимых загрузок. К примеру, ночью всем можно качать данные с диска без ограничений, а днем только по полосам.

    D. Настроить приоритет трафику. Допустим, VOIP и RDP подключения сдалать самыми приоритетными, чтобы всегда работал скайп и удалённые сервера. Важная деталь: не всё сетевое оборудование имеет такую опцию. Для этих целей мы выбрали оборудование MikroTik и без проблем всё настроили.

    6. Неисповедимы пути Google Drive


    В первые дни работы выяснилась ещё одна неприятная особенность, после обнаружения которой мы точно будем вдвое внимательнее проверять всё ПО перед запуском. Когда мы включали оффлайн-доступ к папке или файлу в программе Google Drive, весь кэш сохранялся… только на диске «C». Возможность выбора в настройках диска для сохранения кэша отсутствовала.

    Не беда, если это 10 текстовых документов, с которыми работает копирайтер. Проблемы начинаются, когда нужен офлайн-доступ к макетам и исходникам видео, каждый из которых может весить гигабайты. В итоге у дизайнеров кэш всех файлов падал на маленький SSD-диск с системой. При его объёме 250 Гб это быстро приводило к переполнению, а диск «D» на 4 Тб оставался незадействованным в этом процессе.

    Позже выяснилось, что Google Drive только недавно реализовал функцию, позволяющую изменить место хранения кэша тех файлов, которые находятся в оффлайн-доступе — с диска «C» на диск «D». Возможность внести изменения есть только у администратора, который для этого запускает специальную команду в редакторе реестров — а отдельный пользователь по-прежнему не имеет такой возможности.

    Вывод простой: перед принятием решения о запуске нового ПО, его следует внимательно и многократно тестировать во всех рабочих сценариях.

    Три коротких вывода


    1. Выбор подходящего облака — жизненно важная штука.

    Здесь надо внимательно взвесить все за и против: изучить тарифы, софт и функционал. В случае ошибки и последующего разочарования в выборе можно «попасть» на переезд. А это, мягко говоря, нетривиальная процедура, которая может заморозить всю работу и повлечь за собой немалые затраты.

    2. Полезно всегда держать файлы в порядке и на всякий случай иметь план «B».

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

    3. Переезд — это не только про технику, но и про команду.

    Все манипуляции с переносом файлов и наведением порядка могут обернуться полным провалом, если не держать команду в курсе и действовать по принципу «разберутся как-нибудь сами». Может и разберутся, но без прозрачного и заботливого инструктажа работа этот процесс будет куда более трудозатратным и изматывающим.
    Share post

    Similar posts

    Comments 85

      +8
      Если у вас уже есть свои сервера, то почему бы не попробовать заиспользовать что-то вроде owncloud, nextcloud или что-то похожее?
        +2

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

          +1
          Вы имеете в виду развернуть свое собственное облако? тут момент в том, что мы хоть и прокачаны в части IT но не настолько, чтобы обеспечивать качественную поддержку. Стараемся использовать проверенные решения на рынке. Но идея очень здравая, да.
            +1
            Собственно «развернуть свое собственное облако» звучит очень-очень громко. При условии что у вас есть хоть какая-то инфраструктура и она хоть как-то защищена (бэкапы, зеркалирование) — вся ваша активность сводится к уставновке и минимальной настройке.
            Из плюсов — все при вас, нет необходимости бегать от одного cloud провайдера к другому, настройка как душе угодно и прочее.
            Подумайте на досуге, возможно это сыкономит вам время и деньги в будущем.
              0

              Как минимум надо грамотно настроить бекапы, протестировать их восстановление. Потом, если сервис торчит голым задом в интернет, надо его обновлять хотя бы при выпуске исправлений безопасности, которые надо мониторить. Обновления иногда могут ломать сервис, надо проверять. И так далее.


              ИМХО подход у ребят совершенно правильный — то, что не является твоим основым продуктом, надо покупить как сервис и не парится.

                0
                сЭкономит
                0
                На самом деле для пользования тем же самым owncloud не требуется многих знаний и времени- установил, настроил и вперёд. Правда я им пользовался как временное хранилище (на работе облако так же под owncloud и там «живёт» порядка 1.2 Тб личных данных)… к чему это я, ах да- сейчас много мануалов, пошаговых инструкций почти для всего. Вы создаёте продукты, а я даже толком не знаю ни одного языка программирования, но смог установить и настроить :-) уж у Вас то всё выйдет на славу- это факт!
              +3
              Позже выяснилось, что Google Drive только недавно реализовал функцию, позволяющую изменить место хранения кэша тех файлов, которые находятся в оффлайн-доступе — с диска «C» на диск «D».

              К счастью, в случае с Windows можно смонтировать раздел жесткого диска в каталог штатными средствами. Будет не очень гибко, но вполне надёжно.

                –5

                Вот только знают об этом обычно только админы, работавшие с Unix подобными системами :).

                  +5

                  image
                  Мне кажется многие админы видели это больше одного раза в жизни в управлении дисками. Что особенно приятно, у одного раздела может быть и имя диска и несколько смонтированных путей.

                    +1
                    Да вообще не только админы знают о наличии различного рода линков в NTFS.
                    +1
                    Или SoftLink C:\Temp-->D:\temp. Например. Актуально как для Виндовс, так и для linux-машин.
                      +4
                      Софтлинк да — пробовали, повел себя неадекватно на ряде машин. Поддержка Гугла рекомендовала через реестр править. Вообще конечно полный бред с их стороны такой подход
                        +2

                        В NTFS есть помимо симлинков ещё и junction, который можно создать через mklink /J. В некоторых случаях, он работает стабильнее, чем софтлинки.

                        0
                        В windows mklink
                          0
                          По моему личному впечатлению на винде (покрайней мере на 2012 сервере) симлинки (Вы это под софтлинком подразумеваете? Который через mklink делаются) работают как-то странно. Вроде бы в «Проводнике» все норм, но у некоторых программ возникают проблемы при работе через симлинки. Причем проблемы из разряда «уууу шайтанама, че-то не работает».
                            0
                            начиная с десятки RS3 всё наоборот — junction стали работать значительно хуже и пришлось их все передельівать в симлинки
                      • UFO just landed and posted this here
                          0
                          у DB лан синхронизация — вещь, меня одно утешает, что в сам File Stream был выпущен сравнительно недавно, и будет дорабатываться.
                          +3
                          который работает на серверной операционной системе Windows Server 2012. Оказалось, что, в отличие от Dropbox, Google Drive её не просто не поддерживает.

                          Удивительно это читать — вы знаете о Google, но даже не попробовали его использовать для решения проблемы. По запросу «Google Drive File Stream Windows Server» (скопировано из ошибки, которую пишут установщик при попытке установить штатно) первая же ссылка ведёт на reddit, где написано как же всё таки установить Drive на сервер.
                            +2
                            если говорить о личных штуках -я так и делаю, даже нравится, самому «наколхозить» и взломать систему :) а если говорить о корп. решениях, я стараюсь до последнего решить вопрос стандартными методами. Могу даже объяснить почему.
                              0

                              Да, объясните, пожалуйста. Интересно "корпоративное" мышление в этом случае.

                                +1
                                Основной момент в делегировании полномочий. Когда бизнес быстро растет, а мы выросли с 2 человек до 40 фактически за 3 года, ты почти каждый день должен отдавать по кусочкам свои задачи кому-то, кому ты очень доверяешь и кого ты хорошо подготовил. Так вот, зачастую не получается просто делегировать напрямую, нужно искать компромисс, потому что мы очень жестко контролируем издержки. Допустим, я научил нашего офис менеджера оперировать понятиями SSD диск, память, объяснил чем отличаются конфигурации ПК для разных сценариев и т.д. И она, как сообразительный сотрудник, вполне может сама с этим управляться, без меня, заказывать нужные железки, объяснять сотрудникам что происходит с их ПК, подключать удаленного сис. админа если все варианты исчерпаны и надо апгрейдиться. Тут тоже самое — мы не хотим брать выделенного сис. админа который 70% времени будет сидеть, причем объективно, ничем не занятый. Мы используем аутсорс + прокачку сотрудников по базовым навыкам IT и вот тот колхоз, что я написал выше, он уже «слишком» для основных сотруднико. За гранью, это будет перегруз — я лучше сделаю чуть более длинным путем, но зато, например, они смогут прочитать все в официальной тех. поддержке гугла или слака. И выиграют все: меня, как руководителя и эксперта в этой области не будут дергать, они сами расширят свой проф. кругозор, а пользователь, кто запрашивал эту услугу останется доволен, а компания еще и сэкономит.
                                  +1
                                  Итого: на сисадмине сэкономлено, зато данные компании — в заложниках у сторонних облачных сервисов. Вы их хоть бэкапите локально?
                            0
                            Когда мы включали оффлайн-доступ к папке или файлу в программе Google Drive, весь кэш сохранялся… только на диске «C».
                            Позже выяснилось, что Google Drive только недавно реализовал функцию, позволяющую изменить место хранения кэша тех файлов, которые находятся в оффлайн-доступе — с диска «C» на диск «D».

                            Оу мама. И это в 2018 году! Формально, самое правильное место для кэша — %APPDATA%, которая располагается в подпапке профиля, который по-хорошему надо уносить с системного диска при заливке ОС (или сразу после), и если этого не было сделано, то ребята ССЗБ. Фактически, оффлайн-кэш лучше с точки зрения пользователя хранить в подпапке Documents с соответствующим приложению именем (а-ля "Google Drive — username"), а вот её уже перенести на соседний диск куда легче, и с этим справится и пользователь без админских прав, если на диске с данными у него есть право create subfolder. Хорошо, что сделали правильный вывод :)

                              +2
                              Кхм, вариант. Мнтересно, а что будет с производительностью других приложений которые хранят там данные? Например кеш Адоба у дизайнеров, где очень критична скорость?
                                +1
                                Даже Адоба не надо — кэш браузера, лежащий на HDD, ошутимо замедляет работу этого самого браузера.
                                  0
                                  Ну как вариант, подпапку %APPDATA%\Local\Adobe смапить обратно на C:. Иначе получается старая песня, или быстро, или много, но не оба сразу.
                                  +1
                                  Offline-кеш в %localappdata%
                                  +2
                                  3. Перенос данных — путь через тернии к звёздам
                                  Делается одной простой командой:
                                  robocopy "D:\nsr\index" "Y:\new_place\index" /MIR /NFL /MT

                                  Сам часто переношу данные которые не статичны
                                  Причем её можно обрывать, запускать заново и т.д.
                                  И будет лишь «докатывать» новые и измененный файлы.
                                    +2
                                    Сколько отделов в компании использовало Дропбокс? Переезжали сразу все?

                                    PS. За «ааааааааааааасысыв.psd» в общем хранилище надо наказывать лишением доступа к чайнику.
                                      –1
                                      у нас нет отделов как таковых, есть общая команда 35-40 человек.
                                        0
                                        То есть, все занимались всем и никакого разделения на проекты или типу выполняемых работ?
                                          0
                                          Нет у нас несколько десятков проектов и команда работает по проектно, собирая под каждую задачу свою комбинацию сотрудников
                                            +2
                                            Понятно. То есть, можно было пару проектов сначала перевести на Гуглодиск и протестить.
                                      0
                                      Я правильно понял, что программа xStarter — это программа для автоматизации действий на ПК?
                                        0
                                        да, именно
                                          0
                                          Удивительно, что программа, которая закончила развиваться в 2009 году, успешно работает и по сей день. Сам пользовался ей, для автоматизации рутины.
                                            0
                                            она реально неплохо все делает!
                                        +1
                                        есть же cvs, которые умеют отслеживать бинарники и проприетарные форматы, кто-нибудь пробовал прикрутить управление версиями не к текстовым документам?
                                        так-то репозиторий поднять нынче просто очень
                                          +1

                                          Репозиторий на 3 Тб под большие бинарные файлы — так себе идея. Особенно если эти файлы часто редактируются.

                                          +1
                                          — что вместо 12 аккаунтов с безлимитным хранилищем у нас может быть 35 аккаунтов (то есть вся команда) — и всё это ровно за те же деньги.

                                          Я думаю что если бы позвонили в маркетинговый птдел dropbox-a вы вполне могли бы договорится получить тоже самое за те же деньги и сэкономить на переезде.
                                            +3
                                            Я думал, но там тоже есть нюансы, мы, например, клиенты gsuite и нам выгоднее все консолидировать. Сейчас думаем отказаться от подписки на офис, т.к. есть все в гугле. И потом, я очень расстроился за маркетинг дропбокса, что когда их клиент с почти 5-ти летней историей прекращает работать, мне даже формального вопроса не задали — а почему? Что случилось? Так буднично — хоп, отключили и через два дня вернули деньги. Я полагал, что они будут цепляться.
                                              0
                                              Мне кажется какие-то глобальные полиси стали менятся — раньше когда я закрывал счета и кaрточки в банках — обязательно спрашивали почему и уговаривали это не делать.
                                              И мне приходилось себя сдерживать, чтобы не наговорить необдуманных гадостей про их «сервис». Сейчас — повсеместный молчек. Что не может не радовать.
                                                0
                                                Скорее всего, что они считают так — ничего нового вы им не скажете, все уже озвучено до вас, а по вашим проблемам никто не будет моментально что-либо «допиливать», потому xnj есть свой план разработки и отклонятся от него себе дороже. Раз не будут допиливать, то клиент все-равно уйдет, но раз так и так уйдет, то какой смысл спрашивать и тратить на это время и ресурсы?
                                              +2
                                              Не увидел какого-либо резервного копирования. Если гугл в результате аварии / санкций заблокирует ваши данные — что будете делать?
                                              Второй вопрос — неужели нельзя купить какую-нибудь Synology (если уж не хочется нанимать сисадмина) и поставить ее в офисе? Чтобы не качать рабочие данные туда-сюда. Бекап можно сделать куда угодно.
                                                0
                                                по первому пункту — они выкатили на днях функцию экспорта: gsuiteupdates.googleblog.com/2018/05/export-all-your-g-suite-data-in-one-step.html мы готовимся на нее перейти, но пока не понятно что с драйвом. Была еще задумка оставить один акк дропа, с безлимитом и туда на сервере перекладывать данные как-то. Но у дропа нет таких акков, максимум 1 Тб. Короче вопрос в процессе решения.

                                                Меня очень парит вопрос безопасности, ну кому мешает прийти в офис и забрать этот синолоджи? А пожар, а потоп и т.д. Везде есть свои плюсы и минусы.
                                                  +1
                                                  Меня очень парит вопрос безопасности, ну кому мешает прийти в офис и забрать этот синолоджи?

                                                  Можно зашифровать.
                                                  А пожар, а потоп и т.д. Везде есть свои плюсы и минусы.

                                                  Если данные дороги — всегда нужно бекапить в другое местоположение. Хоть облако, хоть локальное железо. На данный момент у вас это не реализовано.
                                                    +1
                                                    так-то во всех айтишных конторах есть свои серверные помещения, где стоят стойки с дорогущим оборудованием (серверным и телекоммуникационным), и ведь не боятся же, что кто-то придёт и заберёт.

                                                    плюс никто не отменяет хранить вашу инфу в офисе и сливать в облако.
                                                    всяко лучше чем хранить только в облаке или только локально в офисе.
                                                      0
                                                      Причём решений достаточно много: от самых недорогих до дорогих. Мы решили юзать принцип: храним бэкапы в офисе + раз в неделю крайний заливаем в облако.
                                                      0
                                                      Считаю важным сказать, что необходимо присмотреться к вопросу бэкапа, вот статья
                                                      habr.com/post/262043
                                                      как Amazon EC2 потерял данные клиента
                                                    0
                                                    Названия папок и файлов у нас, например, строго регламентированы. Файл с непонятным названием удаляется без разговоров первым заметившим непорядок — извини, ничего личного. Очень дисциплинирует, надо сказать. Если нужен файлик aaaaa.psd сохраняй его локально, хоть на рабочий стол, в общем каталоге испражняться не надо.
                                                      0
                                                      а вы не поделитесь правилами? ) очень интересен опыт других в этой части
                                                        0

                                                        Ну это сильно зависит от отрасли. Мы экспериментальной наукой занимаемся: данные экспериментов, mathcad, статьи, графики, картинки.

                                                          0
                                                          думал есть общие принципы, как мы тут в части переезда старались описать
                                                      0
                                                      Странное немного желание хранить данные, которые нужны, как я понимаю, исключительно локально, в облаке. Поставили бы локальный NAS. 3тб сейчас на одном бердане даже бывают. И никаких проблем с миграцией. Для надёжности можно добавить зеркало + инкрементные бакапы. В чём профит от облаков в вашем случае? Кроме описанных неудобств, хорошо если последних?
                                                        0
                                                        Безопасность и надежность, любое облако от большой компании априори надежней в выборе между: только облако или только локально. Нам просто не потянуть такой уровень безотказности и надежности внутри компании. Мы объективно оцениваем риски. и я жду все же локальной синхронизации от Гугл как это было в Дропе. Это решит все вопросы.
                                                          0
                                                          Облако далеко не панацея. Завтра выйдет очередной чудный закон наподобие Яровой, GDPR, блокировки и так далее. И хорошо, если данные вообще можно будет забрать. Локально же поставить сервер дело нескольких дней. 3тб на сервере сейчас это уже вообще ничто, согласитесь. Небольшой сервер на несколько жестких. Мне кажется проблема несколько надумана. Не те объемы совсем. Я понимаю, ну хотя бы о сотне тб разговор шёл. И не в будущем, а сейчас прямо.
                                                            0
                                                            У нас уже готов собственный впн сервер вне России, и часть трафика уже туда «заворачивается», в крайнем случае мы готовы завернуть весь. Поэтому мы тут тоже подстраховались, хотя все это конечно дико неудобно для всех.
                                                          0
                                                          Чтобы хранить информацию своими силами необходим квалифицированный сисадмин. А чтобы гарантировать её сохранность нужен очень квалифицированный сисадмин. Плюс ПО и оборудование. Кроме того, никто не застрахован от пожара, потопа и ОБЭП. Не строить же распределённую систему. Поэтому облачное хранилище на порядки дешевле описанной схемы.
                                                            0
                                                            Про порядки — это вы изрядно прибавили (см приближенные расчеты немного ниже по ходу обсуждения).
                                                            Про ОБЭП — давно уже изъятия не встречал, их интересует бухгалтерия, но даже в этом случае чаще всего удовлетворяются последним бэкапом хотя бы недельной давности. Ну или при них его делаешь (Работаю в области 1с и говорю не со слухов, а практики).
                                                            Про админов — спасибо на добром слове, но тут скорее в архитектуру системы упирается. У нас в свое время архитектор нарисовал план, админы его реализовали. С тех пор состав админов поменялся процентов на 60, но все работает как часы — бэкап, мониторинг, проверки целостности и т.д.
                                                              0
                                                              Вы преувеличиваете, честно. Админов средней руки хватает. Привлечь, настроить и периодически (можно удалённо) поддерживать. Даже свой, постоянный, не нужен. Мы сами занимаемся изготовлением ПО в том числе для хранения некоторых специфических данных десятками и сотнями терабайт, знаю о чем говорю.
                                                                0
                                                                Для гарантии сохранности достаточно сисадмина, знающего, что такое бэкапы, и да, их можно делать и в облако, желательно в несколько. Если проблема в ОБЭП, то это решается арендой сервера на удалённом хостинге, и, кстати, в статье упомянут такой сервер…
                                                              0
                                                              А поднять свой файловый сервер? Три терабайта в наше время это небольшой размер,
                                                              ну для бэкапа еще. По крайней мере копирование будет несколько часов занимать вместо недель. Если хочется облако то виртуальный сервер арендовать.
                                                                0
                                                                наш прогноз что данные будут расти по экспоненте, удваиваясь каждый год как минимум. локальное решение так себе.
                                                                  0
                                                                  35 человек, работающие с большими файлами, положат дешевый сервер на ура, а ssd на 3 терабайта кусаются.
                                                                    0
                                                                    да, или собирать какие-то рейды, а это недешево :(
                                                                      0
                                                                      Неожиданный аргумент. Давайте посчитаем в некоем приближении — стоечная дисковая полка от НР с дисками на сегодняшний объем на райд10 — около 120к.руб (понятно, что бу, но как показывает практика — надежность при грамотном выборе не страдает), сервер для OwnCloud (это если совсем по взрослому играть) в районе 70-100 к.руб. При этом его можно грузануть сторонними задачами типа проксирования, поддержки своего веба и т.д.
                                                                      Если хотим конкретно сэкономить — то просто отказываемся от сервера ОвнКлоуд. Простых виндовых шар часто оказывается достаточно. особенно при налаженной системе бэкапа. в дисковую полку размер бэка заложен.
                                                                      Расширение объемов этого наколеночного чуда — в районе 15 к.руб за Тб. Сопровождение/аутсорс — в районе 1,5/мес (опционально, ибо при правильно налаженной системе мониторинга ....).
                                                                      итого: Мин 120, макс 220. Ежемесячное — 2к. сопоставимо с сегодняшней ценой за ГуглоДрайв? ну, на дистанции хотя бы в год? При том, что появляется масса плюсов — локальность. скорость доступа… Ну и опять же — рядом и свое.
                                                                      Да, стойку и серверную я не считал. т.к. у нас ПТО этим занимается. И если их нету, то стоимость проекта конечно вырастит, но не смертельно.
                                                                        0
                                                                        посмотрел цены на г.драйв. Ну да, 7 к.р/мес (84 к. по году). Срок окупаемости конечно великоват для сегодняшнего положения наверно.
                                                                        Еще один вопрос тогда: а за активное использование диска Гугл ничего дополнительно не берет? Ведь это в итоге нагрузка на сеть…
                                                                          0
                                                                          ниже написал, чисто анлим получается 4 евро лицензия у Гугла.
                                                                            0
                                                                            Если 188 евро в месяц, то вариант со своим хранилищем отбивается примерно за 1,5 года даже в максимальной комплектации. Или я ошибаюсь?
                                                                              0
                                                                              я думаю корректно считать не бу + поддержку надо добавлять, плюс зип
                                                                                0
                                                                                Тут же каждый по себе, по потребностям и по возможностям выбирает. У нас похожий бу-шный набор живет уже 5 лет без нареканий. Ставили себе на эксперимент, но прижилось и втянулось в компанейские процессы. Серверное бу живет достаточно долго.
                                                                                Ну и история из жизни: на одной из конференций, в которых мне случилось участвовать были ребята из гугла. И они на «голубом глазу» рассказали, что в их дата-центрах используется кэжуал-оборудование. Ибо даже если рухнет, то можно быстро заменить. Прямо блочно, не разбираясь в поломке. Хард скотчем примотан, планки памяти воткнуты. Как-то так.
                                                                  –1
                                                                  Что делать тем сотрудниквм у кого линукс? Ведь клиент gdrive нету
                                                                    0
                                                                    через веб работать
                                                                  • UFO just landed and posted this here
                                                                      0
                                                                      8 евро за все, включая почту. Мы были на базовом тарифе с 30 Гб сначала, платили 4 евро, до анлима надо было добавить еще 4 евро, итого 8. Сейчас 47 лицензий за 376 евро, т.е. 188 евро в месяц за «добавку анлимную». А у Дропбокса было 165 долларов за 12 лицензий. Ну примерно 150 евро. Годовая экономия значительная.
                                                                      • UFO just landed and posted this here
                                                                          0
                                                                          По любому здесь можно очень много сэкономить, даже наняв удалённого сисадмина однократно для поднятия своего «облака» и периодически на поддержку (если потребуется)… И даже аренда сервера заметно дешевле выйдет, если религия не позволяет это делать локально!
                                                                        0
                                                                        Как вы настроили уровень и структуру доступа? Вручную?
                                                                          0
                                                                          да, все руками собрали и сделали
                                                                          0

                                                                          Непонятная история. Неорганизованные сотрудники, оставляющие аааааааа.psd, к делу не относится. Права? Скопируйте все и сделайте права как нужно. Как скопировать? Куча способов вроде. Наша компания (CloudEndure) позволяет миграцию в реальном времени. Так в чем пожар?

                                                                            0
                                                                            Пожара нет, но с таким походом вы точно клиентов на наберете :)
                                                                            –1

                                                                            Ну если вы сказали "точно", значит точно. Я просто против приемов "Секс, а теперь, когда мы привлекли ваше внимание..."
                                                                            P.S. "поход" — это подход? :) Так это вы наоставляли аааааааа.psd? :)

                                                                              0
                                                                              Рассматривали возможность использовать Resilio Sync? Тот же dropbox/google drive только все у себя и под контролем

                                                                              Only users with full accounts can post comments. Log in, please.