Сколько хранится сохраненная копия яндекс
Перейти к содержимому

Сколько хранится сохраненная копия яндекс

  • автор:

Резервное копирование 1С в Yandex Cloud, включая БД и виртуальные машины

У многих компаний 1С работает в Yandex.Cloud — это удобно, снижает инфраструктурную нагрузку на собственные вычислительные мощности. Но у каждого решения есть проблемы, которые уменьшают эффективность, а соответственно лояльность и удовлетворённость пользователей. Когда речь идёт об 1С в Yandex.Cloud, жизнь сильно осложняет резервное копирование.

Яндекс предлагает не автоматизированный вариант — делать снапшоты виртуальных дисков, но сделать backup виртуальной машины как объекта Yandex Cloud на текущий момент не позволяет. Нам было важно автоматизировать этот процесс, снизить количество рутинных операций, создать возможность гибкой настройки прав. В дальнейшем мы планируем применять решение для себя, а затем у своих клиентов, масштабировать и настроить его под их конкретные задачи.

Уже сейчас у нас есть заказчики, у которых мы хостим 1С в YandexCloud, где упрощённый бекап остро необходим. Поэтому мы разработали решение, которое автоматизирует процессы, доступные в Yandex.Cloud в ручном режиме. Вендор анонсировал схожие функции, упрощающие жизнь при резервном копировании, но пока они не доступны пользователям. Между тем, спрос на них уже есть. Иными словами, основная цель проекта — дать пользователю удобное решение, которое исключает “танцы с бубном”, связанные с бэкапом 1С работающей в Yandex.Cloud, включая виртуальные машины. В настоящий момент мы готовим решение к запуску.

Проблемы

Настройка расписания

Для заказчиков и для нашей компании мы используем управляемые базы данных PostgreSQL. База управляется Yandex.Cloud. Проблема состоит в том, что инструмент резервного копирования, доступный из коробки как сервис, неудобен. Он ограничен в настройках, вплоть до того, что его нельзя отключить, а кроме времени проведения бэкапа, можно настроить только желаемый период хранения от 7 до 60 дней — и всё. Более того, бэкап происходит ежедневно. Нет гибкого расписания. Например, если нужно хранить 4 еженедельные копии и 12 ежемесячных, то реализовать такое стандартным средством бэкапа от вендора пока невозможно.

Неизбирательность восстановления

Для сервера баз данных в Yandex Cloud используем сервис Managed PostgreSQL — полуинтегрированное с YandexCloud решение, которое само разворачивает кластер, управляет его обновлениями, масштабированием, снижает затраты на администрирование, выступая в роли своеобразного сервиса. Когда речь идёт об 1С и использовании баз данных Postgre, то восстановление при помощи нативного инструментария Yandex.Cloud возможно только целым кластером.

Нет возможности поднять определённую базу, сохранённую в то или иное время. Восстанавливается весь ресурс, что по сути является огромным оверхедом. Получается, что если кластер заказчика велик и содержит много баз данных, например, более 60, то из-за одной базы приходится восстанавливать весь массив, чтобы потом эту одну базу из него вытягивать вручную.

Права доступа

Ещё одной проблемой стали настройки прав доступа. Сервисные аккаунты Yandex Cloud предоставляют своим пользователям достаточно широкие, и в некоторых случаях избыточные, права. В ситуациях, когда критически значим высокий уровень информационной безопасности, настройка прав доступа должна быть более гибкой и детальной. Иногда необходимо дать доступ к конкретным функциям, базе или виртуальной машине, чего в дефолтном варианте сделать нельзя.

Все решения предполагают установку агента на хостинг, где работает СУБД. Такой хост фактический “черный ящик” Во многом это также побудило к созданию более гибкого инструмента резервного копирования. Очевидным стал вопрос о гибкости инструмента и его способности более экономно и эффективно расходовать ресурсы.

Отсутствие уведомлений о значимых событиях

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

В сухом остатке

По сути, решение для бэкапа существует, оно даже снижает нагрузку на администрирование, но как и большинство других “коробочных” инструментов не способно удовлетворить конечных запросов многих наших заказчиков. Кроме того, коробочное решение от вендора пока не поддерживает нативной интеграции с “чистым” PostgreSQL.

Что мы уже сделали

Решение, которое мы предложили своим клиентам с 1С на Yandex Cloud, помогло справиться со следующими задачами:

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

Инструменты реализации и график бекапа

Решением стало использование штатных средств резервного копирования Postgre и организация их автоматического выполнения с использованием Jenkins. Применение этих средств открывает возможность гибко настроить расписание. Теперь можно устанавливать любое время и периодичность бекапа и гибко регулировать график в зависимости от изменения условий.

Уведомления

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

Хранение

Для хранения резервных копий мы решили использовать в Yandex Cloud S3 object storage, как в наиболее бюджетной защищенной распределенной файловой системе. Кроме того, мы реализовали возможность записывать логи ошибок и вести учет успешного запуска и создать ручной интерфейс управления резервными копиями, позволяющий их запускать и восстанавливать.

Виртуальные машины

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

Другие функции

В текущий момент уже реализована нотация и ротация логов, например в данный момент в нашей тестовой системе срок хранения копии и логов ограничен 20 днями. Также Jenkins позволяет работать с конфиденциальными данными, например, если они касаются пользователей системы. Эти данные хранятся в зашифрованном виде, доступ к ним легко ограничивается для большинства ролей в системе.

Настройка прав пользователей и их ограничений

В Jenkins были созданы различные уровни доступа в зависимости от роли пользователя. Сетка прав настраивается при помощи “матрицы пользователей”. Сейчас с её помощью можно делегировать права на одну конкретную виртуальную машину или базу данных, а также на конкретные действия.

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

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

Преимущества решения

Часть задач, которые стоят перед этим решением сервис инженер может выполнить вручную. Например написать что-то в консольной утилите Yandex Cloud. Но для этого нужны дополнительные знания и права на стороне облака. У Yandex Cloud есть специальный курс, который позволяет получить подготовку и сертифицироваться по их стандарту.

Нашим сертифицированным архитекторам, чтобы пройти этот курс и сдать экзамены, понадобилось до 3-х недель, у обычного сотрудника техподдержки с техническим образованием на такое обучение уходит от 2-х до 3-х месяцев. И мы говорим о минимальном пуле знаний для работы с Yandex Cloud, не архитектурных, достаточно поверхностных знаний, т.е. знакомство с функциями, инструментами и получение представления о том, как ими пользоваться. Инструмент, который предлагаем мы, специалист без технического образования может освоить за 3 недели непрерывного обучения. В практике был случай, когда для работы с ним учились люди с бэкграундом сейлз-менеджера.

Перспективы и масштабирование

Проект позволяет использовать его не только для 1С, но также для любых управляемых баз данных в Yandex Cloud. В следующей версии мы попробуем адаптировать решение для других систем. Существует возможность интеграции с service desk предприятия и мы также планируем реализовать его, чтобы ещё быстрее обрабатывать события. Мы обязательно напишем об этом на Хабре. Традиционно будем признательны за комментарии и вопросы об этом кейсе.

  • резервное копирование
  • 1c
  • yandex.cloud
  • 1С в Yandex.Cloud
  • облачные сервисы
  • системная интеграция

Что такое кэш поисковой системы? Зачем он нужен?

Когда робот поисковой системы (ПС) обходит сайт во время индексации, система автоматически сохраняет копию каждой посещенной страницы. Эти копии попадают в базу данных – кэш поисковой системы.

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

Особенности работы кэша поисковиков

  • Кэш и индекс – не одно и то же. В кэше хранятся копии веб-страниц, а в индексе – только текстовые фрагменты с ключевыми словами и URL страниц, которые проиндексировал робот.
  • В кэш не попадают динамические скрипты. Кэшированная страница содержит html-код текстового и статического контента. Видео, графика и блоки, написанные на JavaScript, Flash и Ajax не сохраняются в кэш. Но если поставить на них абсолютные ссылки, то эти блоки будут отображаться на кэшированной странице.
  • Кэш – одна копия страницы. В базе данных поисковой системы хранятся наиболее актуальные копии каждой страницы. При каждом переобходе роботом информация в кэше обновляется и перезаписывается, старые версии при этом удаляются.

Кэш поисковой системы позволяет:

  • увидеть сохраненную ранее копию страницы и ознакомиться с контентом, который был на ней в момент индексации;
  • проверить, какие внесенные изменения на сайте были проиндексированы, а какие – нет;
  • узнать, учитывает поисковая система ссылку на ресурс или нет;
  • восстановить удаленные данные;
  • оценить уникальность размещенного на странице текста;
  • определить точную дату индексации.

Кроме того, кэш помогает посмотреть содержимое сайта, который система считает потенциально опасным и запрещает открывать актуальную страницу.

Как часто поисковые системы обновляют кэш

В Яндексе актуализация (апдейт) сохраненной копии происходит 1-2 раза в неделю. Система проверяет текстовое наполнение и ссылки. Пересчет ТИЦ (тематического индекса цитирования) производится реже – 1 раз в 2 месяца.

В Google нет фиксированной периодичности обновлений кэша. Все зависит от робота – когда он посчитал нужным зайти на страницу, тогда кэш и обновится. Здесь наши специалисты по SEO оптимизации грустят вместе с вами.

Как посмотреть кэш поисковой системы

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

Так это выглядит в Яндексе:

Яндекс кэш

А так – в Google:

Гугл кэш

Иногда в выдаче не показывается ссылка на сохраненную копию. Например, как здесь:

Без сохраненной копии

Это означает, что вебмастер по какой-то причине не хочет открывать доступ к кэшу посторонним лицам. Поэтому прописал атрибут Robots: . После этого ссылка на кэш не отображается в результатах поисковой выдачи, но сама страница все равно индексируется поисковыми роботами, если это тоже не запрещено в файле robots.txt.

Зачем и как удалить страницу из кэша поисковой системы

В процессе работы SEO-специалисты сталкиваются с разными проблемами, одна из которых – копирование контента с их сайта. Из-за этого проседают позиции, и процесс продвижения ставится под вопрос. Если удается добиться, чтобы сайт «воров» перестал работать, страницы начинают отдавать ошибку 404, но продолжают оставаться в выдаче. В таком случае единственный способ решить проблему – удалить копии страниц из кэша.

Еще может произойти ситуация, когда на сайт попала нежелательная информация, которую оперативно удалили, но робот все же успел проиндексировать страницы, где она находилась.

Чтобы удалить кэшированные страницы из выдачи, нужно воспользоваться специальным инструментом – Google для веб-мастеров или Яндекс.Вебмастер . Для удаления страницы система может потребовать подтвердить права на владение сайтом.

Еще ответы по теме:

  • С какими CRM вы работаете?
  • Важна ли карта sitemap.xml?
  • Что такое семантическое ядро?

Сколько гугл хранит кеш несуществующих сайтов?

Народ, кто знает, если например сайт перестал существовать (неважно хостинг или домен не проплачен или другие причины, но вообщем 404), то сколько гугл будет хранить информацию об этом сайте? Не смог найти точной информации. По опыту каких то сайтов уже и через 2 недели нет, а каике то месяц+ держатся. От чего зависит?

На сайте с 03.04.2012

8 июня 2013, 21:19

От того, как быстро переиндексируется страница. Например страницы, имеющие много обратных ссылок — индексируются чаще.

Настройка резервного копирования на Яндекс.Диск

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

Используйте инструкцию для примера настройки резервного копирования на других хранилищах .

Перейдите в панель управления сервером и переключитесь в расширенные настройки srv-admin по инструкции.

На панели меню слева перейдите в Инструменты (1) → Резервные копии (2).

Если появилось сообщение «Недостаточно данных», нажмите на кнопку «Оk» для настройки резервного хранилища. Вы перейдете к настройкам резервных копий.

В блоке «Основное» галочка включения резервных копий (1) будет стоять автоматически, не убирайте ее. Выберите тип хранилища «Яндекс. Диск» (2) и при необходимости задайте пароль для доступа к резервной копии.

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

В блоке «Яндекс. Диск» введите код доступа (4), сформированный в аккаунте Яндекс.Диска. Вы можете перейти по ссылке в форме создания резервной копии, после чего поле будет заполнено автоматически. Укажите каталог на Яндекс.Диске, в котором будут храниться резервные копии, в строке «Путь до бэкапов» (5). Данное поле можно оставить пустым, в этом случае резервные копии будут сохраняться в корневой каталог.

В блоке «Ограничения» можно указать лимит дискового пространства для резервных копий (6), задать необходимое количество полных (7) и ежедневных резервных копий (8) и исключить файлы для бэкапа (9) — например, временные файлы, лог-файлы и кэш.

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

Для «1С-Битрикс: Управление сайтом» мы рекомендуем исключить следующие файлы:

  • data/logs/*.log
  • data/mod-tmp
  • data/bin-tmp
  • data/www/*/bitrix/backup/*
  • data/www/*/bitrix/cache/*
  • data/www/*/upload/tmp/*
  • data/www/*/upload/resize_cache/*
  • data/www/*/bitrix/managed_cache/*
  • data/www/*/bitrix/stack_cache/*
  • data/www/*/bitrix/local_cache/*
  • data/www/*/bitrix/tmp/*
  • data/www/*/bitrix_personal/cache/*
  • data/www/*/bitrix_personal/managed_cache/*
  • data/www/*/bitrix_personal/stack_cache/*
  • data/logs/*.log-*.gz

Нажмите кнопку «Ok». Дождитесь создания первой резервной копии и проверьте, что настройки проведены верно.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *