День бэкапа
Mar. 31st, 2025 11:29 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
chabapok31 марта — это Международный день резервного копирования
Люди делятся на три категории: те, кто не делает бэкапы, кто делает - и те, кто теперь еще и периодически проверяет,что из бэкапа можно все восстановить.
а к какой категории принадлежите вы?
Люди делятся на три категории: те, кто не делает бэкапы, кто делает - и те, кто теперь еще и периодически проверяет,что из бэкапа можно все восстановить.
а к какой категории принадлежите вы?
![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
no subject
Date: 2025-03-31 09:26 pm (UTC)no subject
Date: 2025-04-01 03:11 am (UTC)Но проверять бэкапы надо, это да.
no subject
Date: 2025-04-01 03:34 pm (UTC)Как проверять, если не восстанавливать?
Ведь может оказаться, что "проверка" работает, а когда надо, действительно, восстановить - не работает.
> Если восстанавливать - то на отдельный пустой диск
Не обязательно на пустой диск. Но восстанавливать надо на другой компьютер.
Например, на сервер для разработки.
Заодно разработчики получат возможность протестировать функциональность на данных, восстановленных из production.
> а то можно случайно восстановить старые версии файлов:-)
Обычно backup нужен для восстановления на другой компьютер (потому что основной компьютер сломался).
Поэтому тренироваться восстанавливать backup на компьютер, с которого этот backup был сделан - довольно странно.
no subject
Date: 2025-04-01 05:17 pm (UTC)А это зависит от фич бэкап софта. Просто как пример - я периодически делаю бэкап всяких важных файлов и документов для offsite backup путем просто копирования ряда фолдеров на большой USB drive и потом этот drive хранится в моей банковской ячейке. Копирование делается просто массовым копированием файлов (так сделано сознательно, по ряду причин).
Так вот, в этой схеме проверка бэкапа делается легко и просто - перед копированием я прогоняю утилитку которая читает исходные файлы и генерирует дайджест с их MD5 хэшами, а после копирования (для проверки бэкапа) та же самая утилитка прогоняется по файлам в бэкапе и сравнивает MD5 хэши в тем что в дайджесте. Поначалу я это делал для того чтобы убедится что файлы переписались без каких-либо сбоев, но это же позволяет проверять бэкап очень простыми и надежными средствами.
Если делать бэкап генерируя некий архив/архивы, то часто бэкап софт имеет такую функцию.
Еще один важный фактор - насколько волатильными являются файлы и фолдеры. Для себя я давно придерживаюсь схемы - важные файлы и документы рассматриваются как read-only (исключения есть но их мало). Проверять бэкап таких файлов легко и просто, просто сравнением файлов в бэкапе с исходными файлами.
Но это все относится к традиционным бэкапам. Как часть data protection strategy я использую RAID, и поверх рейда - snapshots которое защищает от случайных удалений и изменений файлов. Проверка интегрити тут встроена в сам механизм - e.g. RAID.
...
Side note - вот это предложение ну *очень* проблемное, с секьюрити пойнт оф вью. Это один из классических но тем не менее популярных способов как раз.ебать секьюрити вашего сервиса в ноль, не делайте так для реальных прод сервисов.
>>>Например, на сервер для разработки.
>>>Заодно разработчики получат возможность протестировать функциональность на данных, восстановленных из production.
Реальные рабочие данные из прод *никогда* нельзя выносить из прода, тем более на дев машины. Аналогично и с прод сертификатами, кредами и т.п.
Read-only документы?
Date: 2025-04-01 05:26 pm (UTC)Что значит "read-only" в случае, если документ, всё-таки, изменяется со временем?
Re: Read-only документы?
Date: 2025-04-02 07:43 pm (UTC)Есть некоторый процент файлов которые регулярно меняются (например - файлы какого-нибудь проекта над которым я активно работаю), для таких файлов file history/snapshots - самое то.
Re: Read-only документы?
Date: 2025-04-03 12:00 am (UTC)То есть вы просто копируете в ваш архив новые файлы?
Re: Read-only документы?
Date: 2025-04-03 04:36 pm (UTC)Смотря что считать архивом - в традиционном понимании архив это отдельный сторадж (обычно-с медленным доступом) где хранятся данные и данные из архива можно извлекать для использования.
Я сделал несколько по-другому - например коллекция фильмов и музыки организована как отдельный volume на NAS, плеер напрямую читает файлы с этого volume (т.е. нет необходимости извлекать файлы из архива), но файлы на этом volume организованы как write-once/read-only - я регулярно добавляю туда файлы, но никогда не меняю уже существующие файлы (менять их смысла нет).
На другом NAS volume я храню всякие разные важные и нужные файлы - сканы всяких документов и т.п., схема та же самая - write-once/read-only.
Эта схема (WORM, write-once/read-many) применяется в сторадже в современном клауде, это так называемая immutable storage. Synology NAS тоже такое умеет, локально (без всякого клауда).
Кроме того у меня есть отдельный набор фолдеров где лежат файлы которые постоянно меняются, WORM там применить не получится, но регулярные снапшоты обеспечивают защиту файлов и версии.
Re: Read-only документы?
Date: 2025-04-03 05:15 pm (UTC)А вы удаляете какие-то из этих файлов?
Или то что записано - не может быть удалено?
Re: Read-only документы?
Date: 2025-04-03 07:39 pm (UTC)В архиве документов - я ничего не удаляю, благо файлы небольшие и места много не занимают. В архиве фильмов - изредка я устраиваю чистку и удаляю что-то. В большинстве случаев это замена старых видео файлов низкого качества на 4К или подобное. Но бывает что удаляю старые фильмы которые не нужны.
Процесс удаления файлов с такого тома требует специальных дополнительных шагов, случайно такое произойти не может.
Restore backup on development server
Date: 2025-04-01 05:28 pm (UTC)Вы подразумеваете, что security of development server - нулевая?
Почему?
> Реальные рабочие данные из прод *никогда* нельзя выносить из прода
Почему нет?
Это же зависит от того, насколько высокие требования безопасности.
> тем более на дев машины.
Не на dev машины, а на development server.
> Аналогично и с прод сертификатами, кредами и т.п.
Это отдельная история.
Re: Restore backup on development server
Date: 2025-04-02 07:30 pm (UTC)>>>Почему?
Вы имеете в виду - дев машины или test environment?
На дев машины нельзя переносить данные и/или креды из прода категорически, в test env - нельзя в большинстве случаев, можно только если test env изолировано и менеджится так же как прод - чего почти никогда нет (и если вам кто-то рассказывает что мол тест у них изолирован как прод - в 99% это самообман).
>>>>>> Реальные рабочие данные из прод *никогда* нельзя выносить из прода
>>>Почему нет?
>>>Это же зависит от того, насколько высокие требования безопасности.
Безопасность Dev машин и тест env не нулевая (их тоже надо защищать), но по ряду обьективных причин дев машины просто невозможно защитить и мониторить на таком же уровне как и прод, для 99.9% тест env - аналогично.
Если интересно, я могу обьяснить подробней почему так.
Ну и если вы знаете способ(ы) как защитить dev машины на таком же уровне как прод (без создания капитальных проблем для девов) - я бы с удовольствием послушал, мне лично такие способы неизвестны.
...
В инфосеке это классика - неизменно популярный способ ломануть прод через атаку на тест инстансы и на дев машины, широко используется как ред тимами так и реальными атакерами.
Re: Restore backup on development server
Date: 2025-04-03 07:46 pm (UTC)Да development машины гораздо труднее защитить, чем production.
Но из этого же никак не следует, что production backup нельзя восстанавливать на development server.
Если утечка данных не катастрофична, то вполне можно и рискнуть ради удобства и скорости разработки и тестирования.
Re: Restore backup on development server
Date: 2025-04-09 06:34 pm (UTC)Я обычно думаю о таких вещах в терминах environments - есть Dev Environment где девелоперы ведут разработку и гоняют ранние тесты как часть процесса разработки - это включает Dev workstations, но может включать и например тестовые VMы используемые девами в процессе разработки, бывает в dev env есть и тестовый сервер используемый для экспериментов и местного тестирования. In terms of security, ключевыми характеристиками dev env является весьма свободный доступ без особых контролов - девы обычно имеют админ аккаунты (как правило необходимо для процесса разработки), могут использоваться всякие разные рандомные тулзы, network isolation как правило нет или она очень слабая, identity isolation разумеется тоже нет (и ни о каких secure admin workstations и речи быть не может), security monitoring рудиментарная (или вообще нет) и т.д.
Бывает еще integration testing env - отдельный env похожий на prod но предназначенный для полного тестирования. Тут секьюрити может быть чуть получше, но только чуть - много людей имеют standing admin access, могут использовать всякие рандомные тулзы (для дебаггинга), identity isolation нет, network isolation может быть а может и не быть, security monitoring обычно рудиментарная. Часто такие testing env еще и доступны из интернета (для полноценного тестирования часто это необходимо), что сильно повышает риски - а защит особо там нет.
Бывают конечно исключения, но в 95% случаев такой env - первый кандидат для атак.
Ну и есть Prod - тут все понятно - identity isolation, network isolation, жесткий контроль доступа (JIT etc.), полноценная security monitoring и т.п.
В рамках этой таксономи, чем является development server о котором вы говорили?
...
>>>Если утечка данных не катастрофична
Для практически любых компаний утечка данных кастомеров - одна из самых плохих возможных проблем, хуже чем утечка сорс кода. Утечка данных кастомеров у сколько-нибудь большой компании быстро попадет в новости. Да, и по нынешним правилам в большинстве западных стран - утечку данных пользователей держать в секрете невозможно, компании обязаны оповестить пользователей чьи данные утекли с понятными последствиями.
Понятно что если речь идет о каком-нибудь студенческом проекте а не о коммерческом сервисе то проблем намного меньше, но даже в студенческом проекте проблемы могут быть неиллюзорными, особенно если аттакеры ломанут прод используя информацию из тест env - что часто происходит.
Re: Restore backup on development server
Date: 2025-04-09 10:48 pm (UTC)Такой Dev Environment.
С полным доступом для разработчиков.
> Ну и есть Prod - тут все понятно - identity isolation, network isolation, жесткий контроль доступа (JIT etc.), полноценная security monitoring и т.п.
Такой строгий security - слишком дорого в большинстве случаев.
> Для практически любых компаний утечка данных кастомеров - одна из самых плохих возможных проблем, хуже чем утечка сорс кода.
Возможно, утечка данных customers -- хуже, чем утечка source code.
Но ещё хуже: неработающая функциональность (из-за того, что из-за чрезмерно задранной security, разработка становится слишком сложной и дорогой).
> Утечка данных кастомеров у сколько-нибудь большой компании быстро попадет в новости.
1) Только для больших компаний.
2) Попадает в новости и что?
Разве это как-то заметно снижает количество пользователей?
> Понятно что если речь идет о каком-нибудь студенческом проекте а не о коммерческом сервисе
Речь идет о малом бизнесе.
Re: Restore backup on development server
Date: 2025-04-10 03:11 am (UTC)Я говорю о больших серьезных сервисах с множеством кастомеров - кстати в эту категорию входят не только сверх-большие компании вроде Гугла/Амазон/Микрософт/ФБ/etc. но и компании второго-третьего-четвертого плана у которых есть более-менее популярный сервис - в общем компании и сервисы которые что-то значат и представляют какую-то ценность которую надо защищать.
Малый бизнес и очень маленькие компании которые сделали какой-то свой интернет сервис никому не интересны и их никто специально не ломает - по принципу НеуловимогоДжо. Даже когда у них секьюрити очень слабая - это будет малозаметно (ну пока не грохнут залетные кулцхакеры, или пока компания не сделает что-то интересное и будет пытаться продать себя - тогда слабая безопасность им обойдется очень дорого:-) ).
...
Но в этом деле важно помнить что слабая секьюрити - это слабая секьюрити, и если ты принимаешь бизнес-решение жить со слабой секьюрити - это надо делать с открытыми глазами хорошо понимая реальное состояние дел.
Да, и как side note - сделать нормальную секьюрити в маленьком сервисе абсолютно реально и не так уж дорого, и если сделана она правильно - существенного импакта на продуктивити не будет. Но для этого надо чтобы твои технари (хотя бы один-два из них) понимали как это собственно делается и что важно а что нет. Но нанять таких людей очень дорого, разве что если сам владелец малого бизнеса знает как и что делать...
Re: Restore backup on development server
Date: 2025-04-10 03:21 am (UTC)Чем именно обойдётся маленькой компании, сделавшей что-то интересное - восстановление production backup в development environment?
> сделать нормальную секьюрити в маленьком сервисе абсолютно реально и не так уж дорого, и если сделана она правильно - существенного импакта на продуктивити не будет.
Чем же заменить восстановление production backup на development сервере с точки зрения тестирования ситуаций, которые требуют реалистичных данных?
> нанять таких людей очень дорого
Так "очень дорого" или "не так уж дорого"?
Re: Restore backup on development server
Date: 2025-04-10 03:32 am (UTC)Компании дорого обойдется слабая секьюрити. Production backup в dev env - это просто один из простых способов опустить секьюрити прода до уровня dev env (что неадекватно для прод), кроме того думаю что у компании которая так делает там много и других секьюрити проблем.
...
Кстати, иллюстративный пример размера компании - если взять Dreamwidth Studios, то это (очень) малый бизнес - у них всего два (!) сотрудника и меньше чем $400K annual revenue, но при этом у них пара миллионов юзеров (включая нас:-) ), если у Дрима утекут данные кастомеров или хакнут прод - будет неприятно и больно.
>>>Так "очень дорого" или "не так уж дорого"?
Не так уж дорого сделать нормальную секьюрити сервиса даже в малом бизнесе, но очень дорого стоит нанять людей которые знают и понимают как это делать. Т.е. если сам владелец такого бизнеса имеет нужные знания и умения - все ОК, но если нет - то проблема.
Re: Restore backup on development server
Date: 2025-04-10 04:38 am (UTC)Что именно "дорого обойдется", если восстанавливать production backup в development?
Какие конкретно последствия следует ожидать?
> если у Дрима утекут данные кастомеров или хакнут прод - будет неприятно и больно
Насколько больно это будет для Dreamwidth в пересчёте на потерянные $$$?
Упадёт ли прибыльность Dreamwidth, хотя бы, на 10% ($40k = 10% от $400k/year)?
Re: Restore backup on development server
Date: 2025-04-14 03:55 am (UTC)В чем это может конкретно проявиться если/когда такая маленькая компания сделает что-то интересное - две основных категории проблем:
1. Если такая компания смогла сделать что-то ценное (например - интересный сервис/продукт) и хочет теперь себя продать, то потенциальные покупатели обязательно устроят technical due diligence и проблемы с безопасностью раскопают очень быстро. По результатам due diligence потенциальный покупатель скорее всего либо потребует серьезную скидку (аргументируя необходимостью все это чинить), либо (в особо плохих случаях) просто откажется от покупки.
2. Если такая компания смогла сделать что-то ценное и ее сервис начал расти набирая юзеров, это быстро привлечет внимание хакеров которые пройдутся и проверят стандартные каналы взлома, и при слабой секьюрити ломанут такой сервис очень быстро. Причем я говорю о стандартных залетных кулцхакерах которые просто хотят сшибить денег с компании и/или ее юзеров, не о nation state хакерах (там своя специфика).
>>>Насколько больно это будет для Dreamwidth в пересчёте на потерянные $$$?
Судя по вашим вопросам - вам это все скорее всего не релевантно. А если вдруг получится у вас сделать какой-нибудь интересный сервис который наберет популярность - наймете знающих людей (или хотя бы консультантов) которые обьяснят что и как.
Re: Restore backup on development server
Date: 2025-04-14 10:11 am (UTC)Потенциального покупателя никто не заставляет восстанавливать production backup в development environment.
Что здесь чинить-то?
> привлечет внимание хакеров которые пройдутся и проверят стандартные каналы взлома, и при слабой секьюрити ломанут такой сервис очень быстро.
Как ломанут?
Перекупят разработчиков, что ли?
Ну, допустим, перекупили. Как это транслируется в убытки?
Re: Restore backup on development server
Date: 2025-04-14 07:18 pm (UTC)Да и инфосек подавляющее большинство не понимает, даже софт девелоперы - девам обычно кажется что "ну вот сейчас пофиксим баг который эти долбодятлы нашли и все будет з.ебись", а секьюрити паттерны и полиси - это все от лукавого, безопасники мол так жеппу свою прикрывают :-)
Так сложилось что я непосредственно занимаюсь инфосеком, и много раз участвовал в due diligence стартапов. Но как наша беседа наглядно показывает, быстренько в двух словах обьяснить что там и как нереально, да и мне честно говоря это малоинтересно.
...
Постарайтесь нанять дева который инфосеком интересуется, а если вдруг получится сделать какой-нибудь интересный/ценный сервис - наймите людей с нужными знаниями.
Re: Restore backup on development server
Date: 2025-04-14 07:47 pm (UTC)Вместо того, чтобы прямо ответить на мой вопрос ("Как это транслируется в убытки?"), вы спорите с соломенным пугалом (strawman), которое сами и придумали.
Я хорошо знаю, что восстановление production backup на development environment - повышает security risks.
Но из этого же совсем не следует, что восстанавливать production backup на development environment никогда не надо.
Ведь есть и другие, более важные соображения [чем security] при разработке и поддержке продукта.
Re: Restore backup on development server
Date: 2025-04-16 03:29 am (UTC)Нет, мне просто надоело пытаться что-то обьяснить человеку который явно не понимает что такое инфосек и как он собственно делается/от чего зависит. И проводить лекцию-семинар на тему "инфосек и implications для стартапов" я тоже не собираюсь :-)
no subject
Date: 2025-03-31 09:52 pm (UTC)no subject
Date: 2025-04-02 03:43 pm (UTC)Когда встанет вопрос о восстановлении - выяснится, что бэкапы не совпадают, причем как-то ассиметрично (демонически хохочет).
no subject
Date: 2025-04-02 05:02 pm (UTC)no subject
Date: 2025-04-02 07:28 pm (UTC)no subject
Date: 2025-04-01 03:30 am (UTC)Четыре уровня бэкапа:
1. Включенный режим shadow copy делающий snapshot каждые 24 часа (или полноценная file history, если стор поддерживает). Защищает от случайных удалений и изменений файлов - старые версии сохраняются.
2. RAID. Либо mirror, либо RAID5. Защищает от потерь в случае помершего диска (и важно иметь в запасе spare drive чтобы быстро заменить в случае проблем).
3. Раз в полгода - бэкап всяких важных документов и файлов на большой USB драйв, драйв хранится в банковской ячейке. Защита на случай пожара, наводнения и подобных стихийных бедствий. Важно хранить такой бэкап не дома.
4. Кроме того важные документы и файлы периодически бэкапятся онлайн (encrypted backup, разумеется). Это defense in depth, в принципе не обязательно но желательно делать. Вместо онлайн можно устроить домашний бэкап (на отдельные драйвы) - я так раньше делал, до того как онлайн сторадж подешевел.
В давние времена #1 и #2 делались средствами винды (на своем файл сервере), последние годы использую Synology - специализированное железо и софт для таких вещей.
no subject
Date: 2025-04-01 08:40 am (UTC)вы предпочитаете аппаратный или програмный рейд?
Как имея програмный рейд с двумя дисками, если 1 диск вышел из строя, не ошибиться и поменять именно нужный диск, а не хороший? В аппаратном, как я полагаю, возле каждого диска есть светодиод, по которому это видно.
no subject
Date: 2025-04-01 05:45 pm (UTC)И RAID, и бэкапы являются частью data protection strategy. Бэкап не заменяет рейд, и vice-versa. Если же говорить о защите файлов от случайного удаления и модификаций - у меня эта проблема решена использованием снапшотов/file history - работает замечательно, можно легко и просто посмотреть на старые версии файла, и можно легко извлечь любую желаемую версию.
RAID - это для другого, RAID сильно уменьшает вероятность что бэкап вообще понадобится (но тем не менее offsite backup на USB drive я делаю).
>>>вы предпочитаете аппаратный или програмный рейд?
Очень хороший вопрос, это действительно важный момент.
Много лет я использовал софтверный рейд (виндовый). Большим достоинством софтверного рейда является возможнсть вставить эти диски в другую машину, и рейд продолжит работать как ни в чем не бывало (я кстати это проверял). Второе большое достоинство - можно собирать в рейд разные диски. Perf может будет и не оптимальным, но работать будет. Бывает полезно если например нужно заменить умерший диск, а аналогичного нет.
Последние годы я перешел на Synology - там рейд тоже софтверный, но софт специфический. Но зато железо специально сделано именно для использования в качестве NAS (плюс там можно парочку VM запускать и т.п.). Если железо помрет, то надо будет быстренько купить замену и переставить диски, ну и в качестве крайней меры есть софт чтобы извлечь содержимое дисков без Synology железа. Но риски (как по сравнению с виндовым NAS) несколько выше, что есть то есть.
>>>Как имея програмный рейд с двумя дисками, если 1 диск вышел из строя, не ошибиться и поменять именно нужный диск, а не хороший?
В Synology все просто - отдельный светодиод на каждый диск, да и софт делает замену кракнувшего диска практически автоматической. Но это спец железо сделанное для этих целей.
Когда использовал виндовый сервер в качестве NAS - диски просто были помечены. Ну и если отключить не тот диск, то в диск менеджере сразу будет видно.
no subject
Date: 2025-04-01 06:16 pm (UTC)no subject
Date: 2025-04-01 07:31 am (UTC)вот в чем вопрос
no subject
Date: 2025-04-01 08:13 am (UTC)"Одной из наиболее распространенных и эффективных стратегий резервного копирования является правило 3-2-1. Это правило рекомендует создавать три копии каждого важного файла, используя два разных типа носителей, и сохранять одну из копий вне основного места работы или хранения."
no subject
Date: 2025-04-02 09:24 am (UTC)no subject
Date: 2025-04-01 08:00 am (UTC)