Πανικός! Κατά λάθος έκανα initialize στα Windows τον 3TB storage ΕΧΤ4 δίσκο μου!

Αντιμετώπιση προβλημάτων
, , ,
1

Ενός κακού μύρια έπονται… Κατά τις εργασίες μου για την επαναφορά ενός laptop γνωστού προσώπου, αντί να κάνω format έναν εξωτερικό SSD για να τον μετατρέψω σε bootable windows media, από miss click και βιασύνη έκανα initialize τον ext4 3TB “storage” δίσκο μου. Εκείνη τη στιγμή δεν έδωσα σημασία, καθώς θεωρούσα ότι το initialize ήταν κάτι τύπου “mount” και ότι δεν έγινε κάτι στον δίσκο. Προχώρησα με τις υπόλοιπες εργασίες μου και καθ’ όλη τη διάρκεια της ημέρας δεν μπήκα καθόλου Linux λόγω τηλεκπαίδευσης και άλλων υποχρεώσεων.

Σήμερα το πρωί πήρα την πρώτη ψυχρολουσία: Μπαίνοντας Linux, βλέπω κάτω δεξιά στο εικονίδιο του timeshift ότι δεν έχει γίνει mount o δίσκος storage… WTF??? Το μυαλό μου δεν πήγε καν στο συμβάν που περιγράφω στην πρώτη παράγραφο… Ανοίγω disks και έντρομος συνειδητοποιώ τι έχει γίνει… Ο 3TB δίσκος έχει γραμμένο “Windows Reserved” partition, μάλλον MBR, μεγέθους 17MB και όλη η υπόλοιπη χωρητικότητα 3TB φαίνεται unformatted… Τότε κατάλαβα ότι το “initialize” που είχα κάνει από το disk management των Windows δεν ήταν απλό “mount”…

Υπήρχαν καλά και κακά νέα…

Τα κακά ήταν ότι αυτός ο δίσκος περιέχει α) υλικό ανεκτίμητης αξίας με πρωτογενές video από τη γέννηση και τη βρεφική ηλικία του γιου μου, μέχρι και πρόσφατα, β) την ταινιοθήκη μου που περιλαμβάνει και σπάνιες ταινίες που δεν βρίσκεις εύκολα γ) τον φάκελο backup του timeshift (εξ ου και το αρχικό warning) δ) αρχειοθέτηση της δουλειάς μου των τελευταίων 15 ετών.

Τα καλά νέα ήταν ότι ΕΥΤΥΧΩΣ υπήρχε backup (με rsync) του δίσκου, σε εξωτερικό δίσκο 6TB, ο οποίος μάλιστα για λόγους ασφαλείας είναι offline, δηλαδή αποσυνδεδεμένος και συνδέεται μόνο όταν παίρνω backup.

Είχα πλέον μπει σε αχαρτογράφητα ύδατα, γιατί ποτέ μέχρι σήμερα δεν έχω κάνει επαναφορά backup με rsync. Απλά αντιστρέφω τα paths και λειτουργεί; Κάνω απλό copy paste; Και αν κάνω κάτι λάθος κατά την επαναφορά από τον 6TB (εξωτερικό backup) —> 3ΤΒ (εσωτερικό storage), αργότερα, όταν θα έπαιρνα το πρώτο backup από τον δίσκο 3ΤΒ —> 6ΤΒ backup θα είχε την πιθανότητα να χάσω αρχεία για πάντα! Έπρεπε να είμαι πολύ πολύ προσεκτικός! Άσε που επειδή το rsync αρχειοθετεί αρχεία, η επαναφορά θα χρειαζόταν ΩΡΕΣ. Τα αρχεία συνολικά στον δίσκο είναι 1.183.881 !!! Και εννοείται υπήρχε και το δίλημμα: Να επιχειρήσω recovery (αν γίνεται) ή να πάω κατευθείαν σε επαναφορά από backup;

Αρχίζω το ψάξιμο και το googling, πρώτα για το πώς επαναφέρω rsync backup. Κάπου ανάμεσα σε ιστοσελίδες και εντολές τερματικού, έχω τη φαεινή ιδέα να αναζητήσω λύση σε λάθη όπως το δικό μου “accidentally initialized ext4 disk” και σκάω πάνω στην εντολή fsck. 10-15 χρόνια χρήστης linux, γνώριζα την εντολή, αλλά ποτέ δεν είχε χρειαστεί να την χρησιμοποιήσω για διόρθωση σφαλμάτων σε δίσκο, καθώς ΠΟΤΕ δεν είχε γίνει corrupted ext4 filesystem. Τόσο αξιόπιστο είναι… (δεν μπορώ να πω το ίδιο και για το NTFS που πολλές φορές έχω χρησιμοποιήσει chkdsk στα Windows). Τελικά το fsck.ext4 ήταν και η σωτηρία μου!

Με την εντολή

sudo fsck.ext4 -vy /dev/sdd

(-v → verbose // -y —> “ναι σε όλα” γιατί τα prompts που σκάνε είναι πολλά λόγω της φύσης της ζημιάς)

και μετά από 5-10 λεπτά διαδικασία, το fsck κατάφερε να επαναφέρει τον δίσκο, προφανώς αξιοποιώντας κάποιο αντίγραφο του superblock που για λόγους redundancy κρατάει το ext4, με όλα τα αρχεία και τους καταλόγους στη θέση τους! Φυσικά δεν μπορώ να ελέγξω τα πάντα αλλά με τυχαία ανοίγματα που έκανα σε αρχεία, όλα φαίνονται να λειτουργούν ΟΚ!

storage: ***** FILE SYSTEM WAS MODIFIED *****

     2087519 inodes used (1.14%, out of 183148544)
        7915 non-contiguous files (0.4%)
        5256 non-contiguous directories (0.3%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 1971857/2504/7
   285710858 blocks used (39.00%, out of 732566646)
           0 bad blocks
          57 large files

     1183881 regular files
      785491 directories
           0 character device files
           0 block device files
           8 fifos
     4398472 links
      118111 symbolic links (113116 fast symbolic links)
          19 sockets
------------
     6485914 files

Έλεγξα και τα attributes των αρχείων καθώς και τις χρονοσφραγίδες τους και φαίνονται όλα OK, επομένως και το επόμενο backup με rsync θα λειτουργήσει κανονικά, μάλλον…

Συμπεράσματα:

  1. Μην βιάζεστε όταν κάνετε εργασίες με δίσκους

  2. Να έχετε πάντα backup και μάλιστα backup του backup. Ένα εξ αυτών πρέπει να είναι πάντα offline. Όχι μόνο για να αποφευχθεί η όποια φυσική καταστροφή αλλά και για περιπτώσεις , όπως στη δικιά μου, λάθους του χρήστη.

  3. Το fsck.ext4 είναι πανίσχυρο εργαλείο και μπορεί να σώσει τη μέρα, αλλά, βεβαίως, εφόσον υπάρχει η σιγουριά του 2

  4. Πρέπει να γνωρίζετε πώς να επαναφέρετε το backup που κρατάτε.

  5. Η μεγάλη εμπειρία χρήσης Η/Y δημιουργεί πολλές φορές και υπερβολική σιγουριά και λάθη. Το λάθος που έκανα, αν το έγραφε κάποιος στο forum, θα σκεφτόμουν “τι νουμπάς”. Και όμως μου συνέβη…

6 «Μου αρέσει»
2

Πετάγομαι για να σου προτείνω, είτε ως πρόσθετη λύση είτε ως αντικατάσταση του rsync το Borg. Πολύ, πολύ, πολύ πιο ολοκληρωμένο και αποτελεσματικό εργαλείο.

2 «Μου αρέσει»
3

thanx αλλά no thanx… Το rsync διανέμεται εδώ και 20 χρόνια με όλες τις διανομές linux και νιώθω μεγαλύτερη σιγουριά ότι θα το έχω και στο μέλλον. Το borg (δεν το ήξερα) δεν μου γεννά την ίδια εμπιστοσύνη. Εξάλλου οι ίδιοι οι δημιουργοί του αναφέρουν στην ιστοσελίδα

EXPECT THAT WE WILL BREAK COMPATIBILITY REPEATEDLY WHEN MAJOR RELEASE NUMBER CHANGES (like when going from 0.x.y to 1.0.0 or from 1.x.y to 2.0.0).

NOT RELEASED DEVELOPMENT VERSIONS HAVE UNKNOWN COMPATIBILITY PROPERTIES.

THIS IS SOFTWARE IN DEVELOPMENT, DECIDE YOURSELF WHETHER IT FITS YOUR NEEDS.

4

Ολόκληρο το ΕΛ/ΛΑΚ παρέχεται χωρίς εγγυήσεις αλλά αυτό δε σημαίνει απαραίτητα κάτι για τη λειτουργικότητά του, σωστά;

Δε θα σου πω το γνωστό «το χρησιμοποιώ χρόνια και δεν είχα ποτέ το παραμικρό πρόβλημα» γιατί το δικό μου use case* διαφέρει από το δικό σου. Θα σου πω όμως να το δοκιμάσεις. Μπορείς να το κάνεις με κάτι ασήμαντο αρχικά, για να αρχίσεις να εξοικειώνεσαι σταδιακά με ένα εναλλακτικό εργαλείο. Πες ότι στο μέλλον κάτι δεν πάει καλά με το rsync ή σου δημιουργείται μια νέα ανάγκη που δε μπορεί να την καλύψει. Δε θα βρεθείς εκτεθειμένος.

Το Borg δεν είναι ένα τυχαίο εργαλείο αλλά αποτελεί εξελιγμένο fork του γνωστού Attic. Υπάρχει ένα απλό GUI (Vorta), αν είσαι τέτοιος τύπος, και κάμποσα scripts που το κάνουν βατό ακόμα και για τον αρχάριο χρήστη. Θα σταθώ όμως σε ένα από τα συγκριτικά πλεονεκτήματα που έχει έναντι άλλων λύσεων: δεν ξέρουμε αν ένα backup είναι ολοκληρωμένο παρά μόνο αν χρειαστεί να το επαναφέρουμε. Το Borg όμως μπορεί, είτε κατά τη διαδικασία της λήψης του backup είτε οποιαδήποτε άλλη στιγμή, να επαληθεύσει ότι τα δεδομένα που αποθηκεύτηκαν είναι όντως όλα όσα θέλουμε και δεν λείπει/«εξαφανίστηκε»/αλλοιώθηκε απολύτως τίποτα.

*Αν σημαίνει κάτι, εγώ δεν έχω αρχεία τέκνων, έχω όμως ένα ογκώδες αρχείο μουσικής που συνέλεξα και επιμελήθηκα με πολύ κόπο, όπως και άλλα σημαντικά αρχεία. Δε θα τα εμπιστευόμουν σε αμφίβολα εργαλεία.

1 «Μου αρέσει»
5

Αν θεωρείς το rsync αμφίβολο εργαλείο, θα σε παρακαλούσα να το εξηγήσεις. Σε τι εστιάζεις τον προβληματισμό σου;

Το χρησιμοποιώ σε όλα μου τα μηχανήματα, σε 2 home servers και σε 2 production servers. Τα τελευταία 10 χρόνια χρειάστηκα 2 φορές rsync για επαναφορά λειτουργικού (το ένα ήταν production server που έκανε fail ο δίσκος με το λειτουργικό). Δούλεψε όπως ανέμενα. Σε 10 λεπτά ήμουν up and running.
Εννοείται ότι στους servers τα backups είναι επαναλαμβανόμενα σε διαφορετικούς δίσκους για λόγους ασφαλείας) και με logs για να μπορώ να ελέγχω την ροή & πρόοδο τους όποτε θέλω.

Δεν έχω άποψη για το borg διότι δεν το έχω χρησιμοποιήσει ποτέ. Ακολουθώντας όμως τη συμβουλή (σας) θα το τσεκάρω.

6

Η αναφορά μου στα αμφίβολα εργαλεία δεν αφορούσε το rsync αλλά τους ενδοιασμούς του φίλου για το Borg. Απάντησα λοιπόν ότι δε θα το εμπιστευόμουν αν είχα εντοπίσει την παραμικρή ένδειξη αναξιοπιστίας.

Ως εργαλείο τώρα, μπορεί να κάνει ό,τι κάνει και το rsync και ακόμα περισσότερα, όπως ο έλεγχος του backup που ανέφερα. Κι εγώ χρησιμοποιούσα το rsync με διάφορους τρόπους αλλά από τότε που ανακάλυψα το Borg πήγα εκεί.

Ως γενικότερη διαπίστωση θα πω ότι καμιά φορά τυχαίνει να μη γνωρίζουμε/πιστεύουμε ότι χρειαζόμαστε αυτό το “κάτι παραπάνω” μέχρι να το ανακαλύψουμε και να αναρωτηθούμε γιατί τόσο καιρό χρησιμοποιούσαμε το “κάτι λιγότερο”.

7

Πάντως το rsync κάνει αυτόματο validation μέσω checksums. Εκτός αν λέγοντας “έλεγχος backup” εννοείς κάτι άλλο

8

Αν δεν τα θυμάμαι εντελώς λανθασμένα, το μόνο αυτόματο validation στο rsync είναι με timestamps. Τα MD5 checksums χρειάζονται την παράμετρο -c.

Αντίστοιχα, το Borg έχει validation μέσω CRC32 αλλά και το “full extra” όπου δε χρησιμοποιεί checksums αλλά διαβάζει ένα προς ένα τα αρχεία στο backup. Λειτουργεί, δε, ακόμα και αν το backup είναι κρυπτογραφημένο, κάτι που το rsync δε μπορεί να κάνει (εννοούμε encrypt on storage, όχι encrypt transfer που κάνουν και τα δύο).

9

Για να ελέγξεις τα αρχεία, μπορείς να κάνεις αντίστροφο rsync με checksum. Διαφορετικά ένας άλλος τρόπος είναι με rhash να δημιουργήσεις ένα αρχείο με hashes για κάθε αρχείο και αντίστοιχα στον άλλο δίσκο rhash -c file.sfv. Θα σου πρότεινα να τα τσεκάρεις γιατί στο επόμενο backup μπορεί να αντιγραφεί κάποιο corrupted αρχείο πάνω από το κανονικό.

Κάπως σχετικό, σε Unix συστήματα η καταστροφή αρχείων είναι ένα τικ μακρυά. Π.χ. αντί για rm -rf /path/to/some/folder/*, να τρέξεις rm -rf /path/to/some/folder/ *. Γι’ αυτό το alias rm='rm -I' είναι χρήσιμο. To zsh επίσης έχει double verification για τις περιπτώσεις * και /*.

3 «Μου αρέσει»
10

Έχεις δίκιο. Το σκέφτηκα ήδη και πάνω που άρχισα να ψάχνω τρόπους να τσεκάρω με κάποια checksum μέθοδο, τελικά έλεγξα με το ίδιο το rsync, τρέχοντας το με την παράμετρο --dry-run (δεν την ήξερα μέχρι σήμερα). Με τον συγκεκριμένο τρόπο μου δίνει το output του συγχρονισμού, χωρίς όμως να γίνει καμία εγγραφή στο δίσκο. Πλην κάποιων διαγραφέντων αρχείων video (τα είχα σβήσει εγώ στον 3TB, αλλά δεν είχα ανανεώσει το backup, επομένως υπήρχαν στο backup), όλα τα άλλα κομπλέ!

11

Εγώ πάλι θα πρότεινα rsnapshot. Η σιγουριά του rsync με incremental snapshots.

2 «Μου αρέσει»
12

But can it do chunk-based increments? Όχι, δε μπορεί.

Υπάρχουν δύο βασικές προσεγγίσεις στα incremental backups:

  1. File-based increments, όπου αποθηκεύεται εκ νέου ολόκληρο το αρχείο με τις αλλαγές. Αυτό κάνει και το rsnapshot και δεν είναι ιδιαίτερα space-efficient προσέγγιση, ειδικά αν το backup περιέχει μεγάλο όγκο αρχείων.

  2. Chunk-based increments, όπου τα αρχεία επιμερίζονται και σε περίπτωση αλλαγών αποθηκεύονται μόνο αυτές και όχι εκ νέου ολόκληρο το αρχείο. Έτσι εξοικονομούμε και χώρο στον δίσκο αλλά και χρόνο. Σε αυτήν την κατηγορία εντάσσεται το Borg.

13

Οκ. Δεν μπορεί. Αλλά η στρατηγική backup θεωρώ ότι εξαρτάται και από τα σενάρια καταστροφών που θεωρείς πιο πιθανά καθώς και το downtime που θεωρεί κάποιος αποδεκτό (χωρίς να μιλάμε για redundancy με RAID).
Ναι, file-based increments καταλαμβάνουν παραπάνω χώρο, (αν και με τα increments και τα hard links είναι σχετικά μικρός σε σχέση με full backup) αλλά δίνουν την δυνατότητα για ΠΟΛΥ μικρότερο down time σε περίπτωση που επέλθει καταστροφή και είναι πιο “απλά” τα πράγματα στην επαναφορά τους.
Σε chunk-based increments, κερδίζεις χώρο από τη μια αλλά η επανασύνθεση των αρχείων μπορεί να διαρκέσει αρκετά περισσότερο αυξάνοντας το down time.

Οπότε τελικά θα έλεγα πως έχει να κάνει με το πιο εργαλείο χειρίζεται-γνωρίζει κάποιος καλύτερα καθώς και το τι αφορά το backup.

14

Αν υποθέσουμε ότι έχουμε κάποια «mission critical» αρχεία, νομίζω ότι η εξασφαλισμένη σωστή αποθήκευσή τους υπερισχύει του downtime. Έχουν υπάρξει περιπτώσεις ιστοσελίδων, για παράδειγμα, που χρησιμοποιούσαν το Χ εργαλείο με το σχετικά μικρό downtime επαναφοράς, για να βρεθούν στη δυσάρεστη θέση να διαπιστώσουν ότι το backup δεν ήταν σωστό.

Ένα εργαλείο backup, κατά την ταπεινή μου γνώμη, δεν πρέπει μόνο να μπορεί να αποθηκεύει και να επαναφέρει εύκολα και γρήγορα αλλά να λαμβάνει υπόψη του και άλλους σημαντικούς παράγοντες, όπως είναι ο έλεγχος της ακεραιότητας του backup, τα μεταδεδομένα των αρχείων και η διασφάλιση ότι η επαναφορά θα είναι απόλυτα λειτουργική χωρίς να χρειαστεί καμία άλλη παρέμβαση. Σε διαφορετική περίπτωση, το όποιο εργαλείο είναι απλά ένα glorified cp.

Αν, λόγου χάρη, σε ένα υποθετικό διάστημα 6 μηνών έχουμε ένα backup του 1 TB, θα θέλαμε να εντοπιστούν τα corrupted αρχεία σε αυτό όσο το δυνατόν πιο κοντά στη στιγμή της λήψης του και όχι τον 7ο μήνα που μπορεί να χρειαστεί να το επαναφέρουμε. Μπορεί το downtime να είναι μικρό αλλά ο συνολικός χρόνος αποκατάστασης των corrupted αρχείων να είναι πολύ μεγαλύτερος, έτσι δεν είναι;

1 «Μου αρέσει»
15

Και πάλι συμφωνώ. Θεωρώ ότι προσεγγίζουμε προς την ίδια κατεύθυνση το θέμα απλά από διαφορετικές πλευρές.
Εγώ θα κατέληγα σε μια φράση: βρες ένα εργαλείο που δουλεύει σωστά -αποδεδειγμένα- μάθε το και μείνε σε αυτό.
Προσωπικά άλλαζα επί 3 χρόνια μεθόδους backup που νόμιζα ότι έτρεχαν απρόσκοπτα μέχρι που κάτι πήγαινε στραβά (ευτυχώς χωρίς να χρειαστεί επαναφορά στο ενδιάμεσο).
Τελικά μετέπειτα δημιούργησα στρατηγική backup (τι θέλω, πως το θέλω, πότε το θέλω κτλ) και έστησα backup 3-2-1 το οποίο παίζει εδώ και 4 χρόνια σωστά -αποδεδειγμένα- και καλύπτει τις ανάγκες μου.

16

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

1 «Μου αρέσει»
17

update 8/4/21

Απλά έλεος…

Ενώ όλα καλά, μετά από μερικά boots windows 10 και μια εκτέλεσε easus backup του win 10 συστήματος, ξαναγυρνάω σε linux και ξανά μανά τα ίδια!!!

Ο δίσκος είχε ξανά ένα partition sdd1 στην αρχή windows reseved και τα δεδομένα sdd υπήρχαν αλλά σε “unformated” partition.

Τρέχω ξανά fsck.ext4 και τα επαναφέρω…

Κάτι πρέπει να άφησε το intialize των windows στο gpt και οταν το βλέπουν πάνε να ανακτήσουν τον δίσκο…

Τρέχοντας fdisk /dev/sdd (μετά την επαναφορά με fsck) βλέπω αυτό:

george@ryzen:~$ sudo fdisk /dev/sdd
[sudo] password for george:         

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

The primary GPT table is corrupt, but the backup appears OK, so that 
 
will be used.

Επομένως η υπόθεσή μου είναι σωστή, ναι μεν το fsck ανακτά τα αρχεία μου, αλλά η μαμακία στο GPT παραμένει…

Δοκίμασα fdisk -w (write new table) αλλά τώρα φαινόταν όλος ο δίσκος unformatted και τον επανέφερα ξανά με fsck

Πώς διορθώνω το πρόβλημα στο GPT για να μην γίνει ξανά μαμακία στα windows??? SOS

18

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

19

Αυτό έγινε τελικά. Άλλωστε υπήρχε backup ούτως ή άλλως. Έπαιξα λίγο για εγκυκλοπαιδικούς λόγους, αλλά στάθηκε αδύνατο να φέρω το gtp partition table στα ίσια του…

20

Σε δισκους με πολλα partitions ή λειτουργικο, παρε και ενα image με Clonezilla ναχεις το κεφαλι σου ησυχο. Ο συνδοιασμος Clonezilla (αρχικο + ανα 6μηνο π.χ.) με τακτικα Rsync ειναι αχτυπητος…
Οταν κατι παει στραβα, επαναφερεις το (τελευταιο) image, και συγχρονιζεις με τα επομενα αρχεια. Ολα στη θεση τους.