Данная статья предназначена для тех, кто заинтересован в сохранении воспроизводимости своих записей на случай внезапного системного сбоя. Далее будут описаны харатктерные особенности целых и поврежденных файлов, записанных в нескольких наиболее известных форматах как MP4, MOV, MKV, FLV, рассмотрены особенности изменений в структуре файлов при различных условиях записи.
В компании «Криптонит» завершили интересное исследование, результатами которого мы спешим поделиться. Наша команда лаборатории информационной и сетевой безопасности провела реверс-инжиниринг ПЗУ промышленного устройства и получила доступ к данным, которые считаются защищёнными. Точно такие же средства «защиты» используются в тысячах других устройств — от принтеров и МФУ до автомобилей Mazda и модуля записи видео на Международной космической станции.
Четыре года назад я уже писал статью на тему обработки кардиограммы. Тогда я показал, как можно перевести бумажную кардиограмму в цифровой формат PCM данных, отрыв затем её в звуковом редакторе. Мне было интересно воспроизвести, послушать и оценить, как это будет звучать. В этот раз предстоит не менее интересная задача. Необходимо разобраться в структуре файла кардиограммы, переписанного с цифрового кардиографа, и извлечь из него всю информацию о кардиограмме в понятном для пользователя виде.
Краткое руководство о том, как обнаружить атаку на внутреннюю инфраструктуру компании раньше всех и правильно отреагировать на нее
Число кибератак стремительно растет: если раньше их количество исчислялось десятками в месяц, сейчас насчитывают тысячи инцидентов только за одну неделю: «Касперский» заявляет о 8-кратном увеличении числа DDoS-атак на российские организации. В то же время недавнее исследование SearchInform сообщает, что из 900 опрошенных ими компаний 95% ограничиваются только антивирусом в вопросах защиты от кибератак. В таких условиях вероятность столкнуться с инцидентом ИБ значительно выше, чем может показаться. Поэтому все же стоит отбросить сомнения, вроде «да кому наша информация нужна», и заранее разобраться, что делать, если инцидент уже случился.
«Когда-то я был админом, который не делал бэкапы. Теперь я очень грустный, но бэкапы делаю», — цитата одного сисадмина.
Утром 16 марта ваш покорный автор получил следующее "письмо счастья". Которое на фоне всего происходящего в мире не казалось таким уж неожиданным.
На днях я столкнулся с такой проблемой: мне нужно было перенести большое количество файлов с одного компьютера на другой. Было решено использовать флешку вместо облака. Суммарный объем файлов примерно 60 гигов, флешка была всего на 32. Я подумал, что за два захода справлюсь с этим. Первую часть (примерно 30 гигов) я перебросил без каких-либо проблем, когда закачивал вторую возникла проблема — на 97% закачка остановилась и минут 40 ничего не происходило. Ну что ж, принято решение вытащить флешку и скинуть на другой компьютер то, что уже было на ней. Но, не тут то было: флешка перестала читаться на каком-либо компе. Попробовал, на всякий случай, несколько вариантов: запустил флешку на компе с Windows и Linux. Результат тот же: звук, что флешка вставлена в компьютер есть, самой флешки нет.
В этой работе рассмотрен пример искажения данных, передаваемых в виде звукового потока.
Почтовый сервис Mail.Ru, платёжная система Qiwi, социальная сеть «ВКонтакте», крупнейший хостинг-провайдер Европы OVH — все они столкнулись с серьёзными сбоями в работе центров обработки данных. Компании не только потеряли деньги из-за выхода оборудования из строя, но и понесли репутационные потери. В этом посте мы расскажем о том, как защитить ЦОД от подобных угроз.
Столь серьёзные форс-мажоры случаются не каждый день — обычно поломки бывают менее критичными. Тем не менее, эта проблема очень распространена: по данным проведённого ресурсом «Цоды.рф» опроса, почти 80% компаний сталкивались с прерыванием работы сервисов из-за сбоев в работе ЦОДа. Решение, которое помогает предотвратить сбои или минимизировать их последствия — постоянный мониторинг инженерной инфраструктуры.
Иван Чувашов, DBA Okko и Southbridge, поделился жизненными кейсами с PostgreSQL, которые помогут решить ваши проблемы.
Разберем случаи из PostgreSQL: запросы в статусе idle in transaction, выключенные контрольные суммы данных, переполнение int4, убивающие базу временные файлы и загрузку CPU.
Hystax — подходящее решение для миграции, если нужно перенести ВМ с Linux или Windows между разными платформами: VMware, OpenStack, AWS и так далее. C его помощью можно переехать на любую из этих платформ даже с bare-metal. Мы уже не раз использовали Hystax для переезда наших клиентов с VMware в OpenStack. Также Hystax можно использовать для послеаварийного восстановления (DR).
Несколько месяцев назад один из клиентов обратился к нам с задачей переезда с OpenStack на VMware. Потом клиент передумал, но мы все равно провели пару тестов с миграцией и аварийным восстановлением на VMware. Выяснилось, что без знания особенностей Hystax можно внезапно закопаться в ручных настройках сети. Для DR это фатально, так как ручная настройка сразу увеличивает RTO. Но и для миграции настройка вручную не очень хороша. Без опыта с Hystax можно неверно спланировать работу, не уложиться в технологическое окно и нарушить сроки переезда.
В статье расскажу, где настройки могут не подняться автоматически и как с этим бороться. Показывать буду на версии Hystax DR 3.7.1701.
Привет Хабр, меня зовут Александр Архипов, и моя задача это показать как можно просто и легко настроить резервное копирование данных СУБД clickhouse разработанной компанией Яндекс. Я работаю devops инженером, и так как у нас в команде нет первоклассного DBA, недавно мне пришла задача, настроить резервное копирование данных. Пошел искать, гуглить, читать и смотреть видео:) Для всего этого, потребовалось не очень много времени, чтобы изучить новый инструмент, но все же, у нас его всегда мало. В этой статье я постараюсь понятно рассказать об утилите clickhouse-backup, надеясь на то, что тому кто пользуется этой СУБД или же только планирует внедрять у себя на проекте, и справится с этой задачей довольно быстро и легко.
Привет, Хабр! Современный высокотехнологичный бизнес немыслим без глубокой аналитики и отработки гипотез с помощью ML. Однако это накладывает особые требования на качество данных: все мы знаем, что ерунда на входе = ерунда на выходе. Прекрасно понимая, что стоит на кону у большого бизнеса, мы организовали большой митап, посвящённый подходам к качеству данных в больших компаниях уровня Lyft и Shopify.
Митап был интересен как приглашёнными спикерами, представителями крупных проектов, делающих свой бизнес на анализе больших данных, так и охватом тем. Мы поговорили о том, как предотвратить повреждение данных (потому что «не ломать проще, чем чинить»), о том, как быть, когда информация есть, но пользователи ей не доверяют, как тестировать данные не на динамических моделях, а на подменённых «в воздухе» статических данных и, наконец, как показывать пользователям фейковые данные, чтобы узнать, чего люди хотят на самом деле.
Далее краткий пересказ докладов Datafold, Lyft, Shopify и HealthJoy. Текст будет интересен в первую очередь дата-инженерам и тем, кто обеспечивает хранение, предоставление и тестирование данных.
В VBR 11 у инструментов Veeam Explorer for SQL Server и Veeam Explorer for Oracle появилась возможность мгновенного восстановления базы данных (Instant recovery). Подход здесь напоминает всем знакомое мгновенное восстановление виртуальной машины - быстро смонтировать файлы на рабочий сервер, чтобы, например, достать нужные отчеты для бухгалтерии, и в это же время в фоновом режиме спокойно копировать файлы бэкапа и по готовности переключиться на полноценную машину.
Рассмотрим эту фичу более подробно на примере SQL Server database.
Долгожданный релиз версии 11 нашего флагманского продукта заставил меня снова взяться за перо. Такова цена работы с активно развивающимся софтом – не успеваешь с чувством глубокого удовлетворения закрыть Word, как все написанное начинает устаревать и Сизиф вновь должен толкать свой камень в гору на общее благо.
За время моей работы в Veeam я пережил уже семь крупных апдейтов. Чтобы быть во всеоружии, еще до релиза по каждому я вел конспект, куда записывал все изменения и нововведения. Могу сказать, что по этой нехитрой метрике v.11 побил все рекорды, обогнав даже юбилейную десяточку. Уверен, о новых фичах будет сказано еще многое, а я же продолжу развивать тему этой серии и расскажу, какие изменения следует ожидать с точки зрения ретеншена.
