У моей весьма недалекой и доверчивой родственницы в годах по такой же схеме на днях угнали телегу. Попросила меня помочь вернуть ей доступ. Так вот, восстановление акка в телеграме - это просто верх идиотизма. При попытке авторизоваться заново код авторизации приходит... в угнанный телеграм, смс на телефон как опция в принципе отсутствует (вроде как она есть на премиум-аккаунтах, но не уверен). Почту для восстановления доступа мошейники меняют на свою. В факе телеграма указано, что для восстановления нужно заменить сим-карту на номере телефона в офисе оператора сотовой связи и авторизоваться снова, но после этого на введенные коды приходит ответ "Not allowed". В итоге доступ всеми правдами и неправдами восстановили, но это был лютый геморрой. Крайне странно, что в таком удобном и продуманном сервисе таким идиотским образом реализован этот функционал.
На форуме мне ответил один из разрабов Restic. Размер чанка определяется динамически от 512 КБ до 8 МБ, но стремится к примерно 1 МБ, и вручную задавать это значение не получится. Кроме того, я задал вопрос по поводу алгоритма компрессии - там zstd, и поменять его нельзя. Zstd - это неплохо, но удивляет прибитие гвоздями подобных вещей без уровня абстракции.
О, я как раз сейчас Restic ковыряю, так как он нативно работает и на винде, и на никсах, да и Go ощутимо быстрее питона, на котором написан Borg, предложенный выше. Скормил ему папку с нативными полными бэкапами от самой СУБД за три дня (общий размер 36 ГБ), указал максимальное сжатие, в итоге Restic'овская репа занимает 5 ГБ, что очень неплохо. Но это родительский бэкап, будем смотреть, как он с инкрементами будет справляться. Такую проблему, как у вас, я и предвидел, поэтому сейчас выясняю на тамошнем форуме и в доках, как уменьшить размер чанка до минимума (теоретически должно помочь, если при этом данные не сдвигаются внутри файла). Как-то в итоге удалось решить проблему, или оставили, как есть?
О, спасибо, если это так, то может сработать. Сейчас буду изучать и тестировать. Главное, чтобы СУБД не слишком сильно меняла расположение данных в файле при работе (переиндексация, реструктуризация, оптимизация etc, кто его знает, что она там творит под капотом). Полагаю, система разбиения данных в Borg примерно такая же, как в BitTorrent?
Менять конфиг системы и добавлять дополнительные блочные устройства (даже виртуальные) у меня нет возможности, так что мимо. Проблема еще в том, что в окружении - мультисистемный зоопарк и таких файлов баз с необходимостью бэкапа несколько, каждый на разных машинах, поэтому искал кроссплатформенное решение. При этом я вручную пробовал тупо диффать два варианта файла (условно, вариант файла в понедельник и измененный вариант в пятницу) rsync'ом и сжимать дифф (операция восстановления в этом случае - разархивация диффа и patch понедельничного файла этим диффом от пятничного), и оно работало - размер сжатого диффа укладывался в приемлемые 100 МБ при размере несжатой базы в 12 ГБ, но решил не велосипедничать со скриптами и поискать что-то готовое, так как опасаюсь при их написании не учесть все corner case'ы и запороть восстановление базы при такой необходимости. Что ж, видимо, всё-таки придется писать свой скрипт, благо, WSL на виндовых машинах есть.
Господа, подскажите, пожалуйста, можно ли организовать бэкапы таким образом, чтобы основной файл бэкапа в сжатом виде создавался, условно, раз в месяц, а изменения - в качестве сжатых же бинарных диффов друг от друга по цепочке с проверкой чексумм на каждом этапе (примерно как происходит внутри git, но в бинарном и сжатом виде)? А то мне нужно организовать ротируемые ежедневные бэкапы файла большой однофайловой базы, он хорошо сжимается, ежедневные изменения небольшие, но трафик для отправки бэкапов в облако (кстати, тоже пользуюсь Mega) крайне ограничен.
Может быть. Но что-то полноценной userspace-имплементации VPN с WG в своей основе, кроме собственных клиентов VPN-сервисов (Mullvad, NordVPN, Proton и т.д.), я и не припомню. А жаль.
Настроил WG в качестве резервного VPN-канала в дополнение к OpenVPN еще в 2019 году. Честно говоря, особых преимуществ по сравнению с OpenVPN не увидел - имхо, WG получил гораздо больше хайпа, чем он заслуживает; скорее всего, по причине "одобрямса" со стороны Торвальдса и других разработчиков Linux, отметивших элегантность решения, чистоту кода и нераздутый функционал (что вполне естественно, учитывая возраст WG).
Однако что тогда, что сейчас, WG, как по мне, остается слишком примитивным (я имею ввиду, из коробки, без обвязки сторонним или самописным ПО). Если сравнивать с тем же bloated OpenVPN, я отметил для себя как минимум такие недостатки:
Невозможность запушить конфиг от сервера к клиенту (в WG типа нет парадигмы "клиент - сервер", а все члены VPN демократично являются равнозначными "пирами"), что особенно критично, если клиент удаленный, и WG является единственным каналом связи с ним.
Одна из самых критичных для меня проблем - при изменении IP эндпойнта "серверного" пира "клиентский" пир не переподлючается к новому адресу (а для меня это критично, так как сервер находится за серым динамическим IP и dyndns-сервисом), и вообще ни коим образом не пытается обеспечить хоть какую-то гарантию связности сети (к слову, OpenVPN отрабатывает этот момент как боженька). При этом в Линуксе хотя бы есть стандартный скрипт wg_reresolve-dns.sh (который у меня почему-то срабатывает через раз, и из-за этого я потерял доступ к нескольким удаленным машинам, к которым не имею физического доступа), а в винде - добро пожаловать в мир самописных скриптов на Powershell. Причем на гитхабе уже несколько лет висит PR с решением для виндового клиента, но воз и ныне там.
Лютое неудобство управления парком клиентов, если ты не админ локалхоста, а хотя бы обладаешь десятком удаленных в разных местах машин. У пиров нет "человеческих" имен, все соединения маркируются только публичными ключами, поэтому приходится либо вести реестр соответствия ключей клиентам, либо назначать т.н. vanity keys, когда программа перебором подбирает публичный ключ таким образом, чтобы первые n символов ключа соответствовали понятному админу референсу (sErv..., cliEnT1...). Перебор больше четырех символов case-sensitive такого референса не на игровых машинах с GPU - это больно. Плюс я так и не понял, как настроить логирование подключений - думаю, его просто нет, а это очень печально.
Спорный момент, но всё же: отстутствует сжатие VPN-трафика. Да, я в курсе, что это небезопасно, что это можно организовать на другом уровне OSI, но всё же. OpenVPN на одном из моих дохлых каналов работает в несколько раз быстрее WG именно из-за сжатия трафика.
В общем, мое мнение: это решение пока не доросло до использования в сириуз бизнес в своем vanillla-виде. Слишком мало функционала в угоду компактности и элегантности кодовой базы.
У моей весьма недалекой и доверчивой родственницы в годах по такой же схеме на днях угнали телегу. Попросила меня помочь вернуть ей доступ. Так вот, восстановление акка в телеграме - это просто верх идиотизма. При попытке авторизоваться заново код авторизации приходит... в угнанный телеграм, смс на телефон как опция в принципе отсутствует (вроде как она есть на премиум-аккаунтах, но не уверен). Почту для восстановления доступа мошейники меняют на свою. В факе телеграма указано, что для восстановления нужно заменить сим-карту на номере телефона в офисе оператора сотовой связи и авторизоваться снова, но после этого на введенные коды приходит ответ "Not allowed". В итоге доступ всеми правдами и неправдами восстановили, но это был лютый геморрой. Крайне странно, что в таком удобном и продуманном сервисе таким идиотским образом реализован этот функционал.
На форуме мне ответил один из разрабов Restic. Размер чанка определяется динамически от 512 КБ до 8 МБ, но стремится к примерно 1 МБ, и вручную задавать это значение не получится. Кроме того, я задал вопрос по поводу алгоритма компрессии - там zstd, и поменять его нельзя. Zstd - это неплохо, но удивляет прибитие гвоздями подобных вещей без уровня абстракции.
О, я как раз сейчас Restic ковыряю, так как он нативно работает и на винде, и на никсах, да и Go ощутимо быстрее питона, на котором написан Borg, предложенный выше. Скормил ему папку с нативными полными бэкапами от самой СУБД за три дня (общий размер 36 ГБ), указал максимальное сжатие, в итоге Restic'овская репа занимает 5 ГБ, что очень неплохо. Но это родительский бэкап, будем смотреть, как он с инкрементами будет справляться. Такую проблему, как у вас, я и предвидел, поэтому сейчас выясняю на тамошнем форуме и в доках, как уменьшить размер чанка до минимума (теоретически должно помочь, если при этом данные не сдвигаются внутри файла). Как-то в итоге удалось решить проблему, или оставили, как есть?
О, спасибо, если это так, то может сработать. Сейчас буду изучать и тестировать. Главное, чтобы СУБД не слишком сильно меняла расположение данных в файле при работе (переиндексация, реструктуризация, оптимизация etc, кто его знает, что она там творит под капотом). Полагаю, система разбиения данных в Borg примерно такая же, как в BitTorrent?
Менять конфиг системы и добавлять дополнительные блочные устройства (даже виртуальные) у меня нет возможности, так что мимо. Проблема еще в том, что в окружении - мультисистемный зоопарк и таких файлов баз с необходимостью бэкапа несколько, каждый на разных машинах, поэтому искал кроссплатформенное решение. При этом я вручную пробовал тупо диффать два варианта файла (условно, вариант файла в понедельник и измененный вариант в пятницу) rsync'ом и сжимать дифф (операция восстановления в этом случае - разархивация диффа и patch понедельничного файла этим диффом от пятничного), и оно работало - размер сжатого диффа укладывался в приемлемые 100 МБ при размере несжатой базы в 12 ГБ, но решил не велосипедничать со скриптами и поискать что-то готовое, так как опасаюсь при их написании не учесть все corner case'ы и запороть восстановление базы при такой необходимости. Что ж, видимо, всё-таки придется писать свой скрипт, благо, WSL на виндовых машинах есть.
Спасибо, посмотрю. А в open source решениях что-нибудь подобное есть?
Господа, подскажите, пожалуйста, можно ли организовать бэкапы таким образом, чтобы основной файл бэкапа в сжатом виде создавался, условно, раз в месяц, а изменения - в качестве сжатых же бинарных диффов друг от друга по цепочке с проверкой чексумм на каждом этапе (примерно как происходит внутри git, но в бинарном и сжатом виде)? А то мне нужно организовать ротируемые ежедневные бэкапы файла большой однофайловой базы, он хорошо сжимается, ежедневные изменения небольшие, но трафик для отправки бэкапов в облако (кстати, тоже пользуюсь Mega) крайне ограничен.
Может быть. Но что-то полноценной userspace-имплементации VPN с WG в своей основе, кроме собственных клиентов VPN-сервисов (Mullvad, NordVPN, Proton и т.д.), я и не припомню. А жаль.
Настроил WG в качестве резервного VPN-канала в дополнение к OpenVPN еще в 2019 году. Честно говоря, особых преимуществ по сравнению с OpenVPN не увидел - имхо, WG получил гораздо больше хайпа, чем он заслуживает; скорее всего, по причине "одобрямса" со стороны Торвальдса и других разработчиков Linux, отметивших элегантность решения, чистоту кода и нераздутый функционал (что вполне естественно, учитывая возраст WG).
Однако что тогда, что сейчас, WG, как по мне, остается слишком примитивным (я имею ввиду, из коробки, без обвязки сторонним или самописным ПО). Если сравнивать с тем же bloated OpenVPN, я отметил для себя как минимум такие недостатки:
Невозможность запушить конфиг от сервера к клиенту (в WG типа нет парадигмы "клиент - сервер", а все члены VPN демократично являются равнозначными "пирами"), что особенно критично, если клиент удаленный, и WG является единственным каналом связи с ним.
Одна из самых критичных для меня проблем - при изменении IP эндпойнта "серверного" пира "клиентский" пир не переподлючается к новому адресу (а для меня это критично, так как сервер находится за серым динамическим IP и dyndns-сервисом), и вообще ни коим образом не пытается обеспечить хоть какую-то гарантию связности сети (к слову, OpenVPN отрабатывает этот момент как боженька). При этом в Линуксе хотя бы есть стандартный скрипт wg_reresolve-dns.sh (который у меня почему-то срабатывает через раз, и из-за этого я потерял доступ к нескольким удаленным машинам, к которым не имею физического доступа), а в винде - добро пожаловать в мир самописных скриптов на Powershell. Причем на гитхабе уже несколько лет висит PR с решением для виндового клиента, но воз и ныне там.
Лютое неудобство управления парком клиентов, если ты не админ локалхоста, а хотя бы обладаешь десятком удаленных в разных местах машин. У пиров нет "человеческих" имен, все соединения маркируются только публичными ключами, поэтому приходится либо вести реестр соответствия ключей клиентам, либо назначать т.н. vanity keys, когда программа перебором подбирает публичный ключ таким образом, чтобы первые n символов ключа соответствовали понятному админу референсу (sErv..., cliEnT1...). Перебор больше четырех символов case-sensitive такого референса не на игровых машинах с GPU - это больно. Плюс я так и не понял, как настроить логирование подключений - думаю, его просто нет, а это очень печально.
Спорный момент, но всё же: отстутствует сжатие VPN-трафика. Да, я в курсе, что это небезопасно, что это можно организовать на другом уровне OSI, но всё же. OpenVPN на одном из моих дохлых каналов работает в несколько раз быстрее WG именно из-за сжатия трафика.
В общем, мое мнение: это решение пока не доросло до использования в сириуз бизнес в своем vanillla-виде. Слишком мало функционала в угоду компактности и элегантности кодовой базы.