0% found this document useful (0 votes)
4 views

database backup

The document outlines a Level-IV module on Database Backup and Recovery, covering database architecture, backup methods, and recovery procedures. It details various database architectures including single-tier, two-tier, three-tier, and n-tier, along with their functionalities and implications for data management. Additionally, it discusses potential risks and failure scenarios in database environments, alongside mitigation strategies to ensure data integrity and availability.

Uploaded by

rob69do
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

database backup

The document outlines a Level-IV module on Database Backup and Recovery, covering database architecture, backup methods, and recovery procedures. It details various database architectures including single-tier, two-tier, three-tier, and n-tier, along with their functionalities and implications for data management. Additionally, it discusses potential risks and failure scenarios in database environments, alongside mitigation strategies to ensure data integrity and availability.

Uploaded by

rob69do
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 26

Web Development and Database

Administration Level-IV

 ModuleTitle: Database Backup


and Recovery
This module covers the units
 •Chapter one= Database Architecture
 •chapter two=Database Backup Methods
 •chapter three=Database Recovery Points

& Procedures
Unit one: Database
Architecture
 This unit is developed to provide you the
necessary information regarding the
following content coverage and topics:
 • Architecture of database file system
 • Identify Risks and Failure Scenario
 • OHS
1.1. Architecture of database
file system

 Database architecture focuses on database


design and construction for large enterprise
database systems that manage massive
amounts of information for organizations.
 Database architecture includes setting the
standards for the security and programming
aspects of these databases, as well as figuring
out how these databases will operate and
function within existing structures.
 The design of a DBMS depends on its
architecture.
Cont….
 Selecting the correct Database
Architecture helps in quick and secure
access to data.
 It can be centralized or decentralized

or hierarchical. The architecture of a


DBMS can be seen as either single tier
or multi-tier.
 The tiers are classified as follows:
1.1.1. Single tier
architecture
 The simplest of Database Architecture are 1 tier where
the Client, Server, and Database all reside on the same
machine.
 it keeps all of the elements of an application, including
the interface, Middleware and back-end data, in one
place.
 Developers see these types of systems as the simplest
and most direct way.
 • The database is directly available to the user. It
means the user can directly sit on the DBMS and uses it.
 • Any changes done here will directly be done on the
database itself. It doesn't provide a handy tool for end
users.
 • The 1-Tier architecture is used for
development of the local application, where
programmers can directly communicate with
the database for the quick response.
 For example; when you install a DB in your

system and access it to practise SQL queries it


is tier-one architecture. But such architecture is
rarely used in production
1.1.2.Two-tier Architecture

 The two-tier is based on Client Server architecture.


 It is like client server application.
 The direct communication takes place between client
and server.
 There is no intermediate between client and server.
 Applications on the client end can directly
communicate with the database at the server side. For
this interaction, API's like: ODBC, JDBC are used.
 The user interfaces and application programs are run
on the client-side.
 The server side is responsible to provide the
functionalities like: query processing and transaction
management.
 To communicate with the DBMS, client-side
application establishes a connection with the
server side
 2 tier architecture provides added security to

the DBMS as it is not exposed to the end


user directly.

 A two-tier architecture is a database


architecture where
 1. Presentation layer runs on a client (PC,
Mobile, Tablet, etc)
 2. Data is stored on a Server.
1.1.3. Three-tier
Architecture
 It is an extension of the 2-tier architecture.
A 3-tier architecture separates its tiers from
each other based on the complexity of the
users and how they use the data present in
the database.
 The three tier architecture is the most

popular DBMS architecture.


 This architecture has different usages with

different applications.
 It can be used in web applications and

distributed applications. 3-tier architecture


has following layers;
 • Database server (Data) Tier − at this tier,
the database resides along with its query
processing languages. We also have the
relations that define the data and their
constraints at this level.
 • Application (Middle) Tier – also called
business logic layer and it processes functional
logic, constraint, and rules before passing data
to the user or down to the DBMS.
 This DBMS architecture contains an Application
layer between the user and the DBMS, which is
responsible for communicating the user's
request to the DBMS system and send the
response from the DBMS to the user.
For a user, this application tier presents an
abstracted view of the database.
 End-users are unaware of any existence of

the database beyond the application. At the


other end, the database tier is not aware of
any other user beyond the application tier.
Hence, the application layer sits in the middle
and acts as a mediator between the end-user
and the database.
 • User (Presentation) Tier − End-users
operate on this tier and they know nothing
about any existence of the database beyond
this layer.
 At this layer, multiple views of the database
can be provided by the application.
 All views are generated by applications that
reside in the application tier. Example your PC,
Tablet, Mobile, etc.)
 • The goal of Three-tier architecture is:
  To separate the user applications and
physical database
  Proposed to support DBMS characteristics
  Program-data independence
  Support of multiple views of the data
• N-tier architecture:
 N-tier architecture (or multi-tier architecture)
is a software architecture pattern that
separates an application into multiple layers
or tiers.
 Each tier is a separate component that can

be developed, deployed, and maintained


independently. This separation allows for
greater scalability, flexibility, and
manageability.
 Presentation Tier (Client Tier)
 Functionality: This is the front-end layer that interacts with
users. It displays information and collects user input.
 Examples: Web browsers, mobile applications, or desktop
applications.
 Application Tier (Business Logic Tier)
 Functionality: This middle layer processes the business
logic and serves as an intermediary between the
presentation and data tiers. It handles data processing,
business rules, and application logic.
 Examples: Web servers (e.g., Apache, Nginx), application
servers (e.g., Tomcat, JBoss).
 Data Tier (Database Tier)
 Functionality: This layer manages data storage and
retrieval. It consists of the database and the data access
logic.
 Examples: Database management systems (e.g., MySQL,
Oracle, MongoDB).
 Interaction Flow in N-Tier Architecture
 User Interaction: A user interacts with the
application in the presentation tier (e.g., submits a
form).
 Request to Application Tier: The presentation tier
sends a request to the application tier, which
processes the input and applies business logic.
 Database Access: The application tier
communicates with the data tier to retrieve or store
data, executing the necessary queries.
 Response to Application Tier: The data tier sends
the requested data back to the application tier.
 Display Results: The application tier processes the
data and sends a response back to the presentation
tier, which displays the results to the user.
Risks and Failure Scenario
 In a database environment, understanding
potential risks and failure scenarios is crucial
for ensuring data integrity, availability, and
security. Here are some common risks and
failure scenarios along with their implications:
 . Data Corruption
 Scenario: A power failure occurs while a
transaction is being processed, leading to
corrupted data records.
 Implications: Data integrity is compromised,
and recovery may require restoring from
backups, which could lead to data loss.
Hardware Failure

 Scenario: A hard disk fails, causing the database


server to crash and become inaccessible.
 Implications: Users cannot access the database
until the hardware is repaired or replaced, leading
to downtime.
 Software Bugs
 Scenario: A software bug in the database
management system results in incorrect query
execution or data retrieval.
 Implications: Users may receive inaccurate data,
which can lead to poor decision-making and loss
of trust in the system.
Network Issues

 Scenario: Network latency or a complete loss of


connectivity between the application tier and the
database server.
 Implications: Applications may experience
timeouts or failures in data retrieval, leading to a
poor user experience.
 . Security Breaches
 Scenario: Unauthorized access to the database
due to weak authentication mechanisms.
 Implications: Sensitive data may be exposed or
altered, leading to potential legal repercussions
and loss of customer trust.
 Human Error
 Scenario: A developer inadvertently deletes

critical data or misconfigures the database.


 Implications: This can lead to data loss or

application failures, requiring time and


resources to recover.
 Natural Disasters
 Scenario: A natural disaster (e.g., flood,

earthquake) damages the physical server


hosting the database.
 Implications: Data loss may occur if there is

no off-site backup, leading to prolonged


downtime and recovery efforts.
 Capacity Issues
 Scenario: The database reaches its storage

capacity due to unexpected growth in data


volume.
 Implications: System performance may

degrade, and users may be unable to add new


data until storage is expanded.
 Backup Failures
 Scenario: Scheduled backups fail due to

misconfiguration or lack of storage space.


 Implications: In the event of a failure, there may

be no recent backup to restore from, resulting in


significant data loss.

. Version Incompatibility
 Scenario: An upgrade to the database

management system causes


incompatibility with existing
applications.
 Implications: Applications may fail to

connect or operate correctly, requiring


additional development work to
resolve.
Mitigation Strategies

 To address the risks and failure scenarios


outlined above, organizations can
implement several strategies
 Regular Backups: Establish automated

backup schedules and ensure off-site


storage.
 Redundancy: Use redundant hardware and

failover systems to maintain availability.


 Monitoring and Alerts: Implement
monitoring tools to detect issues early and
alert administrators.
 Access Controls: Strengthen security

measures with robust authentication and


authorization processes.
 Testing and Validation: Regularly test

recovery procedures and validate backups


to ensure data integrity.
 Documentation and Training: Maintain

comprehensive documentation and train


staff to minimize human error.
The end !!!!!!!!!

You might also like