О системах планирования ресурсов предприятия Scala, iScala
пользователям ERP систем Scala 5.1, iScala 2.2, iScala 2.3, iScala 3.0, iScala 3.1, iScala 3.2, iScala 3.3, iScala 3.4, iScala 3.5
  • Главная
    • О проекте
      • Разъяснение о проекте и его участниках
      • Заявление / Memorandum
    • Новости проекта
    • Список опубликованных материалов основного раздела
    • Информация, перенесённая из старых форумов
    • Подписаться на новостную рассылку
  • Наши услуги
  • Статьи
    • Статьи
    • Избранное
    • Мысли вслух
  • Процедуры
  • Доходчиво о сложном
    • Обучение
    • Как сделать?
    • iScala «для чайников»
    • Оч.умелые ручки
  • Структура таблиц
    • Scala 5.1 SR13
    • iScala 2.2 HF 2.3318
    • Tables structure changes history from iScala 2.2 SR2 to iScala 3.0 FSP4
    • Epicor iScala 2.3 — 2.03.3363
    • Epicor iScala 2.3 SR1
    • Epicor iScala 2.3 SR2
    • Epicor iScala 2.3 SR3
    • Epicor iScala 3.00 FSP 2 — 3.00.02254
    • Epicor iScala 3.0 FSP4 — 3.0.4267
    • Изменение структуры таблиц iScala 3.1 по сравнению с iScala 3.0 FSP4 / Table structure changes between iScala 3.0 FSP4 and iScala 3.1
    • Epicor iScala 3.1 — 3.1.0511
    • Epicor iScala 3.2 — 3.2.0317
    • Epicor iScala 3.3 — 3.3.0419
    • Epicor iScala 3.4 — 3.4.0399
    • Epicor iScala 3.5 — 3.5.0.0429
    • Изменение полей в таблицах БД iScala 3.4 по сравнению с iScala 3.2 / Difference between DB structure of iScala 3.4 and iScala 3.2
    • Изменение полей в таблицах БД iScala 3.5 по сравнению с iScala 2.2 / Difference between DB structure of iScala 3.5 and iScala 2.2
  • Материалы по модулям iScala
    • Главная Книга
    • Основные Средства
    • Книга Закупок
    • Книга Продаж
    • Заказы на Закупку
      • Требования
    • Заказы на Продажу
    • Управление Запасами
    • Установка, Администрирование
      • Настройка определений документов MSRS
    • Заработная плата
    • Структура базы данных
    • Отчётность SSRS
    • Отчётность AFR
    • Примеры отчётов
    • Примеры отчётов AFR
    • Интеграция с другими системами
    • Epicor Service Connect
  • English
  • Контакты
  • Поиск
Главная  »»»  IT & ERP  »»»  О необходимости раздельного хранения резервных копий

О необходимости раздельного хранения резервных копий

01.07.2017 Автор Алексей Васильев

В прошедший четверг мне позвонил коллега и рассказал печальную историю: у нашего клиента вирус уничтожил данные на всех серверах, включая сервер резервного копирования. Единственные резервные копии, которые сохранились — те, что делала расчётчица заработной платы (разумеется, это только данные модуля «Заработная плата») и тестовый сервер, на котором мы в конце прошлого года делали тестовую конвертацию на новую версию iScala. Очень печально! Я очень им сочувствую!

В тот же день я позвонил ИТ директору компании, где я раньше работал, и, поинтересовавшись как у них дела, предложил ещё раз убедиться, что процедура резервного копирования работает надежно. На мой взгляд, резервное копирование не менее важно, чем системы безопасности компьютерной сети.

Лично я пережил очень неприятные минуты и часы будучи системным администратором, когда однажды при попытке добавить дополнительный диск в сервер IBM, возникла нештатная ситуация и сервер перестал работать. После нескольких попыток устранить проблему я решил восстановить резервную копию на сервере наших соседей, но выяснилось, что стриммер не может прочитать ленту, так как оглавление этой ленты хранится на сервере, который вышел из строя. Чудесно, правда? 🙁 В конце концов, с помощью друзей мне удалось восстановить сервер, но политику резервного копирования я изменил, а историю эту запомнил навсегда. Было это более 20 лет назад… Другой подобный случай произошёл несколько лет спустя у одного из моих клиентов во время внедрения Скалы. Вышел из строя сервер, а когда захотели восстановить данные из бэкапа, выяснилось, что бэкап хранился на том же сервере. Третий случай я наблюдал, когда бэкапы регулярно делались, ответственный сотрудник добросовестно менял кассеты для стриммера и складывал их в сейф, но, когда понадобилось восстановить данные из резервной копии, выяснилось, что в процедуре резервного копирования произошел какой-то сбой и сервер что-то писал на ленту, но оказалось, что прочитать с неё данные не удаётся.

Таким образом, Вы можете быть уверены в том, что Ваши данные надежно сохранены и доступны для восстановления только если

  • Вы храните их отдельно
  • Если Вы делаете несколько типов резервирования, например, месячный бэкап, недельный бэкап, ежедневные бэкапы
  • Процедура создания резервной копии содержит проверку возможности восстановления

Разумеется, многие из Вас знают о процедурах восстановления больше меня. Вот только уверены ли Вы в том, что эти продвинутые процедуры в Вашей компании безукоризненно выполняются?

Рубрика: IT & ERP Метки: бэкап
VK Telegram Про канал в WhatsApp

Copyright © 2025 О системах планирования ресурсов предприятия Scala, iScala.

Gammapolis WordPress Theme by ERP & Business Consulting

Прокрутка вверх