(Σοβαρή) συζήτηση για home backup policy

[gdp77]

 

[Havic]

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

 

Sava as Batch + Windows Task Scheduler

 

I'm a simple man...

[minast]

5 hours ago, gdp77 said:

 

Μάλλον το κατέχεις το άθλημα πιο πολύ από μένα. Προτίμησα να διαβάσω και να ασχοληθώ με ZFS επειδή από διάφορες πηγές ακούω (και διαβάζω) ότι το software "παραδοσιακό" raid πρέπει να αποφεύγεται (π.χ. πιο αξιόπιστη πηγή σε αυτό το θέμα θεωρώ τον Wendell από L1techs.)  Δεν ξέρω ποια η άποψή σου γι αυτό. Θεωρείς ότι ένα software raid 1 πάνω σε ext4 ή btrfs είναι καλύτερη επιλογή από ZFS mirror; Και αν ναι, μπορείς να μου γράψεις συνοπτικά τους λόγους;

 

Δες και εδώ: 

 

 

Έχεις κάποια αρνητική εμπειρία ή από κάποιο link διάβασες κάτι; Θα με ενδιέφερε να μάθω σχετικά γιατί σε λίγο καιρό λογικά και εγώ θα περάσω σε kernel 5.0 Υπήρξαν περιπτώσεις απώλειας δεδομένων; Γενικά ξέρω ότι το openZFS εξελίσσεται και υπάρχουν αρκετοί devs που ασχολούνται, αλλά δεν φανταζόμουν ότι αυτή η εξέλιξη είναι παράγοντας κινδύνου για απώλεια δεδομένων.

 

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

Π.χ. σχολιάζει τα δυνητικά προβλήματα του software RAID, αλλά και ότι για mirroring παραμένει αποδεκτό. Αναφέρει τα πλεονεκτήματα ενός error detecting/correcting filesystem σε σχέση με τα παραδοσιακά, αλλά και τις σχετικά μεγάλες απαιτήσεις τους, και ειδικά του ZFS.

Είδα και το επόμενο μήνυμά σου για το θέμα των registers για το ZoL στον νέο kernel. Σε αυτό αναφερόμουν, αλλά δεν είναι το μόνο. Ακόμη και η συγκεκριμένη λύση δεν είναι κομψή, αλλά τουλάχιστον δουλεύει χωρίς μειονεκτήματα. Θέμα απώλειας δεδομένων δεν τίθεται.

 

Μερικοί λόγοι που πρότεινα τα συγκεκριμένα: Mirroring έχει το μικρότερο χρόνο επαναφοράς χαλασμένου δίσκου. Έχει τη μικρότερη εξάρτηση από υπολογισμούς για εξακρίβωση των σωστών δεδομένων και υποστηρίζεται και natively στο btrfs. To ZFS έχει εν γένει μεγαλύτερες απαιτήσεις από τις περισσότερες εναλλακτικές, και στο ZoL συνέχεια θυμάμαι να διαβάζω για κάποιο νέο μικρό θεματάκι. Επίσης με τις αναβαθμίσεις του ZFS μπορείς να ενεργοποιείς νέες λειτουργίες στα pools, αλλά δεν μπορείς να γυρίσεις σε προηγούμενη έκδοση. Εάν δίνεις μεγάλη σημασία στην αποφυγή σφαλμάτων που δεν γίνονται αντιληπτά, πρέπει να δεις ολόκληρη την διαδρομή των δεδομένων, πχ τη μνήμη. Ειδικά στο ZFS η μνήμη έχει πάντα μεγαλύτερη προτεραιότητα όταν εντοπίζεται ασυμφωνία, και γι' αυτό προτείνεται η χρήση ECC μνήμης για συστήματα με ZFS.

 

Τέλος, μεγάλο ρόλο σε τέτοιες επιλογές παίζει η ωριμότητα του λογισμικού και η υποστήριξη από τις διάφορες εκδόσεις linux (σε αυτό παίζουν ρόλο και οι άδειες). Σημείο εκκίνησης είναι ext4 και XFS, με ή χωρίς LVM, λιγότερο btrfs και ακόμη λιγότερο ZFS. Ό,τι και να διαλέξεις για τη χρήση που περιγράφεις θα είναι υπεραρκετό, απλά διάλεξε και το σύστημα που εσύ προτιμάς να αφιερώσεις το χρόνο σου να μάθεις και να συντηρείς.

 

Στο σπίτι χρησιμοποιώ ZFS σε FreeBSD NAS με 8GB ECC RAM, γι' αυτό σε έσπρωξα προς την ίδια κατεύθυνση. Σε τοπικό μηχάνημα και για το δίσκο του συστήματος θα πήγαινα σε XFS. Τόση ώρα μιλάω μόνο για storage. Για backup, τα είπαμε πριν.

[gdp77]

@minast

 

Έστησα ένα πειραματικό zpool για να αρχίσω να παίζω λίγο. Είδα tutorials και για mdadm, είναι εξίσου εύκολο. Προφανώς θέλω να εξοικειωθώ με κάθε πιθανό σενάριο παίζοντας με img files, πριν περάσω τα δεδομένα μου σε πραγματικούς δίσκους... 

 

Μια που φαίνεται ότι έχεις ασχοληθεί αρκετά: Υπάρχει τρόπος το pool που φτιάχνω να το δει το σύστημα σαν device (δηλαδή να φαίνεται σαν δίσκος) ή πρέπει να εξοικειωθώ με την ιδέα ότι θα το βλέπω σαν φάκελο; Με αρκετό γκουγκλάρισμα όλοι έχουν tutorials μέχρι να φτιάξεις pool, αλλά για αυτό που ρωτάω δεν βρήκα κάτι.

 

Τώρα για αυτά που γράφεις, έχω να μελετήσω. π.χ. η ιδέα mdadm με btrfs φαίνεται ελκυστική. Θέλω λίγο να ψαχτώ πώς αντιμετωπίζονται τα bitrot και silent errors χωρίς ecc μνήμη. Το zfs διαβάζω ότι τα εντοπίζει στο read και όχι στο write. Οπότε αν έχεις χιλιάδες αρχεία (που θα έχω εγώ) και δεν τύχει να ανοίξεις κάποια που έχουν πέσει θύματα από silent errors, δεν θα το καταλάβεις μέχρι να είναι αργά. Μόνο με manual scrub (προφανώς περιοδικό με cronjob) θα μπορείς να είσαι σίγουρος. Με το btrfs παίζει κάτι αντίστοιχο; Θα πρέπει να ψαχτώ και με το performance hit σε κάθε περίπτωση. Μόλις τεστάρω πραγματάκια με εικονικά img files, θα παίξω με 2 μηχανικούς αρχαίους που έχω σε ένα συρτάρι (80gb έκαστος), για να πάρω τις αποφάσεις μου. Μετα θα ακολουθήσει η αγορά 2x3TB ή 4ΤΒ αν πέσουν οι τιμές και θα κάνω τη μετάβαση.

[minast]

Δεν είμαι βέβαιος αν κατάλαβα την ερώτησή σου. Ακόμη και τα devices των φυσικών δίσκων πρέπει να τα κάνεις mount κάπου, το zpool δεν είναι διαφορετικό. Μπορείς βέβαια να δεις τα vdevs που συμμετέχουν σε ένα pool και τους δίσκους που συμμετέχουν στα vdevs.

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

[gdp77]

Πώς μπορώ το pool να το κάνω να φαίνεται στα devices του screenshot. 

 

 

 

Εν ολίγοις, έχω φτιάξει δύο αρχεία img 2GB έκαστο για δοκιμή:

 

for i in {1..2}; do truncate -s 2G /tmp/$i.img; done

φτιάχνω το pool:

 

sudo zpool create mypool mirror /tmp/1.img /tmp/2.img

 

To pool είναι online και βλέπω τον φάκελο στο /mypool :

 

$ zpool status mypool

  pool: mypool
 state: ONLINE
  scan: none requested
config:

	NAME            STATE     READ WRITE CKSUM
	mypool          ONLINE       0     0     0
	  mirror-0      ONLINE       0     0     0
	    /tmp/1.img  ONLINE       0     0     0
	    /tmp/2.img  ONLINE       0     0     0

errors: No known data errors

Μπορώ να γράψω ό,τι θέλω μέσα στον φάκελο /mypool.

 

Πώς μπορώ να το κάνω να εμφανίζεται σαν device?

Έγινε επεξεργασία Απρίλιος 25, 2019 από gdp77

[minast]

Αυτό έχει να κάνει με το window manager και τί είναι ρυθμισμένος να δείχνει κάτω από Devices. Δοκίμασε να το βάλεις κάτω από το /media/[username]/[mountfolder], πχ /media/gdp77/mypool

[gdp77]

6 minutes ago, minast said:

Αυτό έχει να κάνει με το window manager και τί είναι ρυθμισμένος να δείχνει κάτω από Devices. Δοκίμασε να το βάλεις κάτω από το /media/[username]/[mountfolder], πχ /media/gdp77/mypool

 

Μάλλον έχει να κάνει με το γεγονός ότι έπρεπε να δημιουργήσω zvol. Αλλά κάπου εκεί με πήρε ο ύπνος και δεν το προχώρησα. Κατάφερα μέχρι να το δω από το gnome-disk-manager. Θα λείψω για λίγες μέρες, οπότε το ξανακοιτάω από βδομάδα.

 

btw έπαιξα λίγο και με btrfs. Το raid-1 φαίνεται πολύ πιο απλό... Ψήνομαι να καταλήξω σε αυτή τη λύση. Και όσο πιο πολύ διαβάζω, μάλλον εκεί καταλήγω, καθώς είναι το fs που φτιάχτηκε για το linux για να κοντράρει το zfs (της νυν SUN, πρώην Oracle) το οποίο, όπως γράφεις, έχει τα θεματάκια στο linux λόγω κλειστού λογισμικού. Το openZFS ή ΖοL, πάει καλά, αλλά νομίζω ότι το btrfs μπορεί να επικρατήσει (αν επικρατήσει κάποιο τελικά). Διάβασα ότι και η google btrfs έχει επιλέξει.

[gdp77]

Συνέχεια της αναζήτησής μου και της συζήτησής μας εδώ (με τα νέα μου ευρήματα): 

 

[Inglor]

On 24/4/2019 at 6:02 ΠΜ, το μέλος gdp77 έγραψε:

[..]

Εσείς τι λέτε για όλα αυτά; Ποιο backup policy χρησιμοποιείτε; Περιμένω απόψεις και ιδέες μήπως και προτιμήσω κάποια άλλη καλύτερη λύση από αυτήν που σκέφτομαι.

Λίγο αργά στο θέμα αλλά ας απαντήσω και εγώ.

- Για το /home/inglor daily backup στο local NAS και Cloud backup στο Backblaze B2 (<1$ per month for ~100GB προς το παρόν). Το backup γίνεται με restic αυτόματα απο 2 user systemd  units.

- Για media files (video, photo, audio) μόνο στο τοπικό NAS.

- Media files που είναι καλό να υπάρχουν (photos) backup σε εξωτερικό σκληρό once per month (or more).

 

Από κάτω παραθέτω τα αρχεία για το daily local automatic backup στο NAS.

$ cat /home/inglor/.config/restic/env-local.sh
export RESTIC_REPOSITORY="local:/media/vault/backups/homes/tiamat-home"
export RESTIC_PASSWORD_FILE="/home/inglor/.config/restic/pwd.txt"

!/bin/bash

source /home/inglor/.config/restic/env-local.sh
notify-send "Restic backup started."
echo "Creating incremental backup ..."
### Backup new stuff
restic backup \
        --verbose \
        --files-from /home/inglor/.config/restic/backup.files \
        --exclude-file /home/inglor/.config/restic/exclude.files
### Remove old stuff
echo "Deleting old backups ..."
restic forget \
        --keep-last 7 \
        --keep-daily 14 \
        --keep-weekly 4 \
        --keep-monthly 6
echo "Backup finished."
notify-send "Restic backup finished."

$ cat .config/systemd/user/restic-backup-local.timer
[Unit]
Description=Restic Backup local daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

$ cat .config/systemd/user/restic-backup-local.service
[Unit]
Description=Restic Backup local service

[Service]
ExecStart=/home/inglor/.local/bin/backup-local

[Install]
WantedBy=default.target

Η διαφορά για το B2 είναι διαφορετικό restic repository / password (B2_ACCOUNT_ID, B2_ACCOUNT_KEY) και systemd timer weekly.

 

Υ.Γ.: Ναι ξέρω καλύτερα το password σε keyring αλλά (https://github.com/restic/restic/issues/533), κάποια στιγμή θα πρέπει να το κάνω σε gpg.

 

[masteroidz]

Έχεις σκεφτεί τη λύση MergerFS και Snapraid? Το πρώτο μαζεύει τους δίσκους και τους εμφανίζει ως έναν στο σύστημα (UnionFS) και το δεύτερο είναι snapshot based software raid.

 

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

 

Δες περισσότερα στο https://www.snapraid.it/compare

 

Τρέχει στον δικό μου οικιακό server (3*4ΤΒ σε ext4) εδώ και μήνες και έχει δοκιμαστεί σε ξαφνική απώλεια δίσκου. Δεν έχασα ούτε kb.

[gdp77]

Ενδιαφέρουσα η πρότασή σου @masteroidz. Δεν ήξερα για το snapraid. Διάβασα σχετικά και έμαθα αρκετά. Το γεγονός πάντως ότι δεν πρόκειται για real time redundancy αλλά για on-demand, δεν νομίζω ότι ταιριάζει στο workflow που σκέφτομαι ότι θα με βολέψει.

 

8 hours ago, masteroidz said:

Τρέχει στον δικό μου οικιακό server (3*4ΤΒ σε ext4) εδώ και μήνες και έχει δοκιμαστεί σε ξαφνική απώλεια δίσκου. Δεν έχασα ούτε kb.

 Για να μην έχασες "ούτε kb" όπως αναφέρεις, προφανώς το δοκίμασες σε σενάριο που αμέσως πριν είχες πάρει snapshot.

[masteroidz]

Ο ένας δίσκος ήταν από παλαιότερο σύστημα και έσκασε λίγες μέρες αφού έστησα τον server. Κάνω συγχρονισμό + scrub μια φορά τη μέρα. Έτυχε να γίνει βράδυ αφού είχε συγχρονίσει το σύστημα.

 

Για να καταλήξω σε αυτή η λύση πέρασα από δοκιμές επί χάρτου όλες τις επιλογές όπως RAID 5/6/10, ZFS κλπ αλλά η πολυπλοκότητα τους ακύρωνε τα όποια πλεονεκτήματα. Δηλαδή να προσθαφαιρώ δίσκους στο pool , να διαβάζω δίσκους εκτός pool και γενικά να έχω άμεση πρόσβαση στα δεδομένα μου ακόμα και αν η μητρική πάρει φωτιά.

 

Σημαντικό ρόλο στην επιλογή έπαιξε πως δουλεύω κυρίως με κώδικα, αρχεία κειμένου και spreadsheets οπότε ο όγκος των δεδομένων που αλλάζει καθημερινά είναι σχετικά μικρός. Πολύ μικρός αλλά με μεγάλη αξία. Για να προστατέψω λοιπόν την εργασία των τελευταίων 24 ωρών κρατάω τα δεδομένα που δουλεύω καθημερινά μόνο σε SSDs, pushαρω συχνά σε git repo και εννοείται όλα είναι πάνω σε ups. Τα αρχεία κειμένου & spreadsheets συγχρονίζουν επίσης με το Google Drive. Τα πολύ σημαντικά δεδομένα όπως φωτογραφίες κλπ υπάρχουν και σε usb stick εκτός του χώρου που ανανεώνεται κάθε εξάμηνο ευλαβικά.

 

Ο μοναδικός λόγος που βρίσκω κάποιος να μπλέξει με ZFS εκτός από πειραματισμό είναι απαιτήσεις σε production περιβάλλον κρίσιμων υποδομών με μπόλικους δίσκους και τεράστιες βάσεις δεδομένων. Εκεί πραγματικά δείχνει τα δόντια του.

[minast]

3 hours ago, masteroidz said:

Ο ένας δίσκος ήταν από παλαιότερο σύστημα και έσκασε λίγες μέρες αφού έστησα τον server. Κάνω συγχρονισμό + scrub μια φορά τη μέρα. Έτυχε να γίνει βράδυ αφού είχε συγχρονίσει το σύστημα.

 

Για να καταλήξω σε αυτή η λύση πέρασα από δοκιμές επί χάρτου όλες τις επιλογές όπως RAID 5/6/10, ZFS κλπ αλλά η πολυπλοκότητα τους ακύρωνε τα όποια πλεονεκτήματα. Δηλαδή να προσθαφαιρώ δίσκους στο pool , να διαβάζω δίσκους εκτός pool και γενικά να έχω άμεση πρόσβαση στα δεδομένα μου ακόμα και αν η μητρική πάρει φωτιά.

 

Σημαντικό ρόλο στην επιλογή έπαιξε πως δουλεύω κυρίως με κώδικα, αρχεία κειμένου και spreadsheets οπότε ο όγκος των δεδομένων που αλλάζει καθημερινά είναι σχετικά μικρός. Πολύ μικρός αλλά με μεγάλη αξία. Για να προστατέψω λοιπόν την εργασία των τελευταίων 24 ωρών κρατάω τα δεδομένα που δουλεύω καθημερινά μόνο σε SSDs, pushαρω συχνά σε git repo και εννοείται όλα είναι πάνω σε ups. Τα αρχεία κειμένου & spreadsheets συγχρονίζουν επίσης με το Google Drive. Τα πολύ σημαντικά δεδομένα όπως φωτογραφίες κλπ υπάρχουν και σε usb stick εκτός του χώρου που ανανεώνεται κάθε εξάμηνο ευλαβικά.

 

Ο μοναδικός λόγος που βρίσκω κάποιος να μπλέξει με ZFS εκτός από πειραματισμό είναι απαιτήσεις σε production περιβάλλον κρίσιμων υποδομών με μπόλικους δίσκους και τεράστιες βάσεις δεδομένων. Εκεί πραγματικά δείχνει τα δόντια του.

Το καθημερινό scrub δεν είναι υπερβολικό; Και αυτό καταπονεί τους δίσκους.

Ένα σχήμα πχ με ημερήσια snapshots και εβδομαδιαίο scrub δεν θα σε κάλυπτε;

[masteroidz]

[scrub]
; set to true to run scrub after sync
enabled = true
percentage = 15
older-than = 10

Αυτές είναι οι παράμετροι που χρησιμοποιώ.

Ελέγχει καθημερινά έως και 15% των δεδομένων που δεν έχουν γίνει scrub το τελευταίο 10ήμερο. Στην πράξη οι δίσκοι δεν δουλεύουν πάνω από 15-20 λεπτά και σχεδόν στο ρελαντί.