MySmartCoPilot
Ask Passes Your pass 7 days left 1 day left Last day

Your country

Tools that support it use your country for local currency, number formats, units and paper size. Your choice is saved only in this browser.

SQL (PostgreSQL, MySQL, SQLite)  Module 17 – Security: injection, privileges and data protection

Backups, restores and protecting personal data

Make backups of PostgreSQL, MySQL and SQLite that restore, test every copy, and protect personal data with masking, encryption and hashing.

  • Intermediate
  • 20 minutes
  • Examples run with sql.js 1.14.2, Python 3.14.8 and Pyodide 314.0.7
  • By MySmartCoPilot
Free: Logical and physical backups restore to different moments · A backup counts only once a restore of it passes a test · Copies of personal data need less data, masks and encryption. With a pass: 3 in-depth parts and 3 interview answers, about 14 minutes.

What you will learn

  • Create and restore logical backups in PostgreSQL, MySQL and SQLite
  • Test a backup by restoring it and comparing row counts and checksums
  • Protect personal data in copies with minimisation, masking and encryption
  • Avoid storing passwords or secrets in plain text

Before you start

What you’ll learn · Before you start

What you will learn

  • Create and restore logical backups in PostgreSQL, MySQL and SQLite
  • Test a backup by restoring it and comparing row counts and checksums
  • Protect personal data in copies with minimisation, masking and encryption
  • Avoid storing passwords or secrets in plain text

Before you start

On this page

On this page, a plain copy of a live SQLite database file held 4 orders where the database held 5, and still passed the integrity check. A backup is a copy of a database that has been restored at least once; until a restore works, it is only a file. logical backup: A backup that writes the data out as SQL statements or an archive of rows, made by pg_dump, mysqldump or SQLite's .dump. It restores into a fresh database, often of a newer version, as of the moment the dump started. write the data out as SQL statements or an archive that rebuilds it: pg_dump and pg_restore for PostgreSQL, mysqldump for MySQL, and the .dump command or VACUUM INTO for SQLite. physical backup: A backup that copies a database's files. It restores quickly, but only into the same major version and as a whole server; with an archived write-ahead or binary log it can replay changes to a chosen moment. copy the database’s files, and with the write-ahead log of PostgreSQL or the binary log of MySQL they can replay changes up to a chosen moment.

Every copy holds every customer’s personal data, so backups and the copies made from them need the protection of the live database. Protecting personal data starts with keeping less of it, masking it in copies that leave production, encrypting it on the network and on disk, and never storing passwords at all, only slow salted hashes.

Logical and physical backups restore to different moments

Flow: a logical dump restores as of when it started; physical files plus an archived log restore to a chosen moment; both get tested.The live databaseLogical backup:pg_dump, mysqldump, .dumpSQL text or an archive of rowsPhysical backup:a copy of the data filesWrite-ahead log or binary log,archived as changes happenRestore into a fresh database,as of the moment the dump startedRestore the files, then replaythe log up to a chosen momentRestore test: integrity check,row counts, checksums, and the time it tookevery changereplayed

Logical and physical backups, and the test both must pass

Text description of the diagram

The diagram starts from the live database and shows two ways to back it up.

  1. A logical backup, made with pg_dump, mysqldump or SQLite's .dump, writes SQL text or an archive of rows. It is restored into a fresh database and holds the data as of the moment the dump started.
  2. A physical backup copies the data files. Separately, the write-ahead log of PostgreSQL or the binary log of MySQL is archived as every change happens. A restore copies the files back and replays the log up to a chosen moment.

Both paths end in the same restore test: an integrity check, row counts, checksums, and the time the restore took.

Logical and physical backups
Criterion Logical dumpPhysical copy and log
Holds SQL or an archive of rowsData files and every later change
Restores to When the dump startedAny moment the log reaches
Newer version Usually yesNo
One table alone YesNo
Large databases Slow: indexes rebuiltFast: files copied
When to choose Small and medium databases, single tables, upgradesLarge databases, recovery to the minute

Two numbers describe any backup plan. The recovery point objective (RPO): How much recent data a business can afford to lose in a failure, measured in time. A backup plan of one dump a night can lose up to a day of changes. (RPO) is how much recent data you can afford to lose: with one dump a night, up to a day of it. The recovery time objective (RTO): How long a restore may take before an outage costs too much. Only a timed restore of the real database shows whether a backup plan keeps it. (RTO) is how long a restore may take before the outage costs too much. Both are promises, and only a timed restore tells you whether a plan keeps them. Walk through one day of a shop whose only backup is a nightly dump:

Timeline · 5 events in order What a nightly dump loses, and what decides how long it takes to come back Walk through one day of a shop whose only backup is a dump at 02:00, then the failure and the restore.
  1. 02:00

    The nightly dump starts

    pg_dump or mysqldump reads the database as it is at this moment. Everything committed afterwards is in no backup until the next night.

  2. 02:00 to 13:59

    The shop keeps working

    Every order, payment and refund of the morning exists only in the live database, on one server.

  3. 14:00

    The database is lost failure

    A failed disk, a dropped table or a bad deploy. The live data is gone, and the newest copy is the 02:00 dump.

  4. Recovery point

    Twelve hours of data are gone

    Restoring the dump brings the database back as it was at 02:00. That loss is the recovery point; a nightly dump promises at most a day, and a failure at 01:59 loses almost all of it.

  5. Recovery time

    Closed until the restore ends

    The shop is down while the dump is restored, its indexes rebuilt and its rows checked. How long that may take is the recovery time objective, and only a timed restore shows whether a plan keeps it.

Most teams combine the two kinds: a physical backup with an archived log for recovery to the minute, and a regular logical dump that restores anywhere, into a newer version or one table at a time. Keep at least one copy out of reach of the database server’s own credentials, in another account or a store that refuses deletes for a set time, because a mistyped command and an attacker can both reach backups that sit next to the database.

Checkpoint

Check: Logical and physical backups, RPO and RTO

  1. Question 1 of 2 A shop dumps its database every night at 02:00 and keeps no other backup. The database is lost at 14:00. How many hours of changes are lost?

    Type a number.

    Show the answer

    Answer: 12 hours

    The restore brings the database back as it was when the dump started, 02:00, so the twelve hours from 02:00 to 14:00 are lost. That is the recovery point of a nightly dump: up to a day, depending on when the failure comes.

  2. Question 2 of 2 You must bring back one table, as it was last night, into a newer major version of PostgreSQL. Which kind of backup can do it?

    Choose one answer.

    Show the answer

    Answer: A logical dump, which restores one table, into a newer version

    Logical backups restore into a fresh database, often of a newer version, and can bring back a single table; physical backups restore quickly, but only into the same major version and as a whole server.

A backup counts only once a restore of it passes a test

A copy that restores into a fresh database with the same row counts and checksums is a backup. The program below backs up a live SQLite database four ways while it is in use, then gives each copy the test a restore drill would.

Four copies of a live database, and the test each must pass Python · backup_and_restore.py 
"""Back up a live SQLite database four ways, then test each copy the way a restore test does."""
import hashlib
import pathlib
import shutil
import sqlite3

for name in ("mart.db", "mart.db-wal", "mart.db-shm", "file-copy.db", "online.db", "vacuumed.db", "restored.db"):
    pathlib.Path(name).unlink(missing_ok=True)

live = sqlite3.connect("mart.db", autocommit=True)
live.executescript("""
    CREATE TABLE customers (customer_id INTEGER PRIMARY KEY, name TEXT NOT NULL, city TEXT NOT NULL);
    CREATE TABLE orders (order_id INTEGER PRIMARY KEY, customer_id INTEGER NOT NULL REFERENCES customers, status TEXT NOT NULL);
    INSERT INTO customers VALUES (1, 'Asha Kulkarni', 'Pune'), (2, 'Vikram Nair', 'Kochi'), (3, 'Meera Rathore', 'Jaipur');
    INSERT INTO orders VALUES (101, 1, 'delivered'), (102, 2, 'delivered'), (103, 1, 'placed'), (104, 3, 'cancelled');
    PRAGMA journal_mode = WAL;
    INSERT INTO orders VALUES (105, 2, 'placed');
""")
# Order 105 is committed, but in WAL mode it sits in mart.db-wal until the next checkpoint.

shutil.copyfile("mart.db", "file-copy.db")              # 1. copying the file while the database is in use
with sqlite3.connect("online.db") as copy:              # 2. the online backup API
    live.backup(copy)
live.execute("VACUUM INTO 'vacuumed.db'")               # 3. VACUUM INTO (SQLite 3.27 and later)
dump = "\n".join(live.iterdump())                       # 4. a logical dump: SQL text that rebuilds everything
with sqlite3.connect("restored.db") as restored:
    restored.executescript(dump)


def fingerprint(path):
    """What a restore test compares: integrity, row counts and a checksum of every row in key order."""
    db = sqlite3.connect(path)
    ok = db.execute("PRAGMA integrity_check").fetchone()[0]
    counts = tuple(db.execute(f"SELECT count(*) FROM {t}").fetchone()[0] for t in ("customers", "orders"))
    rows = db.execute("SELECT * FROM customers ORDER BY 1").fetchall() + db.execute("SELECT * FROM orders ORDER BY 1").fetchall()
    db.close()
    return ok, counts, hashlib.sha256(repr(rows).encode()).hexdigest()[:12]


expected = fingerprint("mart.db")
print(f"{'live database':14} integrity={expected[0]} rows={expected[1]} checksum={expected[2]}")
for path in ("file-copy.db", "online.db", "vacuumed.db", "restored.db"):
    ok, counts, digest = fingerprint(path)
    verdict = "restores correctly" if (ok, counts, digest) == expected else "FAILS the restore test"
    print(f"{path:14} integrity={ok} rows={counts} checksum={digest}  {verdict}")

Output

live database  integrity=ok rows=(3, 5) checksum=011ac06f2bfd
file-copy.db   integrity=ok rows=(3, 4) checksum=324ecc947a20  FAILS the restore test
online.db      integrity=ok rows=(3, 5) checksum=011ac06f2bfd  restores correctly
vacuumed.db    integrity=ok rows=(3, 5) checksum=011ac06f2bfd  restores correctly
restored.db    integrity=ok rows=(3, 5) checksum=011ac06f2bfd  restores correctly

Recorded with Python 3.14.8 on macOS 26 arm64. To run it yourself: mise exec python@3.14.8 -- python3 backup_and_restore.py

Three copies restore correctly, and the plain file copy fails the test. Step through why it missed order 105:

Interactive · step by step Why a plain copy of a live database missed order 105 Step through the backup of mart.db in WAL mode. Watch where the last committed order is when each copy is made.
Why a plain copy of a live database missed order 105, step 6 of 6. Showing mart.db, mart.db-wal (order 105, committed), file-copy.db (4 orders), online.db (5 orders). In focus: file-copy.db, online.db.copies one filereads through SQLitemart.dborders 101 to 104mart.db-walorder 105, committedfile-copy.db4 ordersonline.db5 orders

The drawing shows the whole scene; its 6 steps are listed below.

Every step as text
  1. Four orders in the main file. mart.db holds three customers and orders 101 to 104. Then PRAGMA journal_mode = WAL switches the database to write-ahead logging.
  2. Order 105 is committed. The INSERT of order 105 commits, and in WAL mode the commit is appended to mart.db-wal. mart.db stays as it was until the next checkpoint.
  3. Copying the file. shutil.copyfile copies mart.db alone while the database is in use. The copy has 4 orders: order 105 was never in the file it copied.
  4. The copy looks healthy. file-copy.db opens without complaint and passes PRAGMA integrity_check. Nothing about it says that an order is missing.
  5. Copies through SQLite. The backup API, VACUUM INTO and the dump read the database through SQLite, which reads the write-ahead log as well, so each of them has all 5 orders.
  6. The restore test decides. Compared with the live database, rows (3, 5) and its checksum, three copies match and the file copy fails the test. Opening a copy proves nothing; comparing it does.

The database runs in WAL mode, where a commit first goes to the file mart.db-wal and reaches mart.db only at the next checkpoint. The copy looks healthy, passes the integrity check and opens without complaint, which is exactly why a backup has to be compared with its source, not just opened. The backup API, VACUUM INTO and the dump all read through SQLite itself, so they see every committed transaction.

Key idea

A restore test checks three things, the engine’s integrity check, every table’s row count and a checksum over the rows in key order, and it is timed, because that time is your real recovery time.

Run it on a schedule. On PostgreSQL and MySQL the drill is the same: restore into a scratch server, compare each table’s row count and checksum with the source, and record how long it took.

Checkpoint

Check: Testing a backup by restoring it

  1. Question 1 of 2 The live database held 5 orders when the script copied the file mart.db. How many orders did the plain file copy hold?

    Type a number.

    A hint

    Where was order 105 when the file was copied?

    Show the answer

    Answer: 4 orders

    Order 105 was committed into mart.db-wal and had not reached mart.db, which the copy took alone. The copy held 4 orders, opened without complaint and passed the integrity check, and only the comparison with the source showed that it was incomplete.

  2. Question 2 of 2 Which checks does a restore test make on a restored copy?

    Choose every answer that is right.

    Show the answer

    Answer:

    • Every table has the expected number of rows
    • The engine's integrity check passes
    • A checksum over the rows in key order matches the source

    A restore test checks integrity, row counts and a checksum over the rows in key order, and records how long the restore took, because that time is the real recovery time.

Copies of personal data need less data, masks and encryption

Protecting personal data in copies follows four rules:

  • Minimisation: a column no purpose needs is not collected, and a copy leaves out what its users do not need.
  • Masking: copies for development, testing or analytics replace names, phone numbers and other identifiers with stand-ins that keep their format and their joins.
  • Encryption: connections use TLS, disks and backup files are encrypted, and the keys live apart from the data.
  • Password hashing: the application stores a slow, salted hash for each password, never the password itself and never md5() computed in SQL.

Step through the four rules on one request, a copy of production for developers:

Interactive · stage by stage A copy of production for developers, rule by rule Step through the four rules on one request. Each step decides what the copy may still contain.
A copy of production for developers, rule by rule, step 5 of 5. Showing A copy is requested, Minimise, Mask the identifiers, Encrypt it, Hand it over. In focus: Hand it over.A copy is requestedto debug the ordersMinimiseonly what the bug needsMask the identifiersstand-ins, joins keptEncrypt itthe link and the fileHand it overa copy without real people

The drawing shows the whole scene; its 5 steps are listed below.

Every step as text
  1. The request. Developers chasing a bug in orders ask for a copy of production. A straight copy would hand them every customer's name, phone number and address.
  2. Keep less. Minimisation first. The copy takes the tables the bug touches and leaves out the columns no test needs; data that is not copied cannot leak.
  3. Replace who people are. Masking replaces names, phone numbers and other identifiers with stand-ins that keep their format and their joins, so the queries of the bug still work.
  4. Protect the file. The copy travels over TLS, and the file is encrypted with a key that lives apart from it.
  5. Passwords were never there. The users table holds only the slow, salted hashes that the application computed, never a password, so even this copy holds none.

These rules apply to backups as much as to copies: a dump restored on a laptop is a copy of production with every protection of the server removed. Secrets such as API keys and tokens belong in a secrets manager rather than in a table, because every dump copies every table it covers, and a dump travels further than the database ever does.

Checkpoint

Check: Protecting personal data in copies

  1. Question 1 of 2 A developer restores last night's production dump on a laptop to reproduce a bug. What has happened to the customers' personal data?

    Choose one answer.

    Show the answer

    Answer: It now sits on the laptop with every protection of the server removed

    The rules of the lesson apply to backups as much as to copies: keep less, mask identifiers in copies that leave production, encrypt the files and the connections, and store only slow, salted password hashes.

  2. Question 2 of 2 Why do API keys and tokens belong in a secrets manager rather than in a table?

    Choose one answer.

    Show the answer

    Answer: Every dump copies every table it covers, and a dump travels further than the database ever does

    Backups and copies multiply wherever a table goes. A secret kept in a secrets manager is not in the dump at all.

Dump and restore in PostgreSQL, MySQL and SQLite, step by step Pro

Each engine’s dump tool has a default that surprises people at their first real restore. This part runs the dump and restore commands of each engine with measured sizes and times, and reproduces a restore that overwrote a live MySQL database.

In this part:

  • Dump and restore with PostgreSQL’s tools, measured
  • mysqldump, and the restore that replaced a live database, reproduced
  • SQLite: copies that are safe while the database is in use
  • Point-in-time recovery and the two objectives, worked

3 runnable examples (dump_formats.py, dump_restore.py, mysql_server.py, pg_server.py, restore_checks.py) · about 6 minutes

Opening this part with your pass…

This part opens with any MySmartCoPilot pass.

  • Pro pass · 1 week₹79$2.99
  • 30 days₹179$5.99
  • 1 year₹1,699$45

One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.

Choose a passI have a licence key

It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).

A masked copy that keeps joins working, built and checked Pro

Developers and testers need realistic data, and a straight copy of production also hands them every customer’s phone number. This part builds a masked copy that keeps joins, uniqueness and foreign keys intact, checks it automatically, and ends with an exercise.

In this part:

  • What to mask, keep or drop
  • Consistent masking with a keyed mapping, run in your browser
  • Why keeping the last four digits is not masking, worked
  • Your turn: mask phone numbers without breaking the join
  • Mask phone numbers without breaking a join
    • Results of the sample tests

2 runnable examples (Python) · 1 exercise with sample tests · about 5 minutes

Opening this part with your pass…

This part opens with any MySmartCoPilot pass.

  • Pro pass · 1 week₹79$2.99
  • 30 days₹179$5.99
  • 1 year₹1,699$45

One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.

Choose a passI have a licence key

It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).

Passwords, secrets and encryption, with the failures reproduced Pro

Hashing inside SQL looks safe and is not, and encryption helps only when its key lives somewhere else. This part reproduces what a leaked column of unsalted hashes gives away, stores passwords the way current guidance asks, and places encryption keys and logs where they protect anything.

In this part:

  • What a leaked md5 column gives away, reproduced
  • Password hashing parameters, with the memory worked out
  • Encryption in transit, at rest and in backup files
  • Logging access to sensitive tables

2 runnable examples (Python, key_in_log.py, pg_server.py) · about 5 minutes

Opening this part with your pass…

This part opens with any MySmartCoPilot pass.

  • Pro pass · 1 week₹79$2.99
  • 30 days₹179$5.99
  • 1 year₹1,699$45

One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.

Choose a passI have a licence key

It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).

Practise: back up, test and protect

The questions cover the two kinds of backup, the restore test and the rules for copies, weakest idea first:

Practice that adapts to you

Practise this lesson

9 questions about 6 ideas of this lesson. Each answer is explained at once, and what you get right is kept in this browser.

  1. Question 1 of 9 What is the difference between a logical and a physical backup?

    Choose one answer.

    Show the answer

    Answer: A logical backup writes the data out as SQL or an archive of rows; a physical backup copies the database's files

    pg_dump, mysqldump and SQLite's .dump make logical backups; a copy of the data files is physical, and with the archived write-ahead log of PostgreSQL or the binary log of MySQL it can replay changes up to a chosen moment.

  2. Question 2 of 9 Which plan can bring a database back to 13:55, five minutes before a mistake at 14:00?

    Choose one answer.

    Show the answer

    Answer: A physical backup with the write-ahead log or binary log archived as changes happen, replayed up to 13:55

    Logical dumps restore the moment the dump started. Physical backups plus an archived log restore any moment the log reaches, which is why most teams combine the two kinds.

  3. Question 3 of 9 Management asks how long a recovery will take. Which number answers it honestly?

    Choose one answer.

    Show the answer

    Answer: The measured time of a restore test of your own database, on the hardware you would restore to

    Two numbers describe a backup plan: the recovery point objective, how much recent data may be lost, and the recovery time objective, how long a restore may take. Both are promises that only a timed restore can test.

  4. Question 4 of 9 An SQLite database runs in WAL mode. A script copies only the file mart.db while the application is running. What can the copy be missing?

    Choose one answer.

    Show the answer

    Answer: Committed transactions that are still in mart.db-wal and were not yet checkpointed into the main file

    Copy the database with the backup API, VACUUM INTO or the .backup command, which see every committed transaction.

  5. Question 5 of 9 Which check turns a backup file into a backup you can rely on?

    Choose one answer.

    Show the answer

    Answer: Restoring it into a fresh database and comparing integrity, row counts and checksums with the source

    A copy can be made without an error and still miss rows: the file copy did, and it even passed the integrity check. Only a restore compared with the source shows that the copy rebuilds the data, and timing it tells you how long a real recovery would take.

  6. Question 6 of 9 Why run the restore test on a schedule, and time it, instead of once when the backups are set up?

    Choose one answer.

    Show the answer

    Answer: Data and schemas change, so a backup that restored last year may not restore now, and the time it takes is the real recovery time

    Run the test on a schedule and time it. On PostgreSQL and MySQL the drill is the same: restore into a scratch server, compare each table's row count and checksum with the source, and record how long it took.

  7. Question 7 of 9 Which of these are rules for protecting personal data in copies?

    Choose every answer that is right.

    Show the answer

    Answer:

    • Encryption of connections, disks and backup files, with the keys kept apart
    • Minimisation, so a copy leaves out what its users do not need
    • Masking names, phone numbers and other identifiers with stand-ins that keep their format and joins

    The four rules are minimisation, masking, encryption and password hashing with a slow, salted hash, never the password itself and never md5() computed in SQL.

  8. Question 8 of 9 Why keep at least one backup out of reach of the database server's own credentials?

    Choose one answer.

    Show the answer

    Answer: A mistyped command and an attacker can both reach backups that sit next to the database

    Keep at least one copy in another account or in a store that refuses deletes for a set time, so that one mistake or one stolen credential cannot remove the database and its backups together.

  9. Question 9 of 9 Which way of storing passwords do the four rules allow?

    Choose one answer.

    Show the answer

    Answer: A slow, salted hash of each password, computed by the application

    The fourth rule: the application stores a slow, salted hash for each password, never the password itself and never md5() computed in SQL.

Interview questions

  1. Fresher to mid · Warm-up

    What is the difference between a logical and a physical database backup?

    A logical backup writes the database out as SQL statements or an archive of definitions and rows, made by tools such as pg_dump, mysqldump or SQLite's .dump. It restores into a fresh database, often of a newer version or, with some edits, another engine, and can bring back a single table, but it reflects only the moment the dump started and a restore rebuilds every index, which is slow for large databases. A physical backup copies the database's files. It restores quickly, but only into the same major version, and only as a whole server. Combined with the archived write-ahead log of PostgreSQL or the binary log of MySQL, it can replay changes up to a chosen moment, which a nightly dump cannot. Either kind counts only once a restore of it has been tested.

  2. Mid to senior

    Your company has taken a nightly pg_dump of a 200 GB PostgreSQL database for two years, and nobody has ever restored one. Design the restore test, and say which numbers you report to management.

    First step and follow-ups

  3. Mid to senior

    Developers ask for a copy of production to debug a payment issue. The tables hold names, phone numbers and addresses of 2 million customers. What do you give them, and how do you build and check it?

    First step and follow-ups

  4. Mid to staff

    A database dump containing md5(password) values for 500,000 users has leaked. What can an attacker do with it, and how do you move every account to a safe scheme without forcing all users to reset their passwords?

    First step and follow-ups

Key takeaways

  • Logical dumps restore the moment they started and travel between versions, while physical backups with an archived log restore any moment the log reaches.
  • A backup counts only once a restore of it has passed an integrity check, row counts and checksums, and was timed.
  • Use the engine’s own tools to copy a live database, because a plain file copy can miss committed changes.
  • Copies that leave production keep less data, mask identifiers consistently and are encrypted, and passwords are only ever stored as slow, salted hashes.

Terms in this lesson

logical backup
A backup that writes the data out as SQL statements or an archive of rows, made by pg_dump, mysqldump or SQLite's .dump. It restores into a fresh database, often of a newer version, as of the moment the dump started.
physical backup
A backup that copies a database's files. It restores quickly, but only into the same major version and as a whole server; with an archived write-ahead or binary log it can replay changes to a chosen moment.
recovery point objective (RPO)
How much recent data a business can afford to lose in a failure, measured in time. A backup plan of one dump a night can lose up to a day of changes.
recovery time objective (RTO)
How long a restore may take before an outage costs too much. Only a timed restore of the real database shows whether a backup plan keeps it.

References

Related tools

Hash Generator Hashes and HMACs of text or huge files, plus checksum verification. CSV Data Anonymizer (PII Masking) Mask, pseudonymise, fake or generalise the personal data in each column, on your device. Argon2 Hash Generator & Verifier Argon2id hashes with OWASP and RFC 9106 settings, made and checked on your device. File Encryption & Decryption Lock any file with a password — big files too — and unlock it on any device. SQLite Viewer & Editor Look inside any SQLite database and change it; with a pass, download the result.

Report a problem with this lesson