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 !!!!!!!!!
