Я хочу сменить поставщиков веб-хостинга с «Поставщика O» на «Поставщика N» для конкретного сайта, которым я управляю. У меня проблемы с поставщиком O. Я управляю несколькими сайтами, которые в настоящее время размещены у поставщика N, и все в порядке.
Кстати: все сайты, которыми я управляю, не являются коммерческими. Поэтому сохранение минимальных затрат жизненно важно, и альтернативы недорогому общему хостингу нет.
И поставщик O, и поставщик N рекламируют "неограниченное хранилище", а разрешенной полосы пропускания более чем достаточно для типичных операций сайта.
Меня сдерживает объем данных, которые нужно перенести на новый хостинг: 55 ГБ и он растет. (Данные в основном JPGs исторических данных - не порно.) Кажется, что огромное количество данных для перемещения. (Примечание: все эти данные накапливаются на сервере в течение нескольких лет, и нет ничего близкого к удаленной копии всего набора данных.) Очевидно, что скачивать все данные со старого сервера и выгружать их нецелесообразно. на новый, используя мой офисный DSL.
Доступ к оболочке доступен с обоих концов. Я изучал прямые передачи с сервера на сервер с использованием rsyn, scp, tar + wget и т. Д. (Я нашел несколько информативных сообщений об этом здесь, на serverfault). Используя существующую учетную запись Vender N, я ' Я провел несколько межсерверных испытаний с передачей данных от поставщика O. Если цифры, которые я получил, являются репрезентативными, передача 55 ГБ займет много недель при открытом дросселе. Кажется ли этот результат разумным?
Я не нашел много советов по практическим аспектам передачи данных с сервера на сервер. Например, желательно ли уменьшить скорость передачи, чтобы избежать забивания труб - и быть замеченным? Предварительные цифры показывают, что попытка быть хорошим может продлить время перевода до месяцев. Или услуги хостинга уже ограничивают пропускную способность, особенно для учетных записей с низким уровнем цен?
Также меня беспокоит определение «неограниченного хранилища» в списках функций поставщиков. Производитель O не жаловался на загрузку данных в 55 ГБ. Какая гарантия, что поставщик N согласится с этим? Чтение и повторное прочтение соглашения об обслуживании Поставщика N не помогло. Кажется, это их суждение о том, допустимо ли использование складских помещений покупателем. Если бы данные сайта весили, скажем, 1 ГБ, я сомневаюсь, что они даже посмотрят на них, но я предполагаю, что 50 ГБ + могут получить некоторую проверку. Или условия обслуживания обычно не соблюдаются в отношении использования хранилища, за исключением случаев действительно вопиющего неправильного использования?
Кошмар, который я представляю, - это потратить недели или месяцы на передачу 95% данных поставщику N, а затем получить уведомление от поставщика N, в котором говорится: «Использование вами хранилища недопустимо».
Правильно ли я формулирую проблемы? Я упускаю что-то невероятно очевидное? Предложения, пожалуйста.
TIA,
hen3ry
Спасибо за все ваши предложения. Сначала я отвечу вкратце:
- Многие предлагают позвонить новому поставщику и спросить его о большинстве этих проблем. Мой опыт работы с техподдержкой в прошлом был в целом разочаровывающим, но я узнал, что наилучшие результаты достигаются, когда я подробно изучал проблему. Так что… да, теперь я точно понимаю, о чем спрашивать, позвоню.
- Кто-то предлагает ту или иную форму кроссовок. Отличная идея, никогда не думал об этом. Отправьте им диск. Будет ли новый поставщик готов предложить такой уровень обслуживания для новой учетной записи общего хостинга? Если лучший способ электронного перевода безнадежно медленный, стоит спросить.
- Многие НАСТОЯТЕЛЬНО предположили, что необходима полная резервная копия сайта. Вы проповедуете хору. Я полностью согласен! Обстоятельства, отчасти не зависящие от меня ...
- Люди предлагали различные подходы, основанные на nc (netcat, synch, sshfs + sync и т. Д.). Большинство из них невозможно, потому что старый поставщик не поддерживает их (еще одна причина оставить этого поставщика!). Единственный оставшийся кандидат. был scp, который работает через SSH. Старый поставщик, похоже, блокирует любую попытку SSH-подключения к новому поставщику, но я смог использовать scp с другого моего сайта от нового поставщика.
Результаты первичного тестирования:
Используя SCP от нового поставщика, я смог достичь пиковой скорости передачи 3,7 МБ / с или около того, но из-за частых остановок передачи общая скорость была намного меньше. На группу из 280 файлов общим весом около 1,4 ГБ потребовалось около часа. Грубо говоря, это означает, что для передачи всего набора файлов потребуется менее 40 часов - это выглядит очень хорошо.
Избежание остановок при пересадке очень поможет сократить время пересадки. Я не видел никакой закономерности. Часто передачи останавливались до того, как был передан первый блок данного файла (0%), но задержки до 30 секунд или более случались случайным образом в середине передачи. Любые идеи? Неужели старый продавец дросселирует? Могу ли я конкурировать с другими клиентами за пропускную способность?
Единственный способ быть уверенным в их политике - спросить их.
Вы также можете рассмотреть кроссовки. В зависимости от того, где они расположены, смогут ли они выполнять часть услуги, будет ли вам предоставлен физический доступ, если они этого не сделают, и других факторов, вы можете использовать внешний USB-накопитель для выполнения перевод. Конечно, это могло быть намного быстрее, чем недели или месяцы. Им это тоже может понравиться, так как это не позволит им попасть на их линии. FedEx будет рада принять участие, если потребуется.
Вы можете просто позвонить им и объяснить ситуацию. Скорее всего, они позволяют вам передавать все, что вам нужно, на полной скорости, чтобы начать работу. Вы платите деньги за размещение своих данных там, они должны быть гибкими в отношении фактического размещения ваших данных там.
Согласитесь с предложениями позвонить им.
Если вы в конечном итоге выполняете передачу по сети, учитывайте виртуальную уверенность в том, что процесс, который занимает дни или недели, будет прерван и перезапущен. По этой причине я склоняюсь к такому подходу, как rsync, и отхожу от такого подхода, как передача tar в netcat. Если вы планируете создать один большой tar-файл для копирования, не забывайте, что это примерно удвоит ваше текущее использование хранилища во время передачи на обоих концах, и что есть большая вероятность, что ваш набор данных изменится во время передачи, поэтому вам понадобится какой-то механизм для обновления удаленной копии с изменениями.
Кроме того, похоже, что у вас нет резервной копии, а это ожидает катастрофа. Если в процессе передачи будет создана дополнительная физическая копия ваших данных (например, внешний жесткий диск), рассмотрите возможность обновления этой копии при изменении данных. Если ваш процесс передачи будет происходить по сети, рассмотрите что-то вроде Amazon S3 (или Rackspace, или Azure, или что-то еще) как промежуточное место назначения и как текущее резервное копирование. Недорогие хостинг-провайдеры, вероятно, не предлагают никаких гарантий относительно резервного копирования ваших данных - при условии, что они даже попытаются это сделать, что может быть слишком оптимистичным - и даже если они будут время от времени делать резервные копии, вы можете снова приступить к работе. приоритет, если они столкнутся с какой-то трагедией.
Если доступ к оболочке доступен на обоих концах, и если у вас есть доступ к netcat (nc), самый быстрый способ передать 55 ГБ данных - через netcat и tar. Вот как:
На новом сервере:
# nc -l -p 40022 | tar xf -
И на текущем:
# tar cf - /path/to/data | nc newserver 40022
Это, конечно, не шифруется в общедоступном Интернете, поэтому не делайте этого, если вас беспокоят данные, которые вы передаете.
Кроме того, 55G с использованием rsync поверх ssh (если он доступен) не будет невыносимо медленным, и вы получите преимущество в виде возобновления прерванной передачи.
В противном случае вы сможете выполнить scp. Это должна быть та же скорость, что и rsync, поскольку он использует тот же транспорт, но вам придется перезапустить, если соединение разорвется.
Я бы не стал беспокоиться о 55G - это действительно очень маленький объем данных по сегодняшним меркам - это не вызовет никаких проблем для вашего нового поставщика.
Если бы у меня было 55 ГБ данных на каком-то сервере, что было для меня вообще важно, я бы использовал свою линию DSL, чтобы загружать их всю ночь, столько ночей, сколько потребуется, чтобы убедиться, что у меня есть резервная копия, которую я контролирую. Особенно если сервер у недорогого провайдера. Хотя поставщик может создавать резервные копии, что произойдет с этими резервными копиями, если поставщик прекратит работу?
Что касается передачи от поставщика к поставщику, я ожидаю, что скорость будет не менее одного мегабайта в секунду. Перенос 55 ГБ займет меньше суток. Но тогда вы не сказали нам, насколько дешевы ваши провайдеры. Если ваш новый провайдер предлагает доступ к оболочке, вы можете использовать wget или ftp чтобы скачать файлы со старого сервера.