Αντίγραφα ασφαλείας βάσει git;

[Apollon Koutlidis]

Nikos Alexandris wrote:

[snip]
> Apollon Koutlidis wrote:
>   
>> - Τι μέσο αποθήκευσης θέλεις / προτιμάς / μπορείς να χρησιμοποιήσεις
>> για τα αντίγραφα ασφάλειας; ταινία, δίσκος, μηχανογραφικό χαρτί...
>>     
>
> Εξωτερικός(-οί) σκληρός(-οί) δίσκος(-οί) με θύρα firewire(x800) ή USB2.
>   
Η χρήση εξωτερικού δίσκου για αντίγραφα ασφαλείας είναι θεμιτή αλλά όχι 
ιδιαίτερα scalable (κλιμακώσιμη!;) λύση. Για 2 clients καλό το ακούω, αν 
αυξηθούν μάλλον είναι σκόπιμο να αρχίσεις να σκέφτεσαι δικτυακές λύσεις 
με κεντρικό backup server. Σημαντικό είναι οι δίσκοι να μην είναι 
μονίμως συνδεδεμένοι στα αντίστοιχα συστήματα, ειδ' άλλως αυξάνεις την 
πιθανότητα να συμβεί κάτι στα αντίγραφά σου.

>> - Τι είδους δεδομένα θα ασφαλίσεις; Πόσο συχνά αλλάζουν; Λάβε υπ' όψη 
>> ότι κάποιοι τύποι δεδομένων (π.χ. databases) χρήζουν ειδικής 
>> μεταχείρισης - ένα απλό cp / rsync δεν αρκεί (όχι από μόνο του).
>>     
>
> (1) - Από τα πιο "συνηθισμένα" (φωτογραφίες, μουσική, ντοκουμέντα),
>
>     - μέχρι απλά σενάρια (bash, python, R για τα οποία ήδη χρησιμοποιώ
> το git τοπικά)
>
>     - και "πολύπλοκα" (γεω-χωρικά δεδομένα με τα μετα-δεδομένα τους,
> βάσεις γεω-δεδομένων == συνηθισμένοι κατάλογοι με υποκαταλόγους και
> αρχεία υπό το GRASS-GIS, αρκετά sqlite.db's, πιθανόν και άλλες βάσεις
> -φερ' ειπείν PostGIS(PostgreSQL)-)
>
> (2) Αλλάζουν καθημερινά.
>
> Ερώτηση: ποια είναι η απαιτούμενη ειδική μεταχείριση που χρήζουν κάποιες
> βάσεις δεδομένων;
>   
Άρα έχεις ανάμεικτα δεδομένα ως προς τύπο, και δε μας είπες τι ποσοστό 
των δεδομένων σου αλλάζει :) λογικό είναι βέβαια να μην ξέρεις κιόλα 
αφού δεν έχεις ακόμα λύση backup.

Οι βάσεις δεδομένων - όπως και πολλές άλλες εφαρμογές - δεν προσφέρονται 
για αντίγραφα ασφαλείας ως έχουν, διότι η κατάστασή τους βρίσκεται εν 
μέρει στον δίσκο και εν μέρει στη μνήμη. Οι διαθέσιμες μέθοδοι ασφάλισης 
είναι πολλές και εξαρτώνται από την εφαρμογή. Η απλούστερη λύση είναι να 
κλείσεις την εφαρμογή από την αρχή μέχρι το τέλος της αντιγραφής. Οι 
περισσότερες βάσεις δεδομένων διαθέτουν και μεθόδους hot / warm backup 
(π.χ. mysqldump [4]) εάν το downtime είναι πρόβλημα. Σε αυτές τις 
περιπτώσεις τυπικά κάνεις ένα αντίγραφο σε αρχείο στον δίσκο και 
αντιγράφεις μόνον αυτό.

Μία ακόμα παράμετρος που αξίζει να έχεις υπ' όψη: Όπου υπάρχουν πολλά, 
μικρά αρχεία (π.χ. email), εμφανίζεται το πρόβλημα της διαμεταγωγής των 
μεταδεδομένων - συνήθως αυτό μεταφράζεται σε μειωμένες ταχύτητες 
αντιγραφής και αυξημένο όγκο των καταλόγων των αντιγράφων.

>> - Τι μέσο μετάδοσης θα χρησιμοποιηθεί; Ethernet / Fibre channel /
>> SCSI / USB...; Και με τι ταχύτητα διαμεταγωγής;
>>     
>
> Firewire (up to ~115MB/s), USB2 (up to ???)
>   
Όπως είπα και παραπάνω, όσο έχεις λίγους clients και δε χρειάζεσαι 
κεντρικό server τα πράγματα είναι γενικώς πιο απλά.

>> - Τι βάθος ιστορικού θέλεις;
>>     
>
> Θέλω να υπάρχουν όλα και να αποφασίζω εγώ τι θα χάνεται για πάντα
> ανάλογα με το διαθέσιμο ελεύθερο χώρο.
>
>   
Εδώ μου τα μπερδεύεις. Δεν έχω υπ' όψη μου κάποια λύση που να κάνει αυτή 
τη δουλειά (ίσως με εξαίρεση τα αμφιβόλου ωριμότητας logging filesystems 
τύπου NILFS / JFFS [5] αλλά δε θα σου συνιστούσα να κολυμπήσεις σε αυτή 
τη θάλασσα!).

Είτε θα κάνεις καθημερινά πλήρη αντίγραφα (κάτι που απαιτεί πολύυυ 
αποθηκευτικό χώρο), είτε θα κάνεις περιοδικά (π.χ. εβδομαδιαία) πλήρη 
και στο ενδιάμεσο incremental / differential (τα πρώτα αποθηκεύουν μόνο 
τις αλλαγές από το προηγούμενο incremental και τα δεύτερα, όπου είναι 
διαθέσιμα, τις αλλαγές από το τελευταίο πλήρες). Όσο μεγαλύτερο το 
διάστημα μεταξύ των πλήρων, τόσο πιο πολύπλοκη είναι η ανάκτηση (και 
προφανώς το ρίσκο αποτυχίας). Σε κάθε περίπτωση καθορίζεις τη διάρκεια 
τήρησης κάθε αντιγράφου και το λογισμικό θα "ανακυκλώσει" τα ληγμένα 
αντίγραφα μόλις χρειαστεί το χώρο (ή το μέσο όταν χρησιμοποιείς ταινίες).

Ένα λίγο-πολύ κλασικό σενάριο:
- Πλήρη κάθε μήνα το Σάββατο, τήρηση για ένα έτος
- Πλήρη κάθε εβδομάδα το Σάββατο εκτός από τις ημέρες των μηνιαίων, 
τήρηση για 4 εβδομάδες
- Incremental κάθε μέρα εκτός Σαββάτου, τήρηση για 2 εβδομάδες

Κατ' αυτό τον τρόπο έχεις ημερήσιο ιστορικό για 2 εβδομάδες, εβδομαδιαίο 
για άλλες 2 και μηνιαίο για ένα έτος.

>> Πόσο αποθηκευτικό χώρο μπορείς να διαθέσεις;
>>     
>
> Τώρα 1,3 ΤΒ και άμεσα αν παραστεί ανάγκη επιπλέον 2 ΤΒ.
>   
Χωρίς να ξέρουμε όμως τον όγκο των δεδομένων που θα ασφαλίσεις και τον 
ρυθμό μεταβολής τους, αυτή η πληροφορία είναι μάλλον άχρηστη :(

>> - Πόσα συστήματα (clients) θα ασφαλίσεις; Πόσο απομακρυσμένα είναι 
>> γεωγραφικά;
>>     
>
> * 2 laptop, local
> * 1 directory σε ftp server (το πολύ 1χλμ. σε ευθεία απόσταση), σύνδεση
> τοπικού δικτύου μέσω WLAN με το δίκτυο του πανεπιστημίου.
>   
Για το ftp directory μάλλον θα χρειαστεί νά κάνεις καθημερινά τοπικό 
mirroring πριν το αντίγραφο ασφαλείας.

>> - Πόσο χρόνο την εβδομάδα μπορείς να διαθέσεις για να "νταντεύεις" τα 
>> αντίγραφα ασφαλείας σου;
>>     
>
> Όσο χρειαστεί για να γίνει σωστά η δουλειά αρχικά ώστε να χρειάζεται όλο
> και λιγότερο human input αργότερα.
>   
Το αρχικό (όπως πιθανότατα έχεις αρχίσει να υποψιάζεσαι) μπορεί να είναι 
ΠΟΛΥ, μα ΠΑΡΑ πολύ! Στις περισσότερες περιπτώσεις η προσπάθεια που θα 
χρειαστεί αργότερα είναι αντιστρόφως ανάλογη του τετραγώνου της αρχικής 
προσπάθειας (ναι, το μοντέλο είναι ολοσχερώς αυθαίρετο και δεν πρέπει να 
το πάρεις τοις μετρητοίς). Τα υπόλοιπα ελπίζω ότι θα τα συνάγεις από τα 
συμφραζόμενα.

>> - Υπάρχει (ή είναι πολύ πιθανό να υπάρξει σύντομα) ανάγκη προστασίας
>> από φυσική καταστροφή που απαιτεί αντίγραφα να βρίσκονται σε
>> απομακρυσμένη τοποθεσία;
>>     
>
> Δεν ξέρω τι εννοείς εδώ με το "φυσική καταστροφή" (δηλ., σεισμός,
> πυρκαγιά, πλημμύρα ή απλά να τα παίξει ο δίσκος από "φυσική" φθορά;)
> αλλά σε κάθε περίπτωση *πάντα* υπάρχει η ανάγκη προστασίας από "φυσική"
> καταστροφή γενικότερα. Όλα είναι πιθανά!
>   
Εννοώ κυρίως την πυρκαγιά / πλυμμήρα και οτιδήποτε είναι πιθανόν να 
καταστρέψει μονοκοντυλιά τόσο τα πρωτογενή δεδομένα όσο και τα 
αντίγραφα. Για αυτές τις περιπτώσεις, οι συνήθεις λύσεις είναι η 
μετακίνηση π.χ. των μηνιαίων ταινιών / δίσκων σε άλλη τοποθεσία, ή η 
πραγματοποίηση κάποιων (ή όλων) των αντιγράφων κάπου αλλού μέσω δικτύου. 
Οι περιορισμοί και τα κόστη σε κάθε περίπτωση είναι, νομίζω, προφανή.

Δευτερευόντως, πρέπει να λάβεις υπ' όψη σου και την πιθανότητα αστοχίας 
υλικού στα αντίγραφά σου (οι πλέον παρανοϊκοί εφαρμόζουν σατανιστικές 
λύσεις τύπου RAIT [6] ή mirrored δίσκους).

>> - Πόσο συχνά χρειάζεται να είναι τα αντίγραφα; (μεταφράζεται σε: πόσες
>> ώρες / μέρες αλλαγών μπορείς να ανεχτείς να χαθούν;)
>>     
>
> Κάθε μέρα νομίζω είναι απαραίτητο για όσα δεδομένα υφίστανται αλλαγές.
>
>   
>> Όσο για το git (ή οποιοδήποτε άλλο VCS)]
>> - πρώτον: ΔΕΝ είναι backup,
>>     
>
> Σύμφωνοι. Αλλά, κατά τη γνώμη μου, έχει κανείς λόγους να ασχοληθεί αυτό
> ακόμη και αν δεν είναι υπερ-προγραμματιστής (βλέπε και [*]). Συν τοις
> άλλοις, χρησιμοποιώ το git για τα όλα τα ντοκουμέντα μου είναι (αρχεία
> LyX == απλό κείμενο ουσιαστικά :-).
>
>   
>> δεύτερον: πολύ σπάνια είναι η καλύτερη λύση για δεδομένα που διαφέρουν
>> δραστικά από πηγαίο κώδικα.
>>     
>
> Προφανώς και δεν είμαι ειδήμων και καταλαβαίνω όσα μπορώ να εκμαιεύσω
> από συζητήσεις όπως αυτή στο [3].
>
>   
Εφ' όσον κατανοείς ότι τα VCS αποθετήρια δεν είναι από μόνα τους 
αντίγραφα αλλά χρήζουν ασφάλισης, έχεις πιάσει την ουσία :-) Λάβε και 
πάλι υπ' όψη ότι ενδεχομένως να χρειαστεί ειδική μεταχείριση όπως στην 
περίπτωση των βάσεων δεδομένων.


Επί της ουσίας τώρα:

Η βασική επιλογή σου είναι μεταξύ δύο κατευθύνσεων - είτε θα 
χρησιμοποιήσεις κάποιο "απλό" εργαλείο (π.χ. fwbackup, sbackup, rbackup, 
hashbackup, κάποιο τυχαίο ή αυτοσχέδιο shell script) ή θα πας σε 
"ενήλικα" backup περιβάλλοντα όπως το bacula ή το amanda. [7], [8]

Τα δεύτερα είναι πολύ πιο πολύπλοκα, απαιτούν πολύ διάβασμα, σκέψη και 
προσπάθεια για να υλοποιηθούν και συνήθως προϋποθέτουν αυτόνομο (ή 
σχεδόν αυτόνομο) εξυπηρετητή. Τα πλεονεκτήματά τους είναι ότι είναι πολύ 
πιο ευέλικτα, μεγαλώνουν μαζί σου (εκατοντάδες clients, petabytes 
αντιγράφων) και κάνουν τη ζωή σου απλή εκεί που μετράει περισσότερο: 
Στην ανάκτηση.

Τα απλούστερα εργαλεία θέλουν λίγη (η και ελάχιστη) προσπάθεια 
υλοποίησης και συνήθως απευθύνονται σε οικιακούς χρήστες με απλές ανάγκες.

Για κλείσιμο, μια επισήμανση: Ό, τι και να διαλέξεις, όπως και να το 
υλοποιήσεις, μην παραλείψεις για κανένα λόγο να κάνεις μια δοκιμαστική 
ανάκτηση μετά από μερικές ημέρες. Ναι, είναι τεράστιος μπελάς (ο 
"σωστός" τρόπος είναι να ξεκινήσεις με έναν καινούργιο ή πρόσφατα 
formatted υπολογιστή) αλλά το μόνο χειρότερο από το καθόλου backup, 
είναι το backup που δε δουλεύει όταν το χρειαστείς!

Καλό κουράγιο και αχρείαστο να 'ναι ;-)

> [...]
>
> Ελπίζω να είναι χρήσιμη η συζήτηση και σε άλλους φίλους της λίστας.
>   
Επειδή εγώ είμαι πολυ-asshole-ος (διάβαζε τεμπέλαρος), αν έχει κανείς 
την όρεξη να μαζέψει τα παραπάνω σε κάποιο wiki / forum.
> Milles mercis, Νίκος
>   

Φιλικά,

Απόλλων



>
>   
>>> ---
>>> [1]
>>>
>>>       
>> http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html
>>     
>>> [2] http://eigenclass.org/hiki/gibak-backup-system-introduction
>>>
>>> [3] http://kerneltrap.org/mailarchive/git/2006/12/12/233113/thread
>>>       
>
> [*]
> http://mendicantbug.com/2008/11/30/10-reasons-to-use-git-for-research/
>   
[4] 
http://www.devarticles.com/c/a/MySQL/Backing-Up-Your-MySQL-Databases-With-MySQLDump/
[5] http://en.wikipedia.org/wiki/Log-structured_file_system
[6] http://www.thic.org/pdf/Oct00/stk.mfisher.pdf
[7] http://blogs.techrepublic.com.com/10things/?p=895
[8] http://linux.about.com/od/softbackup/Linux_Software_Backup_Solutions.htm