Home » Полезные советы » Как правильно делать бэкапы и следить за ними

Как правильно делать бэкапы и следить за ними

Написать данную заметку меня побудила ситуация вокруг хостера ihor.ru, с которым я сотрудничаю уже лет 5. Еще летом у них начались какие-то проблемы, а сейчас они вылились в открытое противостояние собственников. В чем там конкретно проблемы, я не знаю. Есть 2 противоборствующие стороны, у каждой из которых свой канал в телеграме - @ihor_hosting и @marosnet. Там есть подробности. Они делят между собой компанию. А на пользователях это сказывается тем, что постоянно что-то не работает. То связи нет, то сервера выключаются, тех. поддержка не работает вообще, платежи не принимают. В общем, жуть.

Углубленный онлайн-курс по MikroTik

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

Введение

За столько лет я оброс всевозможными сервисами и услугами этого провайдера. Многим его советовал. Я туда десятки (может сотни) клиентов привел, в том числе через этот сайт. Долгое время у меня висела его реклама, так как я сам пользовался его услугами.

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

Бэкапы нужно обязательно разворачивать и проверять

Мало просто настраивать мониторинг бэкапов и оповещения. Я регулярно вручную проверяю все бэкапы. Да, это очень хлопотно, но другого выхода я не вижу. Если я этого не делаю, то перестаю спокойно спать.

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

Особенно важно проверять дампы баз. Физическое наличие файла с дампом не означает, что вы без проблем его развернете. Надо проверять данные, заливая дамп в базу. Это единственный способ убедиться, что данные реально есть и они актуальны.

Backup должен быть в другом дата центре у другого юр. лица

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

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

Как правильно делать бэкап

С самого сервера с данными не должно быть доступа к бэкапам

Очень важное правило - бэкап сервер сам подключается к целевым машинам и забирает информацию. Это добавляет сложности к сервисам, с помощью которых вы будете делать бэкап. Не получится просто купить где-то место в s3, nfs, smb и класть туда бэкапы с серверов. Нужен активный агент, который будет ходить по целевым серверам и собирать данные сам. Зачем такие сложности?

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

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

Большой диск на vps для бэкапа

Бэкапы должны быть максимально полные и подробные

Что я имею ввиду? Зачастую бэкапы делаются с расчетом на то, что что-то изменится на проде и нам надо будет развернуть бэкап и посмотреть на него. Бэкапятся, к примеру, исходники сайта и база к нему. Когда все в порядке и ты просто проверяешь бэкап, сложностей не возникает, потому что если ты даже что-то забыл, то залез на prod и посмотрел.

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

Отсюда правило - бэкапьте не только данные, но и все окружение из расчета на то, что вы разом можете потерять prod навсегда. Я много раз об это спотыкался и по второму разу настраивал все то, что у же было настроено ранее. Сейчас все конфиги проектов храню в своем gitlab. Из того, что часто забывают - ssl/tls сертификаты. А потом их приходится торопливо искать.

Backup виртуальных машин

Я знаю, что многие бэкапят целиком виртуалки. Я редко делаю такие бэкапы, так как с ними трудно работать. Получаются файлы огромных размеров. Если гоняете их через интернет, то они могут биться по дороге, либо в момент создания. У меня были ситуации, когда нужно было развернуть бэкап виртуальной машины на 200 Гб. Я несколько часов его заливал через интернет, а потом он не разворачивался из-за ошибки чтения. Пробовал несколько раз и каждый раз неудачно. Очень повезло, что заметил это в момент тестового разворачивания, а не тогда, когда была бы реальная авария. Это был бы полный провал, так как это был единственный экземпляр архивной копии.

Если нужно делать бэкап виртуальной машины, то я делаю небольшой системный диск (30-50 Гб) и бэкаплю только его. Данные кладу на отдельный виртуальный диск и забираю их в сыром в виде с помощью rsync или аналогов. С его помощью легко и быстро делать инкрементные бэкапы, а потом их разворачивать. Нет проблем с докачкой и битыми файлами. Даже если что-то и повреждено, то 1 файл из десятков тысяч погоды не сделает. Можно пережить.

Проверяйте скорость восстановления данных

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

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

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

У меня были ситуации, когда сервер с бэкапами живет на гигабитном порту с "безлимитным трафиком". А когда ты скачаешь 10-15 гигабайт, включается ограничение полосы до 100 мегабит. Возможно будет и дальнейшее урезание. С такими лимитами нет смысла платить за гигабит. Это просто маркетинговая уловка.

В общем, не доверяйте данным из описания тарифа, проверяйте их сами, чтобы потом не было сюрприза.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Это мои основные правила создания бэкапов. А как вы делаете бэкапы? Поделитесь своим опытом. Возможно, я что-то забываю или упускаю.

Онлайн-курс по устройству компьютерных сетей.

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Помогла статья? Подписывайся на telegram канал автора

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

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

50 комментариев

  1. Александр

    Большое спасибо за Ваш труд!
    Посоветуйте пожалуйста vds/vps для оффсайт бэкапов.

  2. Из практического интереса... как вы делаете бекап виндовых машин? я не нашел способа лучше чем бекап всей ВМ, но как вы правильно заметили это 200Гб и на другой сервер через интернет тащить это проблема, а бекапить 1 диск никак - я миллион раз говорил заказчику чтобы дрессировал пользователей, я даже папки пользовательские перенес на диск Д, они всё равно умудряются почти все записывать на диск Ц

    • От ситуации зависит. Я обычно стандартно делал диск C: под систему на 100Гб, а остальные диски под задачи. Системный не бэкапил. Но если сильно надо было, то конкретно систему архивировал ее штатным средством бэкапов.

      А сами данные забирал по-разному. Чаще всего либо монтировал виндовую шару к linux серверу и забирал через локальный rsync на линуксе. Но это медленно и не так удобно. Либо последнее время настраивал rsync на самом windows сервере и забирал через него.

      Где-то использовал Veeam для бэкапа нужных дисков виртуалки. Если вся инфраструктуру находится в локальной сети, в том числе и бэкапы, то можно и полный бэкап виртуалки делать, либо тем же veeam инкрементные копии.

      В общем, всегда все по-разному, в зависимости от ситуации.

  3. Андрей

    Скорее бы провайдеры облачного хранения сделали у себя в личных кабинетах возможность считывать MD5. Тогда было бы проще. На локальном сервере посмотрел хеш сумму. И в облаке. И если все совпало тогда не надо тестировать.

    Но если согласно вашей статье где-то по пути через интернет побился файл архивной копии вы после отправки файла в облако и после загрузки не считывали контрольную сумму у резервной копии или проверка контрольной суммы бесполезное занятие ?

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

  4. Андрей

    Здравствуйте Владимир.
    Очень интересная и поучительная статья.

    Вы храните бэкапы в облаке ?

    P.S.
    Интересно узнать куда надежнее в какое "облако" копировать данные в пределах РФ.

  5. Сергей

    Добрый день.
    У нас в компании используется кластер из Hyper-V.
    На нем развернут ряд ВМ, как на линуксе, так и на винде.
    В основном все бэкапим с помощью Акронис Инфозащита, версия именно для виртуальной среды.
    Настроены различные планы обслуживания.
    В целом устраивает.
    Можно развернуть из образа новую ВМ, можно достать отдельные файлы из бэкапа.
    Но есть один нюанс.
    У нас присутствует одна большая ВМ - файловый сервер на win2012r2.
    Объем - почти 10ТБ, и продолжает расти.
    Полный бэкап этого чудовища делается больше суток. Поэтому делается не часто. Каждый день делается добавочный бэкап.
    Вот думаю, как бы оптимизировать это.
    Либо что-то менять в организации файлового сервера.
    Либо менять механизм резервного копирования.
    Настраивать синхронизацию? К примеру с помощью Syncthing? Не пользовался им еще.
    По хорошему надо бы еще сохранять права безопасности Ntfs.
    Ну и нужно хранение разностных бэкапов.
    Может есть какие-то готовые рецепты?

    • На больших объемам и сотнях тысяч файлов по моему опыту лучше всего ведет себя rsync. Его можно поставить и на windows server. Посмотрите в этом направлении. Для синхронизации больших файловых дисков я ничего лучше не встречал.

      Права ntfs желательно тоже сохранять. Я делал скриптами на powershell. Но на больших объемах это тоже занимает много времени.

  6. Андрей

    Здравствуйте Владимир.

    Спасибо вам за интересную статью.

    С помощью какого решения вы создаете резервную копию asterisk с возможностью восстановления на другой аппаратной платформе?

    Например:
    боевой сервер asterisk на HP сервере.

    резерв разворачивать на железе уровня desktop.

    каждый вечер после 18:00 нужен активный резерв готовый в работу.

    P.S.
    Я понимаю что можно собирать Linux кластера но если не сразу появляется такая возможность. Как быть с оперативно готовой боевой копией.

    • Если нужен горячий резерв, то нужно бэкаить виртуальную машину с asterisk и разворачивать ее на подменном сервере. Если просто нужен бэкап, то я делаю архив директории /etc/asterisk. Там есть все, что нужно для восстановления работы сервера телефонии. Ценность на нем представляют только сами настройки.

      • Андрей

        дело в том что мне надо с виртуальной ESXi развернуть копию на обычном подходящем по мощности десктоп (железе)компьютере. Так как нет второго сервера с ESXi.

        Сомневаюсь что если я выключу на ночь ВМ и сделаю копию например через Acronis True Image в образ и разверну образ на другом железе и все заведется.

        • Может и заведется. Надо пробовать. Правда я не пойму, зачем лишние действия, если на этот же десктопный компьютер можно поставить бесплатный esxi и без проблем развернуть виртуалку из бэкапа. Не нужен будет Acronis.

  7. Владимир здравствуйте!
    Не так давно работаю в сфере IT, и для меня ваш ресурс просто находка, практически поселился здесь.
    Крайне благодарен вам за ваш труд и доходчивое разъяснение материалов в статьях.
    Ежедневно мониторю появление здесь новых статей.

    И по теме данной статьи,

    Больше всего заинтересовал момент:
    Цитирую "Очень важное правило — бэкап сервер сам подключается к целевым машинам и забирает информацию. Это добавляет сложности к сервисам, с помощью которых вы будете делать бэкап."

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

  8. Всё правильно и познавательно написано. Для себя придумал следующее - с сервера резервного копирования второй сервер на Linux по cron-у забирает резервные копии и отключается - дополнительная защита от шифровальщиков и прочей нечисти.

    • А включается потом как? Как это реализовано полностью?

      • Сначала делаются резервные копии на Windows-сервер, потом Linux-сервер по cron монтирует нужные папки, копирует к себе резервные копии и отключается, кроме того - по cron удаляются старые резервные копии, фактически организовано дополнительное хранение резервных копий, про которое основная Windows-система не знает. Реализовано всё после атаки шифровальщика, которая особого вреда не нанесла, но подумать заставила.

        • А включается бэкап сервер потом как? Я точно так же забираю бэкапы с windows серверов.

          • Оба бэкап-сервера постоянно включены, если надо что-то забрать - можно монтировать папку или копировать через WinSCP.

            • Я что-то затупил. Думал серваки с бэкапами физически выключаются. У меня были идеи так сделать, но посчитал, что это уже слишком :)

              • Linux-сервер как раз и нужен как невидимое из Windows хранилище, подключаемое только на время копирования данных.
                Кто-то писал, что на сервере был внешний USB-диск, который скриптом подключался-отключался, но мне такой вариант не понравился.

              • Зачем их физически отключать, если можно iptables закрывать порты и открывать так же ж

                • Можно, конечно, но выключение единственная 100% защита от всех сетевых угроз :)

  9. Автор, как вы относитесь к Veeam Backup? По моему ничего лучшего еще не придумали.
    Он не только безопасно бекапит по сети, проверяя целостность, но еще и может проводить дедупликацию данных.

    Работает с агентами, которые ставятся на машины, может бекапить всю систему, даже во время работы активной работы.

    Был ли у вас опыт работы с этим продуктом?

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

  10. У меня бэкапы льются непосредственно с самих тачек (подавляющее большинство Linux) на целевой сервер (smb), но учетка под которой монтируется шара имеет доступ только к определенной папке. После завершения копирования всех бэкапов, на стороне сервера скрипт их перемещает в другое расположение, куда упомянутая выше учетная запись доступа не имеет. Копирование происходит утилитой rsync, что гарантирует целостность файлов.
    Две архива БД разворачиваются и проверяются автоматом каждый день. Остальные периодически вручную.
    Для zabbix настроено низкоуровневое обнаружение новых бэкапов, проверка их актуальности, плюс созданы триггеры оповещающие об отсутствии данных в течение определенное промежутка времени (что я считаю нужно делать на всех критически важных данных).

    • Спасибо, любопытное дополнение. Я как-то не догадался перемещать архивы в другое место в рамках одного сервера. Это где-то может быть неплохим решением.

      Как реализовано обнаружение бэкапов? Интересует просто принцип, без подробностей. Какой-то скрипт, который список директорий делает, а потом передает в zabbix для последующей работы или что-то еще? У меня есть наработки в этой области, но они не универсальные и не гибкие. Каждый раз приходится вручную редактировать под конкретную ситуацию. Что-то универсальное не получается придумать.

      • Принцип простой, получение списка папок через Powershell методом Get-ChildItem. Конечно, ни о какой универсальности речи не идет, у меня пара тройка серверов с бэкапами, все они прописаны в одном скрипте, который дергает Zabbix периодически и добавляет новые в мониторинг, если таковые появились, плюс почти у всех бэкапов стандартная схема ротации: неделя - месяц - квартал - год.
        Актуальность проверяется по свойству lastwritetime

  11. Владислав

    Использую Handy Backup (https://www.handybackup.ru/hyper-v-backup.shtml) для всех машин в институте, и не парюсь. Изнутри машины не делаю бэкап в принципе, и другим не рекомендую: первый сбой, вирус или рэнсомвэр в какой-нибудь тестовой конфигурации — и до свидания, данные! (Мы так один рад потеряли машину, на которой было развёрнуто целое виртуальное издательство, визгу от научных сотрудников было до небес!)

    • Бэкапы изнутри настоятельно рекомендую делать. Причем они должны быть с версионированием, чтобы была возможность откатиться на прошлую версию файла, тогда никакие шифровальщики не страшны. Бэкап виртуалки это один большой файл. С ним могут возникнуть проблемы. Он тупо может не прочитаться или не развернуться. Я с этим сталкивался лично, так что рекомендую не надеяться всецело на него.

  12. В догонку тем кто пользует Vmware ESXi Free.
    В последнем релизе отключена возможность использования стронних продуктов для бэкапа ВМ (
    Не верите? Читаем http://www.virtualizationhowto.com/2019/11/esxi-6-7-free-limitations-and-features/

    >>No backups from third-party backup solutions<>Maximum of 8 vCPUs for VMs running on ESXi 6.7 free<<

    Всем пользователям Veeam, Vembu etc - большой "привет". И еще один повод перейти на Open source.
    Proxmox, Opennebula etc в помощь.

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

      • Да, с инкрементными бэкапами из коробки пока не очень. Есть костыль в виде отдельного проекта для этого дела. Насчет "функционала" Вима. Вим - это отдельный проект, для к-го нужна отдельная машина. Ни у Гипер-В, ни у Вмваре Фри нет и никогда не будет готовой системы бэкапов с ротацией. У PVE она есть. Даром. Плюс скоро ZSTD-сжатие завезут.

        >>Только на уровне хранилища, но для малого и среднего бизнеса это не вариант. У них нет промышленных хранилок.
        Для малого и среднего бизнеса хватит отдельного PC (или неск-ко) + xigmanas на флешке + zfs raidZ2\3
        С головой хватит.

  13. Добрый.

    Для ZFS есть:
    http://www.znapzend.org
    или руками gist.github.com/sammy8806/b87021bbca83c9aff56c1c22941dcbc0

  14. Алексей

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

    • Это хороший вариант, если есть возможность автоматизировать. Какие средства для этого используете?

      Если есть veeam, то вопросов нет. Сам там настраиваю регулярную репликацию с проверками. А вот если вима нет, то все усложняется. Чаще всего восстанавливаю скриптами в полуавтоматическом режиме.

      • Алексей

        Стандартные линукс-утилиты, типа того же rsynс. Плюс некоторые вещи реализованы плейбуками для Ансибл (удобно что и порт проверит и так далее. Что не так - откат и матюги). Главное - не усложнять. :)

  15. Аноним

    Спасибо. Было позновательно.

  16. Сергей

    "А с этого хранилища второй бэкап-сервер сам забирает данные."
    Если не секрет, то какие есть инструменты, чтобы так делали?

    • Способов может быть очень много. Все зависит от используемых средств и систем. Если оба сервера с бэкапами полноценные серверы с ssh, то один сервер с другого может забирать данные по scp, rsync, используя ssh авторизацию. Можно расшарить данные бэкапов по nfs или smb и настроить ограничения по ip, разрешая подключаться только со второго сервера. В общем, зависит от возможностей. Так или иначе это везде реализуется, только по разному.

  17. Больная тема вообще) сколько раз у меня ломали сайты, сколько раз хостеры с ума сходили... без Backup вообще никуда и никогда, делается на внешки раз в 24 часа. И проверять как минимум раз в неделю, чтобы не криво и четко по времени

  18. По поводу того, что бэкапы нужно обязательно проверять, подтверждаю на 100%. Был опыт.

  19. Кстати, статью я опубликовал и через некоторое время ihor умер окончательно. Я весь день все переносил и восстанавливал из бэкапов. Удалось восстановить все, не потерял ничего. Чего не скажешь о многих других людях.
    ----------------------------------------------------
    1
    --------------------------

    2
    -----------------------------------------------------

    3
    -----------------------------------------------------

  20. Алексей

    Согласен почти со всеми пунктами, только одно попало под сомнение.

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

    И тут же добавляете:
    " Иногда я делаю 2 разных бэкапа — в первое хранилище целевой сервер кладет данные самостоятельно. А с этого хранилища второй бэкап-сервер сам забирает данные."

    Зачем настраивать backup-конфиги на самом целевом сервере, т. е. на том сервере, с которого backup-ться эти самые данные? Если на целевой сервер попадет вирус или хакер, то он почистит или зашифрует везде данные, включая данные на backup-сервере путем просмотра этих backup-конфигов. И тогда "А с этого хранилища второй бэкап-сервер сам забирает данные." будет бессмысленным действием уже, т.к. данные уже будут зашифрованными на первом backup-сервере.

    Или я что-то понял неправильно здесь?

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

      Бэкап же делается не в лоб, простым сравнением и перезаписью файлов. Хранится история изменений, чтобы можно было откатиться на какой-то предыдущий день. Это уже вопрос конкретной реализации.

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

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

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar