уючи для цього pkginfo-l. Можна перевірити статус табличних просторів, що не переключалися вони в режим OFFLINE, що може бути доброю ознакою виконання в даний час гарячого резервування.
SQL> select tablespace_name, status
from dba_tablespaces; _NAME STATUS
-------------------------------------- ONLINEONLINEONLINEONLINE_REPOSITORY ONLINEONLINE_IND_1 OFFLINE_DATA_1 ONLINE
6 rows selected.
SQL>
Перевірка холодного резервування простіше, так як можна знову перевірити завдання cron, листинги процесів і подивитися, чи є регулярні зупинки, а потім пошукати яке-небудь працююче програмне забезпечення резервування. Якщо доступний сигнальний файл Oracle (alert log), то в ньому просто знайти всі зупинки та запуски бази даних. Необхідно пробувати визначити, де і коли записуються файли і, що більш важливо, намагатися дізнатися, чи можна ці фали взяти і прочитати.
3.2 Резервні копії на стрічці
Резервні копії на стрічці досить добре охороняються, але якщо рішучий хакер захоче, і захист буде не на висоті, він може, використовуючи соціальну інженерію, запросити стрічки з резервними копіями на винос і почати їх упорядковувати і збирати по міру отримання. Коли всі стрічки будуть зібрані, можна буде повторно створити базу даних на іншій машині. Якщо навіть база даних занадто велика для цієї машини, то можна всі непотрібні таблиць та файлів даних перевести в автономний режим (деактивизировать) і відкрити базу даних без них.
Прим. пер.: «соціальна інженерія»- Тактика зловмисного проникнення, при якій зломщик шляхом «умовлянь» обманює користувачів або адміністратора (наприклад, представляючись новим співробітником) і домагається значимої інформації про компанію та / або її комп'ютерних системах, щоб отримати несанкціонований доступ до мережі. Існують навіть приховані параметри, які допомагають запустити базу даних, коли вона ламається при спробі запуску неповної бази даних.
3.3 Резервні копії на диску
резервний база дані відновлення
Резервні копії на диску навіть краще, якщо не захищені файли. Їх легше взяти і десь повторно створити базу даних для вилучення хешировані паролів або конкретних даних. Тут потрібні технічні прийоми, для з'ясування, яке використовувалося програмне забезпечення для резервування, де знаходяться реальні резервні копії і журнальні файли.
У багатьох випадках бази даних розробників і тестові бази даних мають копії всіх промислових даних, оскільки вони потрібні для системного тестування і налаштування продуктивності. Якщо потрібні ці дані, дуже часто достатньо одного дня для їх вилучення з цих баз даних. Якщо необхідно знайти базу даних розробників або тестову базу даних: її не завантажуйте у ту ж машину, в якій працює промислова база даних. Необхідно з'ясувати в файлах tnsnames.ora і listener.ora SID бази даних, який схожий на SID промислової бази даних. Подивитися в директорії admin інсталяції Oracle файли init.ora. Вони мають імена init [ORACLE_SID]. Ora.
Іноді залишаються інші дірки - розробники часто мають набагато більше прав доступу, ніж це потрібно. Коли тестова середу переноситься в промислову базу даних, часто копіюються також кор...
