Best backup format for SSD's - KDE

On BTRFS file format, I’ve had 4 corruptions of the file system where I couldn’t recover any files. I used every recovery file command I could find. This was a main opensuse linux system.

I’ve setup a backup ssd as usb 3.00 drive. I booted up and later the drive was flashing, but never mounted. I turned the drive off. Somehow it was writing and got corrupted. (files unrecoverable).

So, i’ve doing research and BTRFS is recommended for ssd’s. But, ext4 is used on many servers for file stability.

I need experience and opinions on people here recommend and why. Thanks…

I have experience: Converted everything to btrfs and switched from rsync to btrfs send / receive. The internal backup disk of infamous host erlangen now holds 1438 full backups of system and home, altogether some 260 TB.

Backups to internal and external disks are straight forward, reliable and low in resources due to sharing of data.

Backup to external SSD using USB C:

erlangen:~ # journalctl -b -u btrbk-Crucial.service 
Dec 11 09:02:54 erlangen systemd[1]: Starting btrbk backup of /home to SSD...
Dec 11 09:05:42 erlangen btrbk[23923]: --------------------------------------------------------------------------------
Dec 11 09:05:42 erlangen btrbk[23923]: Backup Summary (btrbk command line client, version 0.32.6)
Dec 11 09:05:42 erlangen btrbk[23923]:     Date:   Mon Dec 11 09:02:54 2023
Dec 11 09:05:42 erlangen btrbk[23923]:     Config: /etc/btrbk/btrbk-Crucial.conf
Dec 11 09:05:42 erlangen btrbk[23923]: Legend:
Dec 11 09:05:42 erlangen btrbk[23923]:     ===  up-to-date subvolume (source snapshot)
Dec 11 09:05:42 erlangen btrbk[23923]:     +++  created subvolume (source snapshot)
Dec 11 09:05:42 erlangen btrbk[23923]:     ---  deleted subvolume
Dec 11 09:05:42 erlangen btrbk[23923]:     ***  received subvolume (non-incremental)
Dec 11 09:05:42 erlangen btrbk[23923]:     >>>  received subvolume (incremental)
Dec 11 09:05:42 erlangen btrbk[23923]: --------------------------------------------------------------------------------
Dec 11 09:05:42 erlangen btrbk[23923]: /
Dec 11 09:05:42 erlangen btrbk[23923]: +++ /Btrbk/btrbk_snapshots/Crucial/ROOT.20231211T0902
Dec 11 09:05:42 erlangen btrbk[23923]: >>> /Crucial/btrbk_snapshots/erlangen/ROOT.20231211T0902
Dec 11 09:05:42 erlangen btrbk[23923]: /home
Dec 11 09:05:42 erlangen btrbk[23923]: +++ /Btrbk/btrbk_snapshots/Crucial/home.20231211T0902
Dec 11 09:05:42 erlangen btrbk[23923]: >>> /Crucial/btrbk_snapshots/erlangen/home.20231211T0902
Dec 11 09:05:42 erlangen systemd[1]: btrbk-Crucial.service: Deactivated successfully.
Dec 11 09:05:42 erlangen systemd[1]: Finished btrbk backup of /home to SSD.
Dec 11 09:05:42 erlangen systemd[1]: btrbk-Crucial.service: Consumed 21.697s CPU time.
erlangen:~ # 

All siblings of infamous host erlangen backup their data on its internal backup disk:

thinkbook:~ # journalctl --since 0:00 -u btrbk
Dec 11 09:19:03 thinkbook systemd[1]: Starting btrbk backup of /home...
Dec 11 09:20:03 thinkbook check-erlangen[19782]: sleep
Dec 11 09:20:32 thinkbook btrbk[20773]: --------------------------------------------------------------------------------
Dec 11 09:20:32 thinkbook btrbk[20773]: Backup Summary (btrbk command line client, version 0.32.6)
Dec 11 09:20:32 thinkbook btrbk[20773]:     Date:   Mon Dec 11 09:20:03 2023
Dec 11 09:20:32 thinkbook btrbk[20773]:     Config: /etc/btrbk/btrbk.conf
Dec 11 09:20:32 thinkbook btrbk[20773]: Legend:
Dec 11 09:20:32 thinkbook btrbk[20773]:     ===  up-to-date subvolume (source snapshot)
Dec 11 09:20:32 thinkbook btrbk[20773]:     +++  created subvolume (source snapshot)
Dec 11 09:20:32 thinkbook btrbk[20773]:     ---  deleted subvolume
Dec 11 09:20:32 thinkbook btrbk[20773]:     ***  received subvolume (non-incremental)
Dec 11 09:20:32 thinkbook btrbk[20773]:     >>>  received subvolume (incremental)
Dec 11 09:20:32 thinkbook btrbk[20773]: --------------------------------------------------------------------------------
Dec 11 09:20:32 thinkbook btrbk[20773]: /home
Dec 11 09:20:32 thinkbook btrbk[20773]: +++ /Btrbk/btrbk_snapshots/home.20231211T0920
Dec 11 09:20:32 thinkbook btrbk[20773]: --- /Btrbk/btrbk_snapshots/home.20231210T0717
Dec 11 09:20:32 thinkbook btrbk[20773]: >>> erlangen.fritz.box:/Backup/btrbk_snapshots/thinkbook/home.20231211T0920
Dec 11 09:20:32 thinkbook btrbk[20773]: /
Dec 11 09:20:32 thinkbook btrbk[20773]: +++ /Btrbk/btrbk_snapshots/ROOT.20231211T0920
Dec 11 09:20:32 thinkbook btrbk[20773]: --- /Btrbk/btrbk_snapshots/ROOT.20231210T0717
Dec 11 09:20:32 thinkbook btrbk[20773]: >>> erlangen.fritz.box:/Backup/btrbk_snapshots/thinkbook/ROOT.20231211T0920
Dec 11 09:20:32 thinkbook systemd[1]: btrbk.service: Deactivated successfully.
Dec 11 09:20:32 thinkbook systemd[1]: Finished btrbk backup of /home.
Dec 11 09:20:32 thinkbook systemd[1]: btrbk.service: Consumed 5.397s CPU time.
thinkbook:~ # 

Backup to remote hosts works reliably in LAN and WAN.

Interesting. Can you point to more info or tutorial on how to use btrfs utilities and features for backup? Thanks.

2 Likes

What other file systems are recommended for backups for ssd’s? EXT4 for one.

Modern drives, HDDs as well as SSDs no longer perform thorough checks. Thus it’s recommended to rely on file systems doing their own checks, such as btrfs.

The video is on raid, but it addresses the underlying problem:

2 Likes

XFS or ext4, not BTRFS.

Enlightening video. So, I somehow turn it off during a sync write and corrupt the drive. I did as many commands I could enter and still couldn’t recover the data.

btrfs-rescue

btrfs restore

It would not even mount. I was learning as I reading. Neither worked. My understanding was too limited. What commands do I need to know figure out what the problem is?

EXT4 has a file journal, but that’s bad for SSDs. XFS how is it for SSDs?

Backups are critical, if you main system fails. I do manual backups, to make sure everything gets copied. With auto backup, I might miss some file folder or files added. I don’t want to wear out the backup with too many writes. So, the more critical the files, the more they get backed up. I turn off the drive until backups are needed.

1 Like

It depends. btrbk offers easy recovery from interrupted backups.

  1. Interrupt the backup:
 3400g:~ # btrbk run 
^C
ERROR: Caught SIGINT, dumping transaction log:
LOCALTIME TYPE STATUS TARGET_URL SOURCE_URL PARENT_URL MESSAGE
2023-12-22T11:06:21+0100 startup v0.32.6 - - - # btrbk command line client, version 0.32.6
2023-12-22T11:06:22+0100 snapshot starting /Btrbk/btrbk_snapshots/HDD/ROOT.20231222T1106 / - -
2023-12-22T11:06:22+0100 snapshot success /Btrbk/btrbk_snapshots/HDD/ROOT.20231222T1106 / - -
2023-12-22T11:06:22+0100 snapshot starting /Btrbk/btrbk_snapshots/HDD/home.20231222T1106 /home - -
2023-12-22T11:06:22+0100 snapshot success /Btrbk/btrbk_snapshots/HDD/home.20231222T1106 /home - -
2023-12-22T11:06:22+0100 snapshot starting /home-SSD/btrbk_snapshots/HDD/home-SSD.20231222T1106 /home-SSD - -
2023-12-22T11:06:22+0100 snapshot success /home-SSD/btrbk_snapshots/HDD/home-SSD.20231222T1106 /home-SSD - -
2023-12-22T11:06:22+0100 send-receive starting /HDD/btrbk_snapshots/3400g/ROOT.20231222T1106 /Btrbk/btrbk_snapshots/HDD/ROOT.20231222T1106 /Btrbk/btrbk_snapshots/HDD/ROOT.20231222T0603 -
2023-12-22T11:06:39+0100 signal SIGINT - - - -
3400g:~ # btrbk dryrun 
  1. Perform a dry run:
3400g:~ # btrbk dryrun 
WARNING: Target subvolume "/HDD/btrbk_snapshots/3400g/ROOT.20231222T1106" exists, but is not a receive target of "/Btrbk/btrbk_snapshots/HDD/ROOT.20231222T1106"
WARNING: Please delete stray subvolumes: "btrbk clean /HDD/btrbk_snapshots/3400g"
WARNING: Skipping backup of: /Btrbk/btrbk_snapshots/HDD/ROOT.20231222T1106
--------------------------------------------------------------------------------
Backup Summary (btrbk command line client, version 0.32.6)

    Date:   Fri Dec 22 11:06:54 2023
    Config: /etc/btrbk/btrbk.conf
    Dryrun: YES

Legend:
    ===  up-to-date subvolume (source snapshot)
    +++  created subvolume (source snapshot)
    ---  deleted subvolume
    ***  received subvolume (non-incremental)
    >>>  received subvolume (incremental)
--------------------------------------------------------------------------------
/
+++ /Btrbk/btrbk_snapshots/HDD/ROOT.20231222T1106_1
!!! /HDD/btrbk_snapshots/3400g/ROOT.20231222T1106
>>> /HDD/btrbk_snapshots/3400g/ROOT.20231222T1106_1

/home
+++ /Btrbk/btrbk_snapshots/HDD/home.20231222T1106_1
>>> /HDD/btrbk_snapshots/3400g/home.20231222T1106
>>> /HDD/btrbk_snapshots/3400g/home.20231222T1106_1

/home-SSD
+++ /home-SSD/btrbk_snapshots/HDD/home-SSD.20231222T1106_1
>>> /HDD/btrbk_snapshots/3400g/home-SSD.20231222T1106
>>> /HDD/btrbk_snapshots/3400g/home-SSD.20231222T1106_1

NOTE: Some errors occurred, which may result in missing backups!
Please check warning and error messages above.
Please delete stray subvolumes: "btrbk clean /HDD/btrbk_snapshots/3400g"

NOTE: Dryrun was active, none of the operations above were actually executed!
3400g:~ # 
  1. Delete the offending subvolume (marked with !!! above ):
3400g:~ # btrfs subvolume delete /HDD/btrbk_snapshots/3400g/ROOT.20231222T1106
Delete subvolume (no-commit): '/HDD/btrbk_snapshots/3400g/ROOT.20231222T1106'
3400g:~ # 

The drive is ready for another backup.

  1. Even removing it from the bus during another ongoing backup won’t damage the filesystem:
3400g:~ # btrbk dryrun 
--------------------------------------------------------------------------------
Backup Summary (btrbk command line client, version 0.32.6)

    Date:   Fri Dec 22 13:03:02 2023
    Config: /etc/btrbk/btrbk.conf
    Dryrun: YES

Legend:
    ===  up-to-date subvolume (source snapshot)
    +++  created subvolume (source snapshot)
    ---  deleted subvolume
    ***  received subvolume (non-incremental)
    >>>  received subvolume (incremental)
--------------------------------------------------------------------------------
/
+++ /Btrbk/btrbk_snapshots/HDD/ROOT.20231222T1303
>>> /HDD/btrbk_snapshots/3400g/ROOT.20231222T1303

/home
+++ /Btrbk/btrbk_snapshots/HDD/home.20231222T1303
>>> /HDD/btrbk_snapshots/3400g/home.20231222T1303

/home-SSD
+++ /home-SSD/btrbk_snapshots/HDD/home-SSD.20231222T1303
>>> /HDD/btrbk_snapshots/3400g/home-SSD.20231222T1303

NOTE: Dryrun was active, none of the operations above were actually executed!
3400g:~ # btrbk run 
ERROR: Failed to send/receive subvolume: /Btrbk/btrbk_snapshots/HDD/ROOT.20231222T1303 [/Btrbk/btrbk_snapshots/HDD/ROOT.20231222T0603] -> /HDD/btrbk_snapshots/3400g/ROOT.20231222T1303
ERROR: ... Command execution failed (exitcode=1)
ERROR: ... sh: btrfs send -p '/Btrbk/btrbk_snapshots/HDD/ROOT.20231222T0603' '/Btrbk/btrbk_snapshots/HDD/ROOT.20231222T1303' | btrfs receive '/HDD/btrbk_snapshots/3400g/'
ERROR: ... creating snapshot btrbk_snapshots/3400g/ROOT.20231222T0603 -> ROOT.20231222T1303 failed: Input/output error
ERROR: ... failed to check target subvolume: /HDD/btrbk_snapshots/3400g/ROOT.20231222T1303
ERROR: ... Command execution failed (exitcode=1)
ERROR: ... sh: btrfs subvolume show '/HDD/btrbk_snapshots/3400g/ROOT.20231222T1303'
ERROR: ... cannot find real path for '/HDD/btrbk_snapshots/3400g/ROOT.20231222T1303': No such file or directory
ERROR: Error while resuming backups, aborting
ERROR: Failed to send/receive subvolume: /Btrbk/btrbk_snapshots/HDD/home.20231222T1303 [/Btrbk/btrbk_snapshots/HDD/home.20231222T0603] -> /HDD/btrbk_snapshots/3400g/home.20231222T1303
ERROR: ... Command execution failed (exitcode=1)
ERROR: ... sh: btrfs send -p '/Btrbk/btrbk_snapshots/HDD/home.20231222T0603' '/Btrbk/btrbk_snapshots/HDD/home.20231222T1303' | btrfs receive '/HDD/btrbk_snapshots/3400g/'
ERROR: ... cannot open btrbk_snapshots/3400g/home.20231222T0603: Input/output error
ERROR: ... failed to check target subvolume: /HDD/btrbk_snapshots/3400g/home.20231222T1303
ERROR: ... Command execution failed (exitcode=1)
ERROR: ... sh: btrfs subvolume show '/HDD/btrbk_snapshots/3400g/home.20231222T1303'
ERROR: ... cannot find real path for '/HDD/btrbk_snapshots/3400g/home.20231222T1303': No such file or directory
ERROR: Error while resuming backups, aborting
ERROR: Failed to send/receive subvolume: /home-SSD/btrbk_snapshots/HDD/home-SSD.20231222T1303 [/home-SSD/btrbk_snapshots/HDD/home-SSD.20231222T0603] -> /HDD/btrbk_snapshots/3400g/home-SSD.20231222T1303
ERROR: ... Command execution failed (exitcode=1)
ERROR: ... sh: btrfs send -p '/home-SSD/btrbk_snapshots/HDD/home-SSD.20231222T0603' '/home-SSD/btrbk_snapshots/HDD/home-SSD.20231222T1303' | btrfs receive '/HDD/btrbk_snapshots/3400g/'
ERROR: ... cannot open btrbk_snapshots/3400g/home-SSD.20231222T0603: Input/output error
ERROR: ... failed to check target subvolume: /HDD/btrbk_snapshots/3400g/home-SSD.20231222T1303
ERROR: ... Command execution failed (exitcode=1)
ERROR: ... sh: btrfs subvolume show '/HDD/btrbk_snapshots/3400g/home-SSD.20231222T1303'
ERROR: ... cannot find real path for '/HDD/btrbk_snapshots/3400g/home-SSD.20231222T1303': No such file or directory
ERROR: Error while resuming backups, aborting
WARNING: Skipping cleanup of snapshots for subvolume "/", as at least one target aborted earlier
WARNING: Skipping cleanup of snapshots for subvolume "/home", as at least one target aborted earlier
WARNING: Skipping cleanup of snapshots for subvolume "/home-SSD", as at least one target aborted earlier
--------------------------------------------------------------------------------
Backup Summary (btrbk command line client, version 0.32.6)

    Date:   Fri Dec 22 13:03:09 2023
    Config: /etc/btrbk/btrbk.conf

Legend:
    ===  up-to-date subvolume (source snapshot)
    +++  created subvolume (source snapshot)
    ---  deleted subvolume
    ***  received subvolume (non-incremental)
    >>>  received subvolume (incremental)
--------------------------------------------------------------------------------
/
+++ /Btrbk/btrbk_snapshots/HDD/ROOT.20231222T1303
!!! /HDD/btrbk_snapshots/3400g/ROOT.20231222T1303
!!! Target "/HDD/btrbk_snapshots/3400g" aborted: Failed to send/receive subvolume

/home
+++ /Btrbk/btrbk_snapshots/HDD/home.20231222T1303
!!! /HDD/btrbk_snapshots/3400g/home.20231222T1303
!!! Target "/HDD/btrbk_snapshots/3400g" aborted: Failed to send/receive subvolume

/home-SSD
+++ /home-SSD/btrbk_snapshots/HDD/home-SSD.20231222T1303
!!! /HDD/btrbk_snapshots/3400g/home-SSD.20231222T1303
!!! Target "/HDD/btrbk_snapshots/3400g" aborted: Failed to send/receive subvolume

NOTE: Some errors occurred, which may result in missing backups!
Please check warning and error messages above.
3400g:~ # 
  1. Upon scanning the bus for the drive and remounting it the filesystem is great again:
3400g:~ # btrfs check --force /dev/sdd1
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/sdd1
UUID: 077f8a3b-ca24-4853-890c-fe38d452e1b8
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups
found 527434063872 bytes used, no error found
total csum bytes: 510774336
total tree bytes: 4798758912
total fs tree bytes: 4015669248
total extent tree bytes: 235995136
btree space waste bytes: 821979846
file data blocks allocated: 15712670470144
 referenced 2428401385472
3400g:~ # 

The xmas holiday has been really busy. I will look at this in detail soon.

FYI…

Thanks for the assistance karl and all others.

Can this form of backup do what ‘unison’ does. Only copy files that have moved, deleted, added, and changed?

Less wear on the backup ssd

Strong opinion, but zero evidence.

Self found BTRFS not so easy for myself, so went back to using ext4 and tar.

As am NOT a big data user, for backups my favourite is tar.

example tar -zcvf Archive/Docs20240117.tar.gz Documents

with size around 30G

I do like the KISS principle…
.

Snapper is NOT a backup. In essence it is a system version manager. By default it does not protect your data just keeps multiple system diffs that can be restored if needed.

1 Like

I also vote for tar -czf in a multi-stage backup system and ext4. I’ve never had any data loss with tar based backups and ext file systems in 16+ years of daily use, both private and job. .tgz storage is independent of the file system and the medium as long as the file system and medium allow for creating files of sufficient size. And if not, just using split & cat. Integrity check using tar -xzf & diff -r.

Lots of options available.

Tar has been used for a long time. As far as I know, It can compress or not compress files. Can it keep folder tree structures?

Hi, @lord_valarian , nice to see you are still around.

I played with BTRFS, did not like it, for various reasons of my own. I will not say it is no good, just that it did not suit me.

I am still using ext4, and still using Unison for backing up my Data, now on 15.5. It has served me well over the many years, has never failed, so see no need to switch either file system or Data backup method.

Large external drives were quite cheap awhile ago, so I have 4 of them and do rotating backups. One external backs once a week, #2 is once every 2 weeks, #3 is once every month, #4 is once a year.

I use CloneZilla on a USB boot key for whole disk backups (saving the structure and latest installed version in case of disk crash). I make one of those backups a couple months after upgrading to the next openSUSE version, once I am sure the new version hasn’t cost me anything vital.

I hope that helps you make your decisions.

BTW: Since you mentioned Unison, and seem to like it, why are you not just continuing to use it?

Hi @lord_valarian , I read the discussion here (Tue Jan 30 08:26:17 CET 2024) . Im somewhat familiar with the concerns and experiences of yours and of other authors here, too. I want to offer some comments about thoughts I had when reading posts and replies to this topic.

Since 2016 and to this day I have worked with BtrFS on Samsung 850 PRO SSDs in Lenovo W530 Thinkpads.
VERY happy with my hardware ever since. However, because of bold experimentations (compliled newer GNU glibc’s as there were initially on my openSUSE Leap 42.3 OS’es) my OS’es have become more vulnerable by 2020. The Leap 42.3 OS’es began to freeze, so that I pulled the plug on them on a daily basis.

Updating/upgrading was no longer possible, however, switching to openSUSE Leap 15.x was imminent these days anyway. So was it the fault of BtrFS, or - asked more precisely - was it the fault of BtrFS ALONE?

WHY might BtrFS be recommended for SSDs anyway? - I asked this question at Phind.com.

Answer | Phind V9 Model

BtrFS is recommended for use on SSDs due to several reasons:

  1. Copy-on-Write (COW) Mechanism: BtrFS uses a COW mechanism for writing data. Instead of updating data in place, it writes a new copy to a different location and then atomically switches the pointers. This method is beneficial for SSDs because it reduces the risk of write amplification, which can significantly decrease the lifespan of SSDs 4.

  2. Error Correction: BtrFS includes built-in mechanisms for error detection and correction. For instance, it uses checksums to detect and repair torn writes, which are writes that are partially completed due to power glitches or other electronic failures. This feature helps maintain the integrity of data on SSDs 4.

  3. Reduced Metadata Writes: SSDs are sensitive to metadata writes, which can quickly deplete their write cycles. BtrFS’s features like DUP block group profiles can help reduce these writes, thereby extending the lifespan of SSDs 4.

  4. Data Consistency: BtrFS ensures data consistency through its generation-based approach. Logical data updates are grouped into a generation, written on the device, and then the super block is written ending the generation. This approach helps maintain data integrity and prevents data corruption 4.

  5. Deduplication and Compression: BtrFS supports data deduplication and compression, which can help optimize the usage of SSD space. These features can reduce the amount of data written to the SSD, prolonging its lifespan 4.

Remember, while BtrFS offers many advantages for SSDs, it’s crucial to regularly monitor the health of your SSDs and ensure they are functioning correctly to extend their lifespan.

So, next I asked this: BTRFS is recommended for SSD’s. But, ext4 is used on many servers for file stability. Is using EXT4 on SSDs recommended, too, and if, why? What else could make sense on SSDs?

Answer | Phind V9 Model

Yes, using ext4 on SSDs is also recommended, although it might not provide all the advanced features that BtrFS does. Here’s why:

  1. Simplicity: Ext4 is simpler and more mature than BtrFS. It has been around for a longer time and is more widely supported across various systems. This simplicity can make it easier to manage and troubleshoot issues 4.

  2. Stability: As you mentioned, ext4 is commonly used on servers for file stability. It provides robust support for large file systems and handles errors well, making it a reliable choice for critical applications 1.

  3. Compatibility: Ext4 is compatible with a wide range of Linux distributions and other operating systems, which can be advantageous when working in heterogeneous environments 4.

Other filesystems that could be considered for SSDs include F2FS and XFS. These filesystems have specific advantages over ext4 and BtrFS depending on the use case:

  1. F2FS: This filesystem is designed specifically for NAND flash memory-based storage devices (like SSDs). It supports wear leveling and bad block management, which can help extend the lifespan of SSDs 4.

  2. XFS: XFS is known for its high performance and scalability. It supports large files and file systems, and it can handle large amounts of data efficiently. However, it lacks some of the advanced features found in BtrFS 4.

In conclusion, the choice between ext4, BtrFS, F2FS, and XFS depends on your specific needs and the nature of your workloads. Each filesystem has its strengths and weaknesses, and understanding these can help you make an informed decision.

So far to my encounter with Phind.com of today.

One last point comes to my mind. In my view, it would probably be beneficial if we mentioned more the reasons WHY we did what we did when issues would arise. The topic here reads “Best backup format for SSD’s - KDE”. However, nobody complains about KDE here if I am correct. If that’s true then let’s focus on “backup” for my closing remark here.

As Phind.com says, the choice between Btrfs, EXT4 or others depend s on the specific needs and the nature of workloads. However, in reality, in my view it depends also on our current state of knowledge and experience with certain technologies. What if BtrFS is new to you but it’s EXT4 that is mastered by you? How detrimental can it be if you use EXT4 instead of BtrFS? How much time is really to be saved if using X is said to be produce faster outcomes than Y? All to often manifest advantages are there, sure, but what if doing it the old-fashioned way is doing okay, too?

@lord_valarian , did you compare using BtrFS AND EXT4 on two separate partitions on your SSD? What if the driver or at least only the current VERSION of it in use just isn’t a good fit for using BtrFS on it, but using EXT4 would be somehow okay, even if we had no immediate explanation at hand why that might be so? Can we rule out such from the beginning?

Even if I did not provide all the answers - or any answer for that - I still hope that my comment might be of some faint inspiration. Maybe searching for the “best” solution for one’s problem is worth while indeed. And maybe doing just okay with the “second best” solution - at least for the time being - is no shame either?

Regards, M.

3 Likes

Can it keep folder tree structures?

Yes, and there are options for specifying how to handle hard- or soft-links and options for compressing the tar’ed directory tree by gzip, bzip2 or xz, for example.

Well, I do frequent backups, about once a week - critical files. Game files are huge now and take forever to download, 110 hours total for one game! Before, I got the large SSD I didn’t backup those files. The whole win10 system hd got corrupted or something happened. Then, I got myself the 2tb ssd.

For a long time, I didn’t use the upgrade function of opensuse. It rarely works. I backup all my folders. (before flash 256gb, now 2tb ssd saberent usb 3.00). Then, I wipe the main ssd - all partitions erased. Do a clean install and new admin password. Restore all from backups. With the SSD saberent, it’s fast.

Unison works well, but it has some drawbacks. I get lots of ‘?’ files, usually an issue of permissions. If don’t want it to backup a file. no longer needed, I have to delete the file manually on the main and backup. Sometimes folder structures don’t get copied and/or I end up with duplicate files.

The drawbacks are few and it’s saves so much time. As for BTRFS, i’m staying with it for now. If dies again, i’m switching to ext4 for backups.

Signup was in 2008. After putting up so many winx hassles, someone recommended opensusellinux - v9.1 - I think. I do all my business and personal on Opensuse. Complete disk corruption was usually my fault and system crashes are so rare. Currently, one libree office writer crash and well nothing else. The issue with proton vpn GUI, asking for the admin password 3+ times. See polkit solution and trying to figure out how to use it. A bug in the KDE GUI with openfolder. Recent files, I figured out how to turn that off. Feature after feature, I keep tripping over. It can do that. Still need to turn off web results in start menu. (Too many questions for the forums).

No, winx extra junk to uninstall or figure out to uninstall, if you can uninstall it, ARG! Every search on the bar, giving you web results. Complex to turn it off. Thank you to opensuse coders…

I was using all free software. Then, I thought with my programing skills I can give back. So, I started the scanvirus project in 2021 about. It’s a full bash command line and GUI. As professional looking as I make it. Clamscan AV was great, but it was lacking in features. So, I built the command line function, using it as the engine. Then, the GUI on top of that. Even better, I think clamscan added the scan start and end times and dates after seeing my code. :grinning:

I tried a C version, but I was just too complex and security was bad. So, I’m now master of bash and KDE GUI. I’ve done so much in scanvirus. I’m out of ideas, for now. :wink: