I did something wrong with 20.04]

[Gnusboy]

I was able to get to get into fsck. I did a soft reboot, found the recovery mode and booted into it.
The results are what I posted a few minutes ago.
The fsck output I did seems very short and limited to sda5. There is a second partition, but I didn't use it. I planned on using it for my most important files.
I also have a 1 TB external drive that I used for important stuff. For some reason I disconnected it a month or two ago.
My old brain is filled with "I was gonna ... "

[ActionParsnip]

Try an fsck from live CD / USB. You don't need to use a fancy backup software to make a backup. Just copy import data to another drive (preferably external) or external storage system when you need to. I use a cron'd cp command which runs weekly. It's crude but absolutely works.

[TheFu]

Try an fsck from live CD / USB. You don't need to use a fancy backup software to make a backup. Just copy import data to another drive (preferably external) or external storage system when you need to. I use a cron'd cp command which runs weekly. It's crude but absolutely works.

For most end-user data, this is absolutely, 100%, truth. Only a small number of exceptions exist. Cannot say whether any user would be impacted or not. If they use ssh, scp, sftp, rsync, or any of the 50 other ssh-based connection tools, then the answer is likely yes and a cp will break those.

For some end-user files in $HOME, a cp to NTFS will drop the permissions, so at restore time, things will be broke.

For all system files, cp will drop owner, group, permissions, and probably miss some files do to access which prevents end-users from access - even if native Linux file systems are on the target disk.

Having 1 copy, no versions, of files is about 80% of what we need backups for. But if you can script a cp to run weekly, then you can script an rsync, which will be much quicker. And if you can script an rsync, you've just gotten to where scripting rdiff-backup is basically the same thing, for an single end-user.

# a cp backup script:
cp -rp  $HOME /mnt/backup/

# a simple rsync backup script:
rsync -avz  $HOME /mnt/backup/

# an simple, single-user, rdiff-backup script w/ 90days of versioned backups (if run daily):
rdiff-backup  --exclude-special-files  $HOME /mnt/backup/
rdiff-backup --remove-older-than 90d --force /mnt/backup/

The first 2 scripts create a single copy and always add new files, never delete old files. That can be a problem.
The rdiff-backup will create versioned backups, efficiently. The 2nd - 90th runs will be faster than rsync. You'll have 90d of versioned backups, probably using 1.3x the original amount of storage. Say your $HOME has 20G, then the 90 days of backups will have about 26G. Seems like a bargain to me. The --force option is there to remove all the backups made 90 days ago, even if we did 5 backups in 1 day.

All the scripts aren't too careful in excluding files that nobody needs in their backups. Things like Firefox or Chromium cache files, for example. Best to start and get too much than not enough.
All of those backup methods above create a mirror directory system, so to restore the last backup made we don't need any fancy tools. cp or nautilus or caja or any other file manager can be used - that includes the rdiff-backup areas. Just don't change any files or directories manually in the /mnt/backup/. Checksums for each file/directory are maintained. Wouldn't want to break those.

Anyway, good, versioned, backups of a single end-user's data aren't really THAT hard.

System backups require more thought and must be run as root/sudo to have access to protected files. What needs to be included and what absolutely must be excluded is a little different too. In rdiff-backup, the --exclude-special-files option prevents trying to backup a fifo, named pipe, or other special device files that would always provide never-ending data. rsync has options for that too - rsync has hundreds of options.

[Gnusboy]

It looks like the output from the fsck I ran did not post where I expected. I thought it would show as a response to THE FU's recommendations.

When I looked through the fsck output, there are a couple of things look important. I'm not sure how they affect restoring my system.

"Inodes that were part of a corrupted orphan linked list found"

"/dev/sda5: UNEXPECTED INCONSISTENCY; RUN fsck manually"

"Failure: File system check of the root filesystem failed."


The total readable output of the test is only 16 lines. Is that a usual result of a fsck?

There were lines of data that scrolled down the monitor too fast for me to read. I'm looking for a way to stop the scroll.
At the bottom, all I could see was 16 lines. I couldn't page up to see what they were and I might have missed something in the readout.

I did the fsck from a soft reboot of 20.04
There were 4 kernels listed; the first was a generic OS and the next was a recovery mode, which is what I used.
Is there another fsck that would return different information?
When the output stopped scrolling, there were 16 lines showing on the screen. I don't know if what is visible is on the screen is everything that's important.

Here's the viewable output:

Begin: running/scripts/local-premount ... done.
Begin: mounting root file system ... Begin: Running /scripts/local-top ...Done.
Begin: Running /scripts/local-premount...Done.
Begin: Will now check root file system ... fsck from util-linux 2.34
[/usr/sbin/fsck.ext4 (1) --/dev/sda5] fsck.ext4 -a -C0 /dev/sda5
/dev/sda5 contains a file system with errors, check forced.
[ 6.959270] random: crng init done ==== \54.9%
/dev/sda5:
Inode 35401772 extent tree (at level 1) could be shorter. IGNORED. /dev/sda5: Inodes that were part of a corrupted orphan linked list found.
/dev/sda5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY (I.E., WITHOUT -a OR -p OPTIONS
fsck exited with status code 4 done.
FAILURE: file system check of the root filesystem failed
the root filesystem on /dev/sda5 requires a manual fsck

BusyBox /
(initramfs)


Looking through the comments y'all were good enough to help me with,
I see the recommendations on how to do backups, which I need, but don't I have
to restore the operation of my system first?

Thank you all

[Gnusboy]

Uh, FU
Can you repeat that in ancient Greek? I might understand it better.

[TheFu]

Uh, FU
Can you repeat that in ancient Greek? I might understand it better.

I'll try. I don't speak Greek, so it is probably a little off. This is an English forum. If you really need Greek, there's probably a Greek language forum.

ή τα περισσότερα δεδομένα τελικών χρηστών, αυτό είναι απολύτως, 100%, αλήθεια. Υπάρχει μόνο ένας μικρός αριθμός εξαιρέσεων. Δεν μπορώ να πω αν κάποιος χρήστης θα επηρεαστεί ή όχι. Εάν χρησιμοποιούν ssh, scp, sftp, rsync ή οποιοδήποτε από τα 50 άλλα εργαλεία σύνδεσης που βασίζονται σε ssh, τότε η απάντηση είναι πιθανό ναι και ένα cp θα τα σπάσει.

Για ορισμένα αρχεία τελικού χρήστη στο $ HOME, ένα cp στο NTFS θα αφήσει τα δικαιώματα, οπότε κατά την επαναφορά, τα πράγματα θα χαλάσουν.

Για όλα τα αρχεία συστήματος, το cp θα αφήσει τον κάτοχο, την ομάδα, τα δικαιώματα και πιθανώς θα χάσει κάποια αρχεία που θα έχουν πρόσβαση, γεγονός που εμποδίζει την πρόσβαση των τελικών χρηστών - ακόμα και αν τα εγγενή συστήματα αρχείων Linux βρίσκονται στο δίσκο προορισμού.

Έχοντας 1 αντίγραφο, χωρίς εκδόσεις, των αρχείων είναι περίπου το 80% αυτού που χρειαζόμαστε αντίγραφα ασφαλείας. Αλλά αν μπορείτε να δημιουργήσετε σενάριο ένα cp για να εκτελείται εβδομαδιαία, τότε μπορείτε να δημιουργήσετε σενάριο ένα rsync, το οποίο θα είναι πολύ πιο γρήγορο. Και αν μπορείτε να δημιουργήσετε σενάριο ένα rsync, μόλις φτάσατε στο σημείο όπου το scripting rdiff-backup είναι βασικά το ίδιο πράγμα, για έναν μόνο τελικό χρήστη.

# εφεδρικό σενάριο cp:
cp -rp $HOME /mnt/backup/

# ένα απλό εφεδρικό σενάριο rsync:
rsync -avz $HOME /mnt/αντίγραφο ασφαλείας/

# ένα απλό σενάριο ενός χρήστη, rdiff-backup με 90 ημέρες εκδόσεων (εάν εκτελούνται καθημερινά):
rdiff-backup --exclude-special-files $ HOME   /mnt/backup/
rdiff-backup - Remove-old-than 90d --force   /mnt/backup/

Τα πρώτα 2 σενάρια δημιουργούν ένα μόνο αντίγραφο και προσθέτουν πάντα νέα αρχεία, μην διαγράφετε ποτέ παλιά αρχεία. Αυτό μπορεί να είναι ένα πρόβλημα.
Το rdiff-backup θα δημιουργήσει αποτελεσματικά αντίγραφα ασφαλείας. Το 2ο - 90ο τρέξιμο θα είναι πιο γρήγορο από το rsync. Θα έχετε 90d εφεδρικών αντιγράφων ασφαλείας, πιθανότατα χρησιμοποιώντας 1,3 φορές τον αρχικό αποθηκευτικό χώρο. Ας υποθέσουμε ότι το $ HOME σας έχει 20G και, στη συνέχεια, τα εφεδρικά αντίγραφα των 90 ημερών θα έχουν περίπου 26G. Φαίνεται σαν μια συμφωνία για μένα. Η επιλογή --force είναι εκεί για να καταργήσετε όλα τα αντίγραφα ασφαλείας που έγιναν πριν από 90 ημέρες, ακόμα κι αν κάναμε 5 αντίγραφα ασφαλείας σε 1 ημέρα.

Όλα τα σενάρια δεν είναι πολύ προσεκτικά εξαιρώντας αρχεία που κανείς δεν χρειάζεται στα αντίγραφα ασφαλείας του. Για παράδειγμα, όπως Firefox ή Chromium cache αρχεία. Καλύτερα να ξεκινήσετε και να πάρετε πάρα πολλά από ό, τι δεν είναι αρκετό.
Όλες αυτές οι παραπάνω μέθοδοι δημιουργίας αντιγράφων ασφαλείας δημιουργούν ένα σύστημα καταλόγου καθρεφτών, οπότε για την επαναφορά του τελευταίου αντιγράφου ασφαλείας δεν χρειαζόμαστε κανένα φανταχτερό εργαλείο cp ή nautilus ή caja ή οποιοσδήποτε άλλος διαχειριστής αρχείων μπορεί να χρησιμοποιηθεί - που περιλαμβάνει τις περιοχές δημιουργίας αντιγράφων ασφαλείας rdiff. Απλώς μην αλλάζετε χειροκίνητα αρχεία ή καταλόγους στο / mnt / backup /. Τα Checksums για κάθε αρχείο / κατάλογο διατηρούνται. Δεν θα ήθελα να τα σπάσω.

Τέλος πάντων, τα καλά, εκδομένα, αντίγραφα ασφαλείας των δεδομένων ενός μεμονωμένου τελικού χρήστη δεν είναι πραγματικά τόσο δύσκολα.

Τα αντίγραφα ασφαλείας του συστήματος απαιτούν περισσότερη σκέψη και πρέπει να εκτελούνται ως root / sudo για να έχουν πρόσβαση σε προστατευμένα αρχεία. Αυτό που πρέπει να συμπεριληφθεί και αυτό που πρέπει να αποκλειστεί είναι λίγο διαφορετικό. Στο rdiff-backup, η επιλογή --exclude-special-files αποτρέπει την προσπάθεια δημιουργίας αντιγράφων ασφαλείας ενός fifo, ονομασμένου σωλήνα ή άλλων ειδικών αρχείων συσκευών που θα παρέχουν πάντα ατελείωτα δεδομένα. Το rsync έχει επιλογές για αυτό - rsync έχει εκατοντάδες επιλογές.

[Gnusboy]

It looks like the output from the fsck I ran did not post where I expected. I thought it would show as a response to THE FU's recommendations.

When I looked through the fsck output, there are a couple of things look important. I'm not sure how they affect restoring my system.

"Inodes that were part of a corrupted orphan linked list found"

"/dev/sda5: UNEXPECTED INCONSISTENCY; RUN fsck manually"

"Failure: File system check of the root filesystem failed."


The total readable output of the test is only 16 lines. Is that a usual result of a fsck?

There were lines of data that scrolled down the monitor too fast for me to read. I'm looking for a way to stop the scroll.
At the bottom, all I could see was 16 lines. I couldn't page up to see what they were and I might have missed something in the readout.

I did the fsck from a soft reboot of 20.04
There were 4 kernels listed; the first was a generic OS and the next was a recovery mode, which is what I used.
Is there another fsck that would return different information?
When the output stopped scrolling, there were 16 lines showing on the screen. I don't know if what is visible is on the screen is everything that's important.

Here's the viewable output:

Begin: running/scripts/local-premount ... done.
Begin: mounting root file system ... Begin: Running /scripts/local-top ...Done.
Begin: Running /scripts/local-premount...Done.
Begin: Will now check root file system ... fsck from util-linux 2.34
[/usr/sbin/fsck.ext4 (1) --/dev/sda5] fsck.ext4 -a -C0 /dev/sda5
/dev/sda5 contains a file system with errors, check forced.
[ 6.959270] random: crng init done ==== \54.9%
/dev/sda5:
Inode 35401772 extent tree (at level 1) could be shorter. IGNORED. /dev/sda5: Inodes that were part of a corrupted orphan linked list found.
/dev/sda5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY (I.E., WITHOUT -a OR -p OPTIONS
fsck exited with status code 4 done.
FAILURE: file system check of the root filesystem failed
the root filesystem on /dev/sda5 requires a manual fsck

BusyBox /
(initramfs)


Looking through the comments y'all were good enough to help me with,
I see the recommendations on how to do backups, which I need, but don't I have
to restore the operation of my system first?

Thank you all

[Gnusboy]

I'm a little rusty. I'll have to break out my old stone tablets

[tea for one]

@TheFu

Post 16 - Classic reply but somewhat Spartan

[Gnusboy]

This is a little known tale of war. To the victors go the spoils.

After the last skirmish between Sparta and Troy, exhausted Spartans, backs turned in defeat, were captured before the trek home.
Seeing an undefended opening in the ranks, the Trojan's took hold of their spears, sheathed themselves tightly in armor and then lunged forcefully, penetrating again and again, deeply into the Spartan ranks. The Trojan warriors, formerly engorged with hard fought victory, felt their initial stiffness flagging. With the battleground awash with the spoils of war, each of them finally dropped onto the spoils of war to sleep.