Делаю бэкап сервера раз в неделю, этого достаточно или нужно каждый день?

раз в неделю мало, братан надо каждый день. и бэкап не держи локально гони в облако — AWS, Google Azure Linode — все дешевые. есть правило 3-2-1, всем советуем. пусть будет и локальный бэкап, и облачный...

Инструменты автоматизации бэкапа: rsync (инкрементальный), mysqldump (база данных), AWS backup service, Duplicati (бесплатный, с шифрованием), Backblaze B2 (1 цент/ГБ/мес). Стратегия ротации: 7 дней ежедневно, 4 недели еженедельно, 12 месяцев ежемесячно. Для e-commerce: соответствие ACID, логи транзакций, архивация binlog. Нужно тестировать восстановление (ежемесячно) — чтобы убедиться, что бэкап рабочий. Хранение офф-сайт минимум 30 дней, идеально 1 год.

Делай бэкап каждый день брат чё тут такого, напиши скрипт, поставь в cron пусть сам крутится. И в облако гони S3 там 3 лиры копейки. короче если сервер сгорит в облаке данные останутся тогда и разберешься...

Планирование стратегии бэкапа: 1) Определи RPO (сколько часов/дней потери данных допустимо) 2) Определи RTO (как быстро нужно восстановить), 3) Политика хранения (сколько времени хранить) 4) Выбери хранилище (локальный диск лента, облако) 5) Шифрование (для чувствительных данных) 6) Автоматизация (cron, запланированные задачи) 7) Мониторинг (успешность бэкапов) 8) Тестирование (ежеквартальный тест восстановления). Идеальный RPO для e-commerce: почасовой (< 1 час потери данных), RTO: < 4 часа. Корпоративный стандарт: ежедневно, но для критичных систем инкрементальный каждые 4-6 часов.

15 лет в IT, каждый раз беда из-за того, что пренебрегали бэкапами. Большинство людей и малых бизнесов делают резервные копии раз в неделю, но это рискованно. Для e-commerce минимум ежедневный бэкап. Полный бэкап раз в месяц, остальное — инкрементальный. Уходите в облако, особенно используйте S3 с версионированием — можно восстановить старые версии.

Не могли бы вы это пояснить? Ответ сильно зависит от отрасли, универсального правила нет.

Изменение платежных данных никогда не подтверждается через тот же канал. Это мое мнение, не утверждаю, что оно единственно верное.

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

Оставлю как заметку, пригодится.

Прочитал этот ответ и выдохнул: значит, проблема не только у меня. Пытаться сделать это в одиночку — самый дорогой путь.

Проверено опытом.

Если я правильно понял, вы имеете в виду следующее: Когда пытаешься изменить всё сразу ничего не приживается.

Исправьте, если я ошибаюсь.

Есть один момент, который меня интересует. Если разрешение и объем тестирования не зафиксированы письменно, тест не начинать.

Посмотрю с другой стороны, я на стороне поставщика. То, что делают все, не значит, что это правильно.

Надеюсь, это будет полезно.

Очень актуальная тема. Если разрешение и объем тестирования не зафиксированы письменно, тест не начинать.

Когда пытаешься изменить всё сразу, ничего не приживается. Если напишете результат здесь, это поможет и другим.

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

Удачи.

Не могли бы вы это пояснить? То что делают все, не значит, что это правильно.

Если напишете результат здесь, это поможет и другим.

Как думаете, это сработает в любом масштабе? Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно.

Решения, работающие в малом масштабе рушатся при росте я узнал это слишком поздно.

Появились три разных мнения, они дополняют друг друга. Большая часть потерь времени копится на задачах, ожидающих согласования.

Исправьте, если я ошибаюсь.

На это стоит обратить внимание. Забытые тестовые среды становятся входом в систему чаще, чем продакшн.

Согласен с этим. Спешка в решениях оборачивается исправлениями через полгода.

На этом всё, извините, если затянул.