It is the "world #backup day", at least according to WorldBackupDay.com. I like the idea of having such a day, to serve as another nudge and a reminder to make and check backups, though WorldBackupDay.com is awkward, does not mention rsync in its software section. The "com" TLD looks suspicious, too, but it is better than nothing (except for potential private data leaks with online backup services).
I use primarily encrypted external HDDs (#ZFS or #LUKS with #ext4) and #rsync for personal backups, including rsync with "--dry-run --checksum" for scrubbing and checking before synchronization; quite happy that such tools are available, even though they are usually taken for granted, as are many other neat FLOSS tools we use regularly. Planning to add a USB stick to the list of storage devices, since it should be less fragile mechanically (even though less reliable otherwise).
My first week of daily driving pmOS edge, or: "Having your dogfood and eating it too"
Intro
I got a Oneplus 6 2.5 years ago, to play around with Linux on mobile. My other phone, an old Android, partially broke its screen last fall. The writing was on the wall, as the cracks crept ever further. Last week it was no longer usable, as the screen began sensing touch inputs erratically, without being touched.
In my opinion btrfs is a better filesystem for the 'portable device' usecase than #ext4 is. Data integrity and easy recovery of b0rked systems is so nice.
Don't pull the circuit breaker of your NAS while it's doing things.
I've never seen a filesystem that messed up—and I did live through the "fedora corrupts #ext4 badly during hibernate/resume" in the 2010s.
At this rate, it looks as if I lost critical #borgbackup repository metadata of a bunch of less important repositories. The more important one at least is able to start a borg check, so I'm hopeful it won't be a total loss.
Non-backup data seems to be unaffected as the only workload running at the time was backup jobs, luckily. And I still have the offsite backups, so there is that.
I wonder why #debian did not pull the kernel deb package 6.1.64-1 with the #ext4 corruption bug from the package repositories. Countless of systems were upgraded to to buggy version as a result. Is there some technical reason why this could not be done? https://www.debian.org/News/2023/2023120902
There is a problem in multiple stable kernel releases that is causing data corruption in ext4 filesystems. It is caused by a problematic commit that is in multiple stable kernels.
It has delayed the release of Debian 12.3 images.
"Please do not upgrade any systems at this time, we urge caution for users with Unattended Upgrades configured."
Due to an issue in ext4 with data corruption in kernel 6.1.64-1, we are a pausing the 12.3 image release for today while we attend to fixes. Please do not update any systems at this time, we urge caution for users with UnattendeUpgrades configured.
The #ext4 data corruption issue[1] in #Linux#kernel v6.1.64 and v6.1.65 that was fixed with #LinuxKernel 6.1.66[2] apparently hit #Debian 12.3 bookworm point release[3]. Fixes are in the works, but preparing them will take a bit[4].
I did the ardurous process of migrating all my stuff from #NTFS to #LUKS-encrypted #ext4 on all drives and it just works so flawlessly on every Linux machine...
#ReiserFS fliegt 2025 aus dem Linux-Kernel raus. Vor vielen Jahren fand ich das Dateisystem noch ganz toll, inzwischen gibt es einfach viel bessere Alternativen.
Ich nutze bei meinen Linux-Systemen eigentlich immer #ext4 mit #LVM - was nehmt Ihr so?
Utterly stumped on solving this drive mount issue. Other drives have resized without issue, no lost files or mangled hashsums, but this one particular drive is giving me trouble... and nothing online gives a conclusive answer...
> Après plusieurs articles sur la FAT32, NTFS, HFS+ ou encore APFS, il est temps de se tourner vers l’univers Linux, et plus particulièrement les deux systèmes de fichiers que l’on y trouve le plus souvent : #ext4 et #Btrfs. Ils se côtoient souvent, mais leur fonctionnement est très différent.
Je me souviens avoir testé Btrfs. J'ai jamais vraiment compris comment m'en servir.
People frequently say they don’t want #ZFS on their workstation because it’s a server FS. But what’s the best workstation FS? #UFS, #Ext4, #HAMMER, #Btrfs, #XFS? What’s the going benchmark workload look like? What subjective aspects matter too? (And yes, I know about damned lies of https://fsbench.filesystems.org/)
After reading up on BTRFS and some experiments in VMs, I think for my proposed deploy - Debian 12 as the sole OS on a single SSD (with loads of free space) on my laptop - for the time being I'm going to stick with using LUKS + LVM + separate LVs for root and home using ext4 on both. BTRFS adds a layer of complexity in exchange for features (such as snapshots and compression) I would personally have little use for.
Interesting stuff this copy-on-write (COW), though.