Снимок сайта со временем

Question

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

Есть ли хорошие решения для решения этого запроса?

Answer 1

Source Control должен быть в состоянии решить ваш запрос в доме. Надписывайте вещи соответствующим образом и используйте внутренний сервер для развертывания этой метки, и у вас не должно возникнуть проблем. Если у вас есть инструмент автоматического развертывания, и вы правильно выбираете метки, то будет относительно просто написать приложение, которое проверит ваш источник на метке X и развернет его, только если пользователь введет метку. Теперь, если у ваших ярлыков есть что-то вроде даты, им просто нужно будет ввести дату в правильном формате и ждать 5 минут для развертывания.

Answer 2

Как говорит Грант, вы можете комбинировать wget с контролем версий для экономии места. На самом деле я пытаюсь написать сценарий, чтобы сделать это для моего обычного просмотра, так как я не доверяю интернет-архиву или веб-сайту, которые существуют бесконечно (и они не очень доступны для поиска).

Сценарий будет выглядеть примерно так: перейдите в каталог; вызовите правильную команду wget --mirror или любую другую; запустите darcs add $(find .), чтобы проверить в хранилище любые новые файлы; тогда darcs record --all.

Wget должен перезаписывать любые измененные файлы обновленной версией; darcs add запишет все новые файлы / каталоги; Даркс запись сохранит изменения.

Чтобы получить представление на дату X, вы просто извлекаете из своего репо все патчи до даты X.

Вы не храните неограниченное количество дубликатов, потому что DVCS не сохраняют историю, если нет фактических изменений в содержимом файла. Вы получите «мусор» в том смысле, что при переходе на страницы больше не требуется CSS, JS или ранее загруженные изображения, но вы можете просто периодически удалять все и записывать это как патч, а следующий вызов wget будет только извлекать необходим для последней версии веб-страницы. (И вы все еще можете выполнять полнотекстовый поиск, просто теперь вы ищите историю, а не файлы на диске.)

(Если загружаются большие медиа-файлы, вы можете добавить что-то вроде rm $(find . -size +2M), чтобы удалить их до того, как они получат darcs add ed.)

РЕДАКТИРОВАТЬ: В итоге я не стал беспокоиться о явном контроле версий, но позволил wget создавать дубликаты и время от времени засеивать их fdupes. См http://www.gwern.net/Archiving%20URLs

Answer 3

Мое предложение было бы просто запускать wget на сайте каждую ночь и сохранять его на archive.yourdomain.com. Добавьте элемент управления на каждую страницу для пользователей с соответствующими разрешениями, которые передают URL-адрес текущей страницы средству выбора даты. После того, как выбрана дата загрузки archive.yourdomain.com/YYYYMMDD/original_url.

Разрешение пользователям просматривать весь сайт без битых ссылок на archive.yourdomain.com может потребовать переписывания URL-адреса или копирования заархивированной копии сайта из какого-либо репозитория в корень archive.yourdomain.com. Для экономии места на диске это может быть лучшим вариантом. Сохраните wget копий в архиве, затем извлеките дату, которую запрашивает пользователь. С этим связаны некоторые проблемы, например, как вы справляетесь с несколькими пользователями, которые хотят одновременно просматривать несколько архивных страниц с разных дат и т. Д.

Я бы предположил, что запуск wget над вашим сайтом каждую ночь лучше, чем извлечение его из системы контроля версий, поскольку вы получите страницу, как она была показана посетителям WWW, с любым динамически отображаемым контентом, ошибками, упущениями случайно повернутые объявления и т. д.

РЕДАКТИРОВАТЬ: Вы можете сохранить вывод wget в управлении исходным кодом, я не уверен, что это купит вас за то, что вы заархивировали его в файловой системе где-то за пределами управления исходным кодом. Также обратите внимание, что этот план будет со временем занимать большие объемы дискового пространства, если принять сайт любого размера.

Answer 4

Аналогично тому, что предлагали другие (при условии динамического веб-сайта), я использовал бы кэширование вывода для генерации кода веб-страницы, а затем использовал бы Subversion для отслеживания изменений.

Использование машины WayBack, вероятно, является лишь последним средством, например, если человек запрашивает просмотр веб-страницы до того, как вы настроите эту систему. Нельзя полагаться на то, что WayBack Machine содержит все, что нужно.

Answer 5

Вы смотрели на машину обратного хода на archive.org?

?

http://www.archive.org/web/web.php

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

Answer 6

взгляните на машину обратного хода она не идеальна, но есть еще несколько смущающих старых сайтов, над которыми я работал:)

Answer 7

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

Это, вероятно, не сработает, если ваш контент находится в базе данных, но если это просто HTML-страницы, которые вы изменяете со временем, тогда SCM будет нормальным способом сделать это. WayBackMachine, о котором все упоминают, великолепен, но это решение в большей степени зависит от конкретной компании и позволяет фиксировать нюансы изменений во времени. Вы не можете контролировать WayBackMachine (насколько мне известно).

В Subversion вы можете настроить хуки и автоматизировать это. На самом деле, это может даже работать, если вы используете контент из базы данных ...

Answer 8

Может помочь WayBackMachine .