Какие основные виды и стратегии восстановления систем и данных существуют?

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

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

Резервные копии (Backup) — это как фотка твоей хаты на случай пожара. Делаешь снимок и спишь спокойно.

• Полный бэкап (Full): Снимаешь всё, до последнего файлика. Места жрёт — овердохуища, делается долго, но если что — раз — и всё на месте. Быстро восстановился и пошёл дальше.
• Инкрементный (Incremental): Ленивая жопа. Сохраняешь только то, что поменялось с прошлого раза. Быстро, места мало. Но вот беда: чтобы всё собрать, тебе нужна целая цепочка этих бэкапов. Восстановление — тот ещё квест, можно и запутаться, блядь.
• Дифференциальный (Differential): Умный компромисс. Сохраняешь всё, что поменялось с последнего полного бэкапа. И создаётся быстрее полного, и восстанавливается проще, чем инкрементальный.

Снимки состояния (Snapshots) — это вообще магия, ёпта! Не копия, а моментальный слепок системы. Как фотоаппаратом щёлкнуть — и всё заморозилось. Виртуалки, облачные диски, базы данных — все это умеют. Главный плюс — скорость. Сделал за секунды, откатился — тоже почти мгновенно. Но это не замена бэкапу! Снапшот часто привязан к тому же хранилищу. Если оно накроется — твои снапшоты тоже, простите, в пизду.

Репликация (Replication) — это когда ты не ждёшь, пока всё сломается. Ты заранее, в реальном времени, копируешь все данные на другой сервер. Один упал — второй уже работает. Можно читать с копий, чтобы основной не ебали, а можно и писать в оба. Штука для высокой доступности, чтобы пользователи даже не заметили, что что-то где-то брякнулось.

Транзакции и откаты (Rollback) — вот это, блядь, основа основ, чтобы в данных не было каши. Принцип простой, как три копейки: либо всё сделалось правильно, либо нихуя не сделалось. Называется ACID. Смотри, как в базе данных:

BEGIN TRANSACTION; -- Начали, мать вашу, дело!
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1; -- Списали с Васи
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2; -- Зачислили Пете
-- А тут, сука, ошибка! Петя не найден!
ROLLBACK; -- И всё! Обе операции отменяются. Как будто ничего и не было. Баланс Васи возвращается. Чистота, блядь!
-- Если бы всё прошло гладко:
COMMIT; -- Тогда да, фиксируем изменения.

Аппаратная избыточность (RAID) — это когда ты дискам не доверяешь, ибо они железные и тупые. Берёшь несколько и делаешь из них массив.

• RAID 1 (Зеркало): Всё, что записал на один диск, автоматом пишется на второй. Один сдох — работаешь со второго. Просто и надёжно, как топор.
• RAID 5/6: Хитрее. Данные и контрольные суммы раскиданы по всем дискам. Один, а то и два диска можно выкинуть — система жива. Экономичнее зеркала, но сложнее.

Аварийное восстановление (Disaster Recovery, DR) — это уже не про один сервак, а про план на случай, когда весь твой дата-центр ушёл под воду, в буквальном смысле. Целый спектакль с другим городом, облаками и прочей хуйнёй. Тут две главные цифры:

• RTO: За сколько часов/минут ты должен всю эту разруху поднять обратно.
• RPO: Сколько данных ты согласен потерять. Пять минут? Час? Сутки? Это определяет, как часто ты должен эти бэкапы гонять.

Идемпотентность (Idempotency) — а это, сука, высший пилотаж для распределённых систем! Философия такая: сделай так, чтобы одну и ту же операцию можно было безопасно послать сто раз. Представь, клиент шлёт запрос "спиши 100 рублей", связь оборвалась, и он не знает, прошло или нет. Он шлёт ещё раз. А если деньги спишутся дважды? Пиздец! Решение: каждая операция идёт с уникальным idempotency-key. Сервер, получив повторный запрос с тем же ключом, не выполняет его снова, а просто отдаёт результат первой попытки. "О, этот ключ я уже видел, вот тебе, мудила, ответ от прошлого раза, иди нахуй". Идеально!