Losing databases unexpectedly can feel catastrophic — especially when it happens after installing something that’s supposed to help, not break things. That’s what happened when I installed MariaDB while setting up Daloradius on my Ubuntu system.

After installation, all my databases were gone, and phpMyAdmin started showing this dreaded message:

mysqli::real_connect(): (HY000/1698): Access denied for user 'phpmyadmin'@'localhost'

When I logged into the database, all my previous projects had vanished. But I eventually managed to recover everything manually — without using sudo timeshift --restore. Here’s how I did it step by step.

1. Understanding the Problem

When you install MariaDB on a system that already has MySQL, Ubuntu often treats MariaDB as a drop-in replacement for MySQL.

That means:

• MySQL is automatically removed or replaced.

• The folder /var/lib/mysql (which contains all databases) is overwritten with a fresh MariaDB data directory.

• Your old database files are not deleted from disk immediately — but they’re moved, renamed, or left behind in a previous snapshot folder (if you use Timeshift or have manual backups).

As a result, logging into phpMyAdmin or MySQL shows no user-created databases.

2. Verifying That MariaDB Overwrote MySQL

To confirm that MySQL was replaced:

mysql --version

It returned something like

mysql Ver 15.1 Distrib 10.x.x-MariaDB, for Linux (x86_64)


That meant MySQL binaries were now replaced by MariaDB. Checking databases:

sudo mariadb -u root -p

SHOW DATABASES;

Only system databases like mysql, information_schema, and performance_schema appeared — everything else was gone.

3. Removing MariaDB Completely

To restore my system, I decided to remove MariaDB entirely.

sudo systemctl stop mariadb
sudo apt purge mariadb-server mariadb-client mariadb-common -y
sudo apt autoremove -y
sudo apt autoclean

Then, I verified that no MariaDB packages were still on the system:

dpkg -l | grep mariadb

If any showed up, I manually removed them too.

4. Reinstalling MySQL

Once MariaDB was gone, I reinstalled MySQL 8.0:

sudo apt update
sudo apt install mysql-server -y

There were a few configuration prompts and minor errors like:

update-alternatives: error: alternative path /etc/mysql/mysql.cnf doesn't exist

I simply chose the default options (pressing Enter where prompted). After installation, MySQL was back, but with a fresh data directory — and, of course, no old databases.

5. Manually Restoring the Old Databases

Here’s where the manual recovery came in.

Step 1: Locate the old MySQL folder

I opened my Timeshift snapshots manually (without running restore).
Timeshift stores snapshots under:

/timeshift/snapshots/

Inside the latest snapshot folder, I navigated to:

/timeshift/snapshots/<snapshot-date>/localhost/var/lib/


Here, I found my old MySQL folder that contained all my previous .frm, .ibd, .ibdata1, and .myd database files.

Step 2: Stop the MySQL service

Before replacing anything, I stopped MySQL:

sudo systemctl stop mysql

Step 3: Backup the new (empty) MySQL folder

Just to be safe:

sudo mv /var/lib/mysql /var/lib/mysql_backup_new

Step 4: Copy the old MySQL folder from the snapshot

Then I copied my old databases back:

sudo cp -r /timeshift/snapshots/<snapshot-date>/localhost/var/lib/mysql /var/lib/mysql

(Replace <snapshot-date> with the correct snapshot folder name.)

Step 5: Set proper ownership and permissions

sudo chown -R mysql:mysql /var/lib/mysql

sudo chmod -R 755 /var/lib/mysql

Step 6: Restart MySQL

sudo systemctl start mysql

If everything went fine, the MySQL service started normally.

6. Confirming the Recovery

Once MySQL was running again, I logged in:

sudo mysql -u root -p

Then checked all databases:

SHOW DATABASES;

To my relief, all my previous databases were back exactly as they were before the MariaDB installation.

phpMyAdmin also loaded perfectly again, without the “access denied” errors.

7. Backing Up Everything Immediately

The first thing I did after recovery was back up all databases to a single .sql file:

mysqldump -u root -p --all-databases > ~/backup_all_databases.sql

That way, even if something similar happens again, I can restore everything with one command:

mysql -u root -p < ~/backup_all_databases.sql

8. Key Takeaways

• MariaDB and MySQL share the same paths — installing one can silently replace the other.
• Your old data isn’t necessarily gone — it’s just no longer linked to the running service.
• Manual restoration works if you can access old system files via Timeshift or a backup.
• Always stop the MySQL service before overwriting /var/lib/mysql, and fix file permissions afterward.
• Keep regular SQL dumps to make recovery faster next time.

This experience was a reminder that even routine installations can wipe out critical data if we’re not careful.
By manually restoring the /var/lib/mysql directory from a snapshot and resetting file permissions, I managed to recover every single database without using full system restore tools.

So, if you ever find yourself staring at an empty phpMyAdmin after a MariaDB install — don’t panic.
Your data is probably still there. You just need to bring it home.

How to Choose the Right Software Development Partner

Choosing a software development partner is like picking a co-pilot for a long journey. The right one ensures a smooth ride; the wrong one can leave you stranded.

Many businesses—especially startups and SMEs—struggle with this decision. Should you hire locally or outsource? How do you know if a developer is truly skilled or just good at selling themselves? And what about hidden costs, missed deadlines, or security risks?

In this guide, we’ll break down:
✅ Key factors to evaluate (beyond just cost)
🚩 Red flags that signal trouble
💡 Real-world tips from industry experts

By the end, you’ll know exactly what to look for—and how to avoid costly mistakes.

Step 1: Define Your Needs Clearly

Before searching for a partner, ask:

• What problem are you solving? (A new app, legacy system upgrade, AI integration?)
• What’s your budget and timeline? (Fixed cost? Agile development?)
• Do you need ongoing support? (Or just a one-time build?)

Example:
A fintech startup needing a secure mobile payment app will prioritize:
✔ Regulatory compliance (PCI-DSS, GDPR)
✔ Experienced fintech developers
✔ Post-launch maintenance

A small business wanting a basic website may focus more on:
✔ Affordable, fast delivery
✔ User-friendly CMS (like WordPress)

Pro Tip: Write a short project brief (even 1 page helps) to share with potential partners.

Step 2: Look for Technical Expertise

A. Relevant Experience

• Have they built similar projects before? Ask for case studies or demos.
• Do they understand your industry’s challenges? (E.g., healthcare needs HIPAA compliance.)

Warning Sign:
❌ "We can build anything!" (Without proof.)

B. Tech Stack Knowledge

• Do they use modern, scalable technologies? (Avoid partners stuck in outdated systems.)
• Can they explain why they chose a certain tech? (Not just following trends.)

Example:

• Web apps: React.js (frontend) + Node.js (backend)
• Mobile apps: Flutter (cross-platform) or Swift/Kotlin (native)
• AI/ML: Python, TensorFlow

Pro Tip: Ask: "How would you architect this project?" Their answer reveals depth of knowledge.

Step 3: Evaluate Communication & Transparency

Poor communication causes 60% of project failures (PMI). Look for:

✔ Clear processes (Daily standups? Weekly reports?)
✔ Timezone overlap (At least 4 hours for real-time collaboration.)
✔ Single point of contact (Avoid getting passed between 5 people.)

Red Flags:
❌ Slow email responses (24+ hours regularly)
❌ Vague answers to technical questions

Pro Tip: Do a trial task (paid) to test responsiveness before committing.

Step 4: Check Security & Compliance

A single data breach costs $4.45 million on average (IBM). Ensure your partner:

✔ Follows secure coding practices (OWASP standards)
✔ Signs an NDA & data protection agreement
✔ Has disaster recovery plans (Ask: "How do you handle breaches?")

Critical for:

• Healthcare (HIPAA)
• Finance (PCI-DSS, SOC 2)
• EU clients (GDPR)

Step 5: Compare Pricing Models

Ask:

• "What’s included in the cost?" (Hidden fees for support?)
• "How do you handle scope changes?"

Step 6: Verify Reputation

✅ Clutch.co/G2 reviews (Look for detailed feedback.)
✅ Ask for client references (Talk to past clients directly.)
✅ GitHub/Portfolio (Check code quality if possible.)

Red Flag:
❌ No portfolio or only "testimonials" from unverifiable sources.

Final Checklist Before Signing

🔲 Defined project scope & milestones
🔲 Clear contract (IP ownership, support terms)
🔲 Security protocols in place
🔲 Trial period or pilot project

Need a Reliable Partner? Try Africancscript

We’ve helped 150+ businesses build secure, scalable software with:
✔ Vetted developers in Africa (Cost-efficient, high-quality)
✔ End-to-end project ownership (From idea to launch)
✔ Transparent Agile processes (No surprise delays)

[Book a Free Consultation] → Let’s discuss your project!

Why IT Downtime Hurts (And How Proactive Monitoring Fixes It)

Imagine this: Your company’s website crashes during a major sales event. Customers can’t check out, support tickets pile up, and your team scrambles to find the issue. By the time it’s fixed, you’ve lost revenue, trust, and sleep.

This is what unplanned IT downtime looks like—and it’s more common than you think. Studies show that:

• The average business faces 14 hours of downtime per year.
• 98% of organizations say just one hour of downtime costs over $100,000.

The good news? Most outages are preventable. Instead of waiting for systems to fail, proactive monitoring spots warning signs early—like a doctor catching an illness before it becomes critical.

What is Proactive Monitoring?

Proactive monitoring means constantly watching your IT systems (servers, networks, applications) for early signs of trouble—before users even notice a problem.

How It Differs from Reactive Monitoring

• Reactive monitoring: You find out about issues after they happen (e.g., a server crashes, and your team gets alerts).
• Proactive monitoring: You detect slow performance, unusual traffic spikes, or memory leaks before they cause a full outage.
  
  

Key Strategies for Proactive Monitoring

1. Monitor the Right Things (Not Just Uptime)

Many companies only track "Is it up or down?"—but that’s not enough. You should also monitor:

• Performance metrics (CPU, memory, disk usage)
• Network latency (slow connections = early warning)
• Application errors (even small glitches can snowball)
• Security threats (unusual login attempts, malware scans)

Example: If your database server’s CPU usage hits 90% for an hour, proactive monitoring flags it before it crashes.

2. Set Up Smart Alerts (Avoid Alert Fatigue)

Too many alerts = ignored alerts. Instead:

• Prioritize critical alerts (e.g., "Server down" vs. "Disk 75% full").
• Use thresholds (Alert only if CPU stays above 85% for 10+ minutes).
• Escalate automatically (If no one responds in 15 minutes, notify the manager).

Bad Alert: "Disk space at 80%." (Might not be urgent.)
Good Alert: "Disk space at 95%—predicted to fill in 2 hours."

3. Predict Problems with AI & Automation

Modern tools use AI-driven analytics to:

• Predict failures (e.g., "This server tends to crash when memory leaks reach X level").
• Auto-fix known issues (Restart a stuck service before users complain).
• Learn from past incidents ("Last time CPU spiked like this, it led to a crash").

Example: Cloud providers like AWS use AI to auto-scale servers before traffic overloads them.

4. Test Failures Before They Happen (Chaos Engineering)

Companies like Netflix intentionally break their systems to see if monitoring catches it. You can too:

• Simulate a server crash (Does monitoring detect it instantly?).
• Flood your network (Can your tools spot abnormal traffic?).
• Test backup restores (Many backups fail when you actually need them).

Pro Tip: Start small—like randomly killing a non-critical service—and see how your team responds.

Best Tools for Proactive Monitoring

Real-World Example: How Proactive Monitoring Saved a Retailer

A mid-sized e-commerce site kept crashing during flash sales. Their old monitoring only alerted them after the site went down.

After switching to proactive monitoring, they:
✔ Spotted traffic spikes 30 mins before crashes (and scaled servers in time).
✔ Fixed a memory leak in their checkout system (before customers noticed).
✔ Reduced downtime by 80% in 3 months.

Final Tips to Get Started

1. Start small—Pick one critical system (like your main database) and monitor it deeply.
2. Train your team—Make sure they understand alerts (not just "ignore until it breaks").
3. Review incidents weekly—Ask, "Could we have caught this earlier?"
4. Automate fixes—Even simple scripts (like restarting a service) can prevent big outages.

Bottom Line

Proactive monitoring isn’t just about avoiding downtime—it’s about sleeping better at night knowing your systems are being watched 24/7. The best time to set it up? Before your next outage happens.

Need help implementing proactive monitoring? [Contact our IT experts: info@africanscript.com] for a free consultation.