@arjay_mccandless: Database backups usually evolve in 3 stages: 1. Periodic backups Taking a full copy of the database on a schedule, like once a day or once a week. Simple, but you can lose everything that changed after the last backup. 2. Differential backups Backing up only the data that changed since the last full backup. This saves time and storage while giving you more frequent recovery points. 3. WAL + PITR Write-ahead logging records changes before they are applied to the database. With point-in-time recovery, you can restore a base backup, replay the logs, and recover to a specific moment before something went wrong. #coding #programming #systemdesign
Would love to learn more about system design. Where can I start?
2026-04-29 19:04:58
58
m :
Incremental backups aren't the best solution for backing up frequently changing data. Let’s say we have a version with a log. If even the slightest error ever occurs in the log, all future logs are simply worthless—for example, if the log for adding a product is corrupted, all subsequent operations on it are worthless because when the database is restored, that object simply won’t exist. The best option is to use a network file system cluster, such as GlusterFS, and host the database on an iSCSI share. With this solution, backups and database functionality are separate systems, and in the event of a system failure, we can restore the entire database within a minute.
2026-05-16 14:54:47
1
jacob_gibbons44 :
Why write to the log before writing to the database as opposed to after? Is the point of this so you log “what the database should look like” at a given point in time rather than “what does the database actually look like” at a given point in time?
2026-04-29 22:20:31
6
msdvasilis :
would that make the transaction slower or are they two different services ?
2026-04-29 18:29:03
5
WingDingKing :
transaction log backups is literally how DB replication works. you've already enabled it the moment you replicate your db
2026-05-03 04:07:22
0
dmme :
software engineers are over paid - thanks to ai - ya salaries are going down
2026-05-16 11:42:10
0
Fabi_ :
Replay is way cooler
2026-04-29 18:07:51
7
Mr.Happy :
boss level unlocked
2026-05-03 08:00:36
0
why am i still here :
just one database for everything😏
2026-05-03 21:41:23
0
PumpGang909 :
Is the write atomic ?
2026-05-05 19:03:42
0
Diego Jancic | Software & AI :
Most major relational DBs already do transaction logging by default. The backups just need to be configured correctly.
Also, there are other things to pay attention to, such as IOPS, backup compression, etc. The best solution nowadays might be to use a provider that does all this out of the box.
2026-05-04 22:29:21
1
Jo23 :
nah im just remember it every single of row my database
Writing to the log first would add more latency to the system and you’d have to decide whether you want it to be sync or async …. Depending on your use case and durability preferences
2026-04-30 23:37:38
0
RasTarbei :
This is better than university, you have a YT channel?
2026-05-11 12:57:15
0
George Goosen :
most databases already have redo logs, and most strategies use a combination of what you're describing here
2026-05-01 04:46:48
1
anonyxbiz :
replaying is way more efficient
2026-04-29 19:27:38
0
WingDingKing :
the pro differential needs to still occasionally do a full backup unless he wants to wait 7-10 business days to replay months of backups
2026-05-03 04:08:41
1
yellowtoaster7 :
why dont you ask your ai agent bro?
2026-04-29 23:49:57
0
Zach M :
Patroni and pgBackRest
2026-04-29 21:55:55
0
sheesh :
no immutable backup?
2026-06-28 09:37:25
0
Duckie Man :
I prefer differential
2026-04-30 15:06:58
0
user5568804933951 :
is the replay feature provided by service providers?
2026-04-30 09:35:52
0
createwithfar :
This is good to know
2026-04-29 23:55:01
0
Henry Newman :
With MySQL doesn't it hang the database when running SQL dump?
2026-04-29 20:47:24
0
To see more videos from user @arjay_mccandless, please go to the Tikwm
homepage.