Timeshift και system updates

[linuxovios]

Χρησιμοποιώ εδώ και καιρό το Timeshift ως μία εκ των ων ουκ άνευ ενέργειες που κάνω αμέσως μετά την εγκατάσταση του συστήματος. Είναι idiot-proof, λειτουργεί αυτόματα χωρίς καμία όχληση στον χρήστη και τουλάχιστον σε μία περίπτωση με έχει σώσει από χάσιμο χρόνου όταν από δικούς μου πειραματισμούς κατάφερα να προκαλέσω ζημιά σε μια εγκατάσταση (με unofficial mesa drivers). Σε μια δεύτερη περίπτωση κατάφερα να επαναφέρω πολύ γρήγορα ένα αρχείο που έσβησα από λάθος, χωρίς να ψάχνομαι με undelete εφαρμογές (που όμως ούτως ή άλλως έχουν περιορισμένη λειτουργικότητα σε SSD λόγω trimming).

Η απορία μου, για την οποία δεν έχω καταφέρει να βρω απάντηση στις αναζητήσεις μου είναι η εξής: Ρυθμίζω το scheduling του timeshift και αυτό παίρνει τα snapshots σε προκαθορισμένες περιόδους (π.χ. ανά μέρα, ανά εβδομάδα, ανά μήνα, ανά boot κτλ). Όταν γίνεται η διαδικασία στο παρασκήνιο (με rsync), εγώ δεν το γνωρίζω. Τι γίνεται αν εκείνη τη στιγμή, που δεν γνωρίζω ότι το timeshift παίρνει snapshot, εγώ τρέξω system update π.χ. με αναβάθμιση kernel; Λογικά τα δεδομένα του δίσκου αλλάζουν με τον νέο kernel ή με τα όποια update files. Κινδυνεύω το snapshot να ολοκληρωθεί π.χ. το μισό με τα pre-update αρχεία και το άλλο μισό με post-update αρχεία; Άρα σε αυτή την περίπτωση αν κάνω revert στο συγκεκριμένο snapshot θα βρεθώ με μη λειτουργικό σύστημα;

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

Γνωρίζει κανείς;

[Asfodelus]

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

Όσον αφορά το πρόβλημα με το apt όμως η λύση είναι απλή. Φτιάξε ένα αρχείο /var/lib/dpkg/lock και δεν θα τρέξει το apt μην τρέξεις αν αυτό υπάρχει. Τόσο απλά αλλά δεν ξέρω αν το timeshift κάνει χρήση αυτού του μηχανισμού.

Αλλά υπάρχει μια πολύ απλή λύση που δεν έχει κανένα τέτοιου είδους πρόβλημα. Είναι η λύση που έχω στον υπολογιστή μου. Απλά δεν χρησιμοποιώ το rsync για το timeshift. Problem solved

Και η λύση είναι να μην έχεις σαν σύστημα αρχείων το ext4/xfs αλλά κάποιο που να κάνει snapshoots από μόνο του. Συνιστώ το btrfs και οχι το ZFS

[tsapi]

Αυτό δεν απαντάει, έτσι όπως εγώ καταλαβαίνω τα πράγματα, στην ουσία της ερώτησης.

Η ερώτηση εν προκειμένω τροποποιείται ως εξής: τι θα συμβεί αν το snapshot “παρθεί” κατά τη διάρκεια ενός apt dist-upgrade?

[linuxovios]

@tsapi

ρώτηση εν προκειμένω τροποποιείται ως εξής: τι θα συμβεί α

Εγκυκλοπαιδικά αναφέρω ότι -αν δεν κάνω λάθος, στο ZFS τα snapshots είναι στιγμιαία λόγω της αρχιτεκτονικής του συστήματος. Δεν γνωρίζω αν το ίδιο συμβαίνει και στο btrfs. Σε κάθε περίπτωση, η πλειονότητα των χρηστών χρησιμοποιεί ext4 και timeshift για snapshots, οπότε θα πρέπει να δοθεί κάποια απάντηση. Πόσταρα και εδώ ερώτημα, αλλά δεν ξέρω αν κάποιος dev μου απαντήσει. → How does Timeshift handle interrupted backups · Issue #484 · teejee2008/timeshift · GitHub

Κάντε και εσείς ένα bump αν θέλετε.

[foufoutos]

Επειδή είχα και γω αυτή την απορία, ενεργοποίησα και την επιλογή boot snapshot που ξεκινά 10’ μετά την εκκίνηση και για 20’-30’ δεν κάνω updates upgades ή άλλες αλλαγές.
Δεν είναι τεχνικά ενδεδειγμένος τρόπος, μα κάλλιο γαϊδουρόδενε παρά γαϊδουρογύρευε

[Asfodelus]

Τελικά η απάντηση είναι απλή. Στην σελίδα του το Timeshift αναφέρει

In RSYNC mode, snapshots are taken using rsync and hard-links. Common files are shared between snapshots which saves disk space. Each snapshot is a full system backup that can be browsed with a file manager.

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

But the filename twice can happen under other circumstances; if you’ve seen this happen, it’s almost certainly because the file changed during transfer. Rsync does no locking. Which means that: if you are modifying a file while it’s being transferred, then probably the checksum will fail and it’ll go round again. And if it goes around twice, and it still fails, then it prints a message saying; Error, checksum failed, file changed during transfer? And it’s probably a file like a log file that’s being constantly updated and so the checksums didn’t match because it’s never going to be able to get it exact; it means that what you’ve got on the other end is something which will approximate some snapshot of the file, but because it’s not doing any locking, it can’t guarantee that it’s got a particular snapshot of the file, because you can’t have an atomic read of the whole file.

Συμπέρασμα

Στην περίπτωση που ενημερώνεις την βάση του apt είναι πιθανόν κάποια index να είναι παλαιότερα. Κανένα πρόβλημα σε αυτή την περίπτωση. Στην χειρότερη περίπτωση θα σου πει να ξανακάνεις ένα apt update ή ένα apt install -f.

Στην περίπτωση που κάνεις ενημέρωση του kernel, αυτά είναι νέα αρχεία και τα αρχεία του παλιού kernel δεν θα πειραχτούν. Οπότε ας πούμε ότι ξεκινάει το backup στην μέση της διαδικασίας, τότε θα έχεις τον παλιό kernel και το grub απείραχτο. Τα αρχεία του grub θα είναι σε κάθε στάδιο της διαδικασίας έγκυρα.

Εξάλλου αν το timeshift έκανε κάποιο τέτοιο πρόβλημα θα είχε πέσει κάποιος ατυχής πάνω και θα είχε αναφερθεί.

Συνιστώ πάντα την χρήση του btrfs, που δεν μου έχει παρουσιάσει κανένα πρόβλημα τους μήνες που το έχω, αλλά και με το rsync παραμένει ασφαλές, ή τουλάχιστον αυτή είναι η κατανόηση μου.

Το μόνο πρόβλημα με το btrfs είναι πως αν ο δίσκος τα φτύσει θα χάσεις και τα αντίγραφα, ενώ αν τα έχεις σε διαφορετικό δίσκο μπορείς να κάνεις επαναφορά από εκεί. Αλλά το timeshift ΔΕΝ είναι λύση για backup, όπως έχουμε πει πολλές φορές.

Περισσότερες πληροφορίες

Διαβάστε το παρακάτω. Μιλάει για το rsnapshot που κάνει τα πράγματα λίγο διαφορετικά, αλλά η κεντρική ιδέα είναι η ίδια. : Easy Automated Snapshot-Style Backups with Rsync

Για τον αλγόριθμο του rsync: The Rsync Algorithm

[linuxovios]

Τελικά έστειλα email απευθείας στον δημιουργό του Timeshift, διότι κανείς σε κανένα forum δεν μπορούσε να μου απαντήσει (έχω ποστάρει και σε αγγλόφωνα). Η απάντηση του Tony George ήταν:

Since Timeshift creates snapshots when system is online, it is possible for inconsistent snapshots to be created. There is no way to avoid this. Ideally the system should be offline (not running) when snapshot is being created.

Regards,
Tony George

Μόλις συνειδητοποίησα λοιπόν ότι δεν μπορώ να βασίζομαι στο timeshift, τουλάχιστον μέχρι να υλοποιηθεί ένα σύστημα notify-send για να γνωρίζει ο χρήστης πότε ένα snapshot εκτελείται, ώστε εκείνη την ώρα τουλάχιστον να μην ξεκινήσει κάποιο system-update.

Του απάντησα με αυτή ακριβώς την παράκληση…

Μέχρι τότε, υπάρχει κάποια άλλη λύση;

[linuxovios]

@Asfodelus

Από το link που δίνεις διάβασα και αυτό:

• Q: What happens if a file is modified while the backup is taking place?
• A: In rsync, transfers are done to a temporary file, which is cut over atomically, so the transfer either happens in its entirety or not at all. Basically, rsync does “the right thing,” so you won’t end up with partially-backed-up files. Thanks to Filippo Carletti for pointing this out. If you absolutely need a snapshot from a single instant in time, consider using Sistina’s LVM (see reference above).

Τώρα μπερδεύτηκα… Ο Τony George λέει ότι μπορεί να δημιουργηθούν ασυνεπή snapshots, ενώ από το link που δίνεις καταλαβαίνω ότι υπάρχει πρόβλεψη για το σενάριο τροποποίησης αρχείων κατά τη διάρκεια του sync… Τελικά τι ισχύει?

[lucinos]

@linuxovios

Τελικά τι ισχύει?

Ισχύει ότι το rsync «κάνει το σωστό» πράγμα που δεν ταυτίζεται με πραγματικά στιγμιαίο spapshot. Δηλαδή με το rsync δεν πρόκειται να έχεις ποτέ ένα μισοσωσμένο αρχείο πράγμα που θα μπορούσε να συμβεί με πραγματικά στιγμιαία snapshot.

[linuxovios]

OK τώρα έχω καταλάβει πλήρως: Έστω ότι έχεις μια εφαρμογή που έχει τα αρχεία Α1, Β1, Γ1. Ξεκινάς rsync. Το rsync αντιγράφει το Α1, αλλά εν τω μεταξύ τρέχει update και αλλάζει τα αρχεία σε Α2, Β2, Γ2. Το rsync έχει προλάβει να αντιγράψει το Α1, αλλά στη συνέχεια αντιγράφει τα Β2, Γ2. Δηλαδή μπορεί να βρεθείς με ένα snapshot που να έχει την παλιά έκδοση του αρχείου Α, αλλά τις νέες εκδόσεις των αρχείων Β και Γ. Αυτό που δεν θα κάνει το rsync είναι να σου δώσει μισό αρχείο παλιό και το άλλο μισό updated. Όμως στο σύνολο του snapshot δεν έχεις εγγύηση για τις εκδόσεις των αρχείων. Αυτό το πρόβλημα λύνεται μόνο αν με κάποιο τρόπο μπορείς να παγώσεις το fs ή να πάρεις offline snapshot ή με κάποιο τρόπο το αυτοματοποιήσεις πριν το login ή μετά την επιλογή shutdown και πριν σβήσει το μηχάνημα.

[Asfodelus]

Υπάρχουν δυο ανεξάρτητες μεταξύ τους ερωτήσεις:

• Η πρώτη ερώτηση είναι αν έχεις ένα ασυνεπές backup. Για παράδειγμα κάποιο αρχείο “μισογραμμένο”. Αυτό θα ήταν πολύ προβληματικό. Η απάντηση σε αυτό το ερώτημα και με τις δυο μεθόδους είναι όχι.

• Η δεύτερη ερώτηση αφορά τις θα συμβεί αν έχεις ένα “ελλιπές” backup. Στην περίπτωση που για παράδειγμα γίνει στο μέσο μιας ενημέρωσης. Αυτό είναι ισοδύναμο με το να σταματήσεις την διαδικασία με CtrlC. Σε αυτή την περίπτωση εξετάζεις τι θα συμβεί κατά περίπτωση. Αν κάνεις αναβάθμιση πυρήνα ο παλιός δεν θα πειραχτεί. Αν σταματήσεις μια αναβάθμιση θα πρέπει να την συνεχίσεις με ένα apt install -f. Αν σταματήσεις ένα apt update θα πρέπει να το ξανακάνεις.
  Τα περισσότερα προγράμματα είναι ασφαλή ακόμα και στις πτώσεις τάσεις, όπου μπορεί να έχεις “μισογραμμένα” αρχεία. Η συνήθης μέθοδος είναι να κάνουν την εγραφή σε διαφορετικό αρχείο πρώτα, και μετά να σβήνουν το αρχικό.

Οπότε η απάντηση στην αρχική σου ερώτηση:

@linuxovios

Τι γίνεται αν εκείνη τη στιγμή, που δεν γνωρίζω ότι το timeshift παίρνει snapshot, εγώ τρέξω system update π.χ. με αναβάθμιση kernel; Λογικά τα δεδομένα του δίσκου αλλάζουν με τον νέο kernel ή με τα όποια update files. Κινδυνεύω το snapshot να ολοκληρωθεί π.χ. το μισό με τα pre-update αρχεία και το άλλο μισό με post-update αρχεία; Άρα σε αυτή την περίπτωση αν κάνω revert στο συγκεκριμένο snapshot θα βρεθώ με μη λειτουργικό σύστημα;

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

Αν πραγματικά θέλεις να μην γίνει clone αν τρέχει το apt, είναι εύκολο να το κάνεις. Απενεργοποίησε τα αυτόματα snapshoots, και φτιάξε ένα δικό σου cron job με ένα αρχείο bash. Αυτό θα ελέγχει αν το apt είναι κλειδωμένο και αν είναι θα περιμένει. Μετά θα τρέχει τις κατάλληλες εντολές. Δες εδώ για μια αρχή, αλλά δεν θα έμπαινα στον κόπο.

ΥΓ: Το notify μπορείς να το υλοποιήσεις επίσης εύκολα, αλλά αν έχεις αυτόματες αναβαθμίσεις; Αν έχεις συνδεμένους πολλούς ή κανένα χρήστη;

[Asfodelus]

@linuxovios

Αυτό το πρόβλημα λύνεται μόνο αν με κάποιο τρόπο μπορείς να παγώσεις το fs ή να πάρεις offline snapshot ή με κάποιο τρόπο το αυτοματοποιήσεις πριν το login ή μετά την επιλογή shutdown και πριν σβήσει το μηχάνημα.

Αυτό μπορεί να γίνει πολύ εύκολα. Το δικό μου setup

Το να κρατάς τόσα πολλά snapshoots (τζάμπα είναι και είναι στιγμιαία) έχει νόημα με το btrfs. Πριν το btrfs είχα μόνο εβδομαδιαία :P

[linuxovios]

Δεν το έχω ρυθμίσει μετά το boot γιατί μπορεί να κάνω 3-4 την ημέρα και κάτι τέτοιο θα πρόσθετε αχρειαστο overhead. Έχω όμως αρκετά ημερήσια, εβδομαδιαία και μηνιαία. Θα πρέπει να ειμαι απίστευτα γκαντεμης για να έχει τρέξει update σε όλα κατά τη διάρκεια του snapshot. Αλλά για ψυχαναγκαστική ασφάλεια φανταζομαι ότι ο ασφαλέστερος τρόπος θα ήταν με κάποιο script να ρυθμίσεις να γίνεται το snapshot μόλις ο χρήστης πατήσει shutdown, πριν σβήσει ο υπολογιστής. Σε αυτό το διάστημα αποκλείεται να τρέξει οποιοδήποτε update η να γίνει κάποια σημαντική παρέμβαση στο file system.

Επίσης το request μου στον Tony George , πιστεύω είναι εξαιρετικά χρηστικό. Δηλαδή να ενημερώνεται ο χρήστης με notify-send ή με κάποιο εικονίδιο στο panel για την ώρα που τρέχει το snapshot ώστε ο ίδιος ο χρήστης να το γνωρίζει και π.χ. να μην εκκινεί κάποιο update ταυτόχρονα. Απορώ που δεν το έχουν σκεφτεί μέχρι σημερα

[lucinos]

Οι προσωπικές απόψεις για το θέμα:

• To rsync είναι ιδανικό εργαλείο μπακάπ.
• Μπακάπ κανείς (όλοι) πρέπει να κάνει τα δεδομένα του.
• Μπακάπ κανείς δεν θα έπρεπε να κάνει το σύστημα δεν εννοώ με rsync, εννοώ γενικά
• Θεωρώ λογικότερο κανείς να διατηρεί ένα δεύτερο εναλλακτικό σύστημα αν ανησυχεί για το τι θα γίνει «αν τα πράγματα στραβώσουν»
• Οπότε οι χρήστες δεν θα έπρεπε καθόλου να ασχολούνται με αυτά τα θέματα πέρα από το μπακάπ
• Αν κανείς όντως έχει εξειδικευμένες ανάγκες τότε μάλλον πρέπει να κοιτάξει το btrfs.

[Asfodelus]

@linuxovios

Δηλαδή να ενημερώνεται ο χρήστης με notify-send ή με κάποιο εικονίδιο στο panel για την ώρα που τρέχει το snapshot ώστε ο ίδιος ο χρήστης να το γνωρίζει και π.χ. να μην εκκινεί κάποιο update ταυτόχρονα. Απορώ που δεν το έχουν σκεφτεί μέχρι σημερα

Πρόσθετα κάτι και δεν το είδες.

@Asfodelus

ΥΓ: Το notify μπορείς να το υλοποιήσεις επίσης εύκολα, αλλά αν έχεις αυτόματες αναβαθμίσεις; Αν έχεις συνδεμένους πολλούς ή κανένα χρήστη;

Μια υπηρεσία συστήματος δεν είναι εύκολο να στέλνει ειδοποιήσεις. Οι ειδοποιήσεις έχουν νοήμα μόνο μέσα σε ένα γραφικό session. Το νόημα του timeshift είναι να το ξεχνάς και να το θυμάσαι μόνο όταν βρεθείς σε ανάγκη. Προσωπικά το βρίσκω μια κακή ιδέα.

Για να το κάνεις αυτό θέλει πολλές ταρζανίες [1] [2]. Ίσως θα μπορούσες να χρησιμοποιήσεις το dbus και να έχεις ένα applet να το παρακολουθεί. Αλλά αυτά θα αυξήσουν κατά πολύ την πολυπλοκότητα, τα σημεία που κάτι μπορεί να πάει κάτι στραβά και την δυσκολία να βάλεις το timeshift σε ένα σύστημα. Όλα αυτά για πολύ μικρό όφελος, που θα εξαφανιστεί σε λίγα χρόνια όταν όλοι θα έχουμε ένα filesystem νέας γενιάς. Το rsync είναι μια προσωρινή λύση.

[linuxovios]

Δεν καταλαβαίνω γιατί είναι κακή ιδεα, έστω μια επιλογή στο setup του timeshift να επιλέγει ο χρήστης αν επιθυμεί ειδοποιήσεις πότε αρχίζει και πότε τελειώνει το snapshot. Με απλό notify-send και χωρίς ταρζανιες. Το έχω κάνει σε script που έχω φτιάξει για manual rsync σε εξωτερικό δίσκο. Γιατί να μην μπορεί να υλοποιηθεί και στο timeshift?

[Asfodelus]

Στην διανομή μου ήρθε σήμερα το finalrd και έτσι ανακάλυψα το systemd-shutdown. Με αυτά μπορείς να κάνεις το snapshot κατά το σβήσιμο του υπολογιστή.

Μπορείς να βάλεις ένα script στον κατάλογο /usr/lib/systemd/system-shutdown/ και θα εκτελεστεί πριν κλείσει ο υπολογιστής.

[Anthemous]

Μια ερωτησούλα προς εσέ “Talos” , ενώ μέχρι τώρα δεν υπήρχε κανενα πρόβλημα με το Timeshift(το αποθήκευα στο H/D του Υπολογιστή και μαξιμουμ εκανε κανα μισάωρο να τελειώσει, χθες αποφάσισα να το αποθηκευσω μια φορά σε εξωτερικό (USB -EXT4, 32GB ), και ενω ξεκινάει καλά , μετα αρχίζει και αυξάνεται ο χρόνος , να φανταστεις το ειχα 25 ωρες συνεχώμενα και δεν τελειωσε. Διεκοψα ξανα ρεσταρτ και παλι απο την αρχή και τωρα μου αυξανει σταδιακά τον χρόνο απο οταν ξεκίνησε (ηταν 23 λεπτα, τωρα ειμαι στις 07 ωρες και αυξάνεται…) Εγώ κανω κατι λάθος ή τα εχει παίξει το σύστημα ; (με rsynk) .

[Asfodelus]

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

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

Είναι ένα γνωστό πρόβλημα, θα σου συμβεί αν προσπαθήσεις να αντιγράψεις ένα μεγάλο αρχείο επίσης. Μπορείς να πειραματιστείς περιορίζοντας το bandwidth (rsync --bwlimit=KBPS) ή και να δώσεις καλύτερη προτεραιότητα με το ionice ή το trickle και να βρεις την βέλτιστη ταχύτητα που έχεις με αυτή την συσκευή με αυτό το καλώδιο σε αυτή την θύρα και με αυτό το system load.

[tsapi]

Αν δοκιμάσεις να κάνεις copy ένα μεγάλο αρχείο (κάποια GB) σε αυτό το εξωτερικό μέσο, η ταχύτητα σε τι επίπεδα κυμαίνεται?