Re: Αντίγραφα ασφαλείας βάσει git;
Ευχαριστώ για την πλήρη απάντηση. Τώρα τη διάβασα (στα γρήγορα) επειδή δεν την έβρισκα επειδή... (άσε, άλλη ιστορία, για μια άλλη φορά για πολύ γέλιο :D). [snip-ped] Apollon Koutlidis wrote: > >> - Τι μέσο αποθήκευσης θέλεις / προτιμάς / μπορείς να χρησιμοποιήσεις > >> για τα αντίγραφα ασφάλειας; ταινία, δίσκος, μηχανογραφικό χαρτί... Nikos Alexandris wrote: > > Εξωτερικός(-οί) σκληρός(-οί) δίσκος(-οί) με θύρα firewire(x800) ή USB2. On Wed, 2009-11-04 at 19:09 +, Apollon Koutlidis wrote: > Η χρήση εξωτερικού δίσκου για αντίγραφα ασφαλείας είναι θεμιτή αλλά όχι > ιδιαίτερα scalable (κλιμακώσιμη!;) λύση. Για 2 clients καλό το ακούω, αν > αυξηθούν μάλλον είναι σκόπιμο να αρχίσεις να σκέφτεσαι δικτυακές λύσεις > με κεντρικό backup server. Σημαντικό είναι οι δίσκοι να μην είναι > μονίμως συνδεδεμένοι στα αντίστοιχα συστήματα, ειδ' άλλως αυξάνεις την > πιθανότητα να συμβεί κάτι στα αντίγραφά σου. > >> - Τι είδους δεδομένα θα ασφαλίσεις; Πόσο συχνά αλλάζουν; Λάβε υπ' όψη > >> ότι κάποιοι τύποι δεδομένων (π.χ. databases) χρήζουν ειδικής > >> μεταχείρισης - ένα απλό cp / rsync δεν αρκεί (όχι από μόνο του). > >> > > > > (1) - Από τα πιο "συνηθισμένα" (φωτογραφίες, μουσική, ντοκουμέντα), > > > > - μέχρι απλά σενάρια (bash, python, R για τα οποία ήδη χρησιμοποιώ > > το git τοπικά) > > > > - και "πολύπλοκα" (γεω-χωρικά δεδομένα με τα μετα-δεδομένα τους, > > βάσεις γεω-δεδομένων == συνηθισμένοι κατάλογοι με υποκαταλόγους και > > αρχεία υπό το GRASS-GIS, αρκετά sqlite.db's, πιθανόν και άλλες βάσεις > > -φερ' ειπείν PostGIS(PostgreSQL)-) > > > > (2) Αλλάζουν καθημερινά. > > > > Ερώτηση: ποια είναι η απαιτούμενη ειδική μεταχείριση που χρήζουν κάποιες > > βάσεις δεδομένων; > > > Άρα έχεις ανάμεικτα δεδομένα ως προς τύπο, και δε μας είπες τι ποσοστό > των δεδομένων σου αλλάζει :) λογικό είναι βέβαια να μην ξέρεις κιόλα > αφού δεν έχεις ακόμα λύση backup. Εμμ... είναι πολύ δύσκολη η εκτίμηση αυτή. - Ξεκίνησα (πάλι) ερασιτεχνικά να φωτογραφίζω και (ίσως) κακώς αλλά οι φωτογραφίες τρώνε αχόρταγα τα GBs. - Τα κείμενα, ντοκουμέντα είναι αστείο να πει κανείς ότι είναι πρόβλημα για ένα μέσο χρήστη (προς λίγο πιο αφοσιωμένο). - Τα γεω-δεδομένα είναι πολλά και θα γίνουν ακόμη πιο πολλά (χοντρικά ~300GB). - Η μουσική είναι αρκετή αλλά όχι πάρα πολύ. Δεν ασχολούμαι με "κατεβάσματα" οπότε απλά τη θέλω σε μια γωνιά ασφαλισμένη. --%<--- > Οι βάσεις δεδομένων - όπως και πολλές άλλες εφαρμογές - δεν προσφέρονται > για αντίγραφα ασφαλείας ως έχουν, διότι η κατάστασή τους βρίσκεται εν > μέρει στον δίσκο και εν μέρει στη μνήμη. Οι διαθέσιμες μέθοδοι ασφάλισης > είναι πολλές και εξαρτώνται από την εφαρμογή. Η απλούστερη λύση είναι να > κλείσεις την εφαρμογή από την αρχή μέχρι το τέλος της αντιγραφής. Οι > περισσότερες βάσεις δεδομένων διαθέτουν και μεθόδους hot / warm backup > (π.χ. mysqldump [4]) εάν το downtime είναι πρόβλημα. Σε αυτές τις > περιπτώσεις τυπικά κάνεις ένα αντίγραφο σε αρχείο στον δίσκο και > αντιγράφεις μόνον αυτό. Ένας λόγος που χρησιμιποιώ sqlite ως backend στο GRASS είναι και αυτός. Είναι απλά αρχεία (όχι client-server) και απλά τα συμπιέζει/αντιγράφει κανείς. Αλλά πιθανόν να υπάρξουν και άλλα δεδομένα που απαιτούν κάτι άλλο από sqlite. --%<--- > Μία ακόμα παράμετρος που αξίζει να έχεις υπ' όψη: Όπου υπάρχουν πολλά, > μικρά αρχεία (π.χ. email), εμφανίζεται το πρόβλημα της διαμεταγωγής των > μεταδεδομένων - συνήθως αυτό μεταφράζεται σε μειωμένες ταχύτητες > αντιγραφής και αυξημένο όγκο των καταλόγων των αντιγράφων. Ενδιαφέρον. --%<--- > >> - Τι μέσο μετάδοσης θα χρησιμοποιηθεί; Ethernet / Fibre channel / > >> SCSI / USB...; Και με τι ταχύτητα διαμεταγωγής; > >> > > > > Firewire (up to ~115MB/s), USB2 (up to ???) > > > Όπως είπα και παραπάνω, όσο έχεις λίγους clients και δε χρειάζεσαι > κεντρικό server τα πράγματα είναι γενικώς πιο απλά. Προς το παρόν θα παραμείνουν απλά. --%<--- > >> - Τι βάθος ιστορικού θέλεις; > >> > > > > Θέλω να υπάρχουν όλα και να αποφασίζω εγώ τι θα χάνεται για πάντα > > ανάλογα με το διαθέσιμο ελεύθερο χώρο. > > > > > Εδώ μου τα μπερδεύεις. ;-) --%<--- > Δεν έχω υπ' όψη μου κάποια λύση που να κάνει αυτή > τη δουλειά (ίσως με εξαίρεση τα αμφιβόλου ωριμότητας logging filesystems > τύπου NILFS / JFFS [5] αλλά δε θα σου συνιστούσα να κολυμπήσεις σε αυτή > τη θάλασσα!). Το git είναι κάτι το φανταστικό. Γι' αυτό έχει κολλήσει το μυαλό μου στο git. Δεν αντιγράφει νέα αρχεία, αλλά μόνο τις αυτές καθ'αυτές αλλαγές (σωστά). Αλλά πάλι, είπαμε, δεν είναι για binary αρχεία. --%<--- > Είτε θα κάνεις καθημερινά πλήρη αντίγραφα (κάτι που απαιτεί πολύυυ > αποθηκευτικό χώρο), είτε θα κάνεις περιοδικά (π.χ. εβδομαδιαία) πλήρη > και στο ενδιάμεσο incremental / differential (τα πρώτα αποθηκεύουν μόνο > τις αλλαγές από το προηγούμενο incremental και τα δεύτερα, όπου είναι > διαθέσιμα, τις αλλαγές από το τελευταίο πλήρες). Όσο μεγαλύτερο το > διάστημα μεταξύ των πλήρων, τόσο πιο πολύπλοκη είναι η ανάκτηση (και > προφανώς το ρίσκ
Re: Αντίγραφα ασφαλείας βάσει git;
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 πριν το αντίγραφο ασφαλείας. >> - Πόσο χρόνο την εβδομάδα μπορείς να διαθέσεις για να "νταντεύεις" τα >> αντίγραφα ασφαλείας σου; >> > > Όσο χρειαστεί για να γίνει σωστά η δουλειά αρχικά ώστε να χρειάζεται όλο >
Re: Αντίγραφα ασφαλείας βάσει git;
[...] (Εσκεμμένα έχω σβήσει το αρχικό μήνυμά μου.) --%<--- Apollon Koutlidis wrote: > Το θέμα του τακτικού (as in regular, not tactical) backup είναι > μεγάλο > και ακανθώδες... και οι λύσεις είναι τουλάχιστον όσα και τα > διαφορετικά > σενάρια - δηλαδή αμέτρητες :) Όπως με κάθε πολύπλοκο πρόβλημα, η > ποιότητα της απάντησης / λύσης είναι ευθέως ανάλογη της ποιότητας της > ερώτησης / διατύπωσης. Πρώτα και πάνω απ' όλα σ' ευχαριστώ για τον πολύτιμο χρόνο που διέθεσες να απαντήσεις και να θέσεις "σωστά" ερωτήματα. Αρκετά από τα παρακάτω ερωτηματικά μου είναι γνωστά και άλλα πάλι τα διαβάζω για πρώτη φορά. Θα προσπαθήσω να είμαι σύντομος και σαφής στις απαντήσεις μου. --%<--- > - Τι μέσο αποθήκευσης θέλεις / προτιμάς / μπορείς να χρησιμοποιήσεις > για τα αντίγραφα ασφάλειας; ταινία, δίσκος, μηχανογραφικό χαρτί... Εξωτερικός(-οί) σκληρός(-οί) δίσκος(-οί) με θύρα firewire(x800) ή USB2. --%<--- > - Τι είδους δεδομένα θα ασφαλίσεις; Πόσο συχνά αλλάζουν; Λάβε υπ' όψη > ότι κάποιοι τύποι δεδομένων (π.χ. databases) χρήζουν ειδικής > μεταχείρισης - ένα απλό cp / rsync δεν αρκεί (όχι από μόνο του). (1) - Από τα πιο "συνηθισμένα" (φωτογραφίες, μουσική, ντοκουμέντα), - μέχρι απλά σενάρια (bash, python, R για τα οποία ήδη χρησιμοποιώ το git τοπικά) - και "πολύπλοκα" (γεω-χωρικά δεδομένα με τα μετα-δεδομένα τους, βάσεις γεω-δεδομένων == συνηθισμένοι κατάλογοι με υποκαταλόγους και αρχεία υπό το GRASS-GIS, αρκετά sqlite.db's, πιθανόν και άλλες βάσεις -φερ' ειπείν PostGIS(PostgreSQL)-) (2) Αλλάζουν καθημερινά. Ερώτηση: ποια είναι η απαιτούμενη ειδική μεταχείριση που χρήζουν κάποιες βάσεις δεδομένων; --%<--- > - Τι μέσο μετάδοσης θα χρησιμοποιηθεί; Ethernet / Fibre channel / > SCSI / USB...; Και με τι ταχύτητα διαμεταγωγής; Firewire (up to ~115MB/s), USB2 (up to ???) --%<--- > - Τι βάθος ιστορικού θέλεις; Θέλω να υπάρχουν όλα και να αποφασίζω εγώ τι θα χάνεται για πάντα ανάλογα με το διαθέσιμο ελεύθερο χώρο. --%<--- > Πόσο αποθηκευτικό χώρο μπορείς να διαθέσεις; Τώρα 1,3 ΤΒ και άμεσα αν παραστεί ανάγκη επιπλέον 2 ΤΒ. --%<--- > - Πόσα συστήματα (clients) θα ασφαλίσεις; Πόσο απομακρυσμένα είναι > γεωγραφικά; * 2 laptop, local * 1 directory σε ftp server (το πολύ 1χλμ. σε ευθεία απόσταση), σύνδεση τοπικού δικτύου μέσω WLAN με το δίκτυο του πανεπιστημίου. --%<--- > - Πόσο χρόνο την εβδομάδα μπορείς να διαθέσεις για να "νταντεύεις" τα > αντίγραφα ασφαλείας σου; Όσο χρειαστεί για να γίνει σωστά η δουλειά αρχικά ώστε να χρειάζεται όλο και λιγότερο human input αργότερα. --%<--- > - Υπάρχει (ή είναι πολύ πιθανό να υπάρξει σύντομα) ανάγκη προστασίας > από φυσική καταστροφή που απαιτεί αντίγραφα να βρίσκονται σε > απομακρυσμένη τοποθεσία; Δεν ξέρω τι εννοείς εδώ με το "φυσική καταστροφή" (δηλ., σεισμός, πυρκαγιά, πλημμύρα ή απλά να τα παίξει ο δίσκος από "φυσική" φθορά;) αλλά σε κάθε περίπτωση *πάντα* υπάρχει η ανάγκη προστασίας από "φυσική" καταστροφή γενικότερα. Όλα είναι πιθανά! --%<--- > - Πόσο συχνά χρειάζεται να είναι τα αντίγραφα; (μεταφράζεται σε: πόσες > ώρες / μέρες αλλαγών μπορείς να ανεχτείς να χαθούν;) Κάθε μέρα νομίζω είναι απαραίτητο για όσα δεδομένα υφίστανται αλλαγές. --%<--- > Αυτές είναι μερικές μόνο από τις ερωτήσεις που χρήσουν απαντήσεων πριν > αρχίσεις να συζητάς την τεχνολογική άποψη... > Όσο για το git (ή οποιοδήποτε άλλο VCS)] > - πρώτον: ΔΕΝ είναι backup, Σύμφωνοι. Αλλά, κατά τη γνώμη μου, έχει κανείς λόγους να ασχοληθεί αυτό ακόμη και αν δεν είναι υπερ-προγραμματιστής (βλέπε και [*]). Συν τοις άλλοις, χρησιμοποιώ το git για τα όλα τα ντοκουμέντα μου είναι (αρχεία LyX == απλό κείμενο ουσιαστικά :-). > δεύτερον: πολύ σπάνια είναι η καλύτερη λύση για δεδομένα που διαφέρουν > δραστικά από πηγαίο κώδικα. Προφανώς και δεν είμαι ειδήμων και καταλαβαίνω όσα μπορώ να εκμαιεύσω από συζητήσεις όπως αυτή στο [3]. [...] Ελπίζω να είναι χρήσιμη η συζήτηση και σε άλλους φίλους της λίστας. 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/ signature.asc Description: This is a digitally signed message part -- Ubuntu-gr mailing list Ubuntu-gr@lists.ubuntu.com If you do not want to receive any more messages from the ubuntu-gr mailing list, please follow this link and choose unsubscribe: https://lists.ubuntu.com/mailman/listinfo/ubuntu-gr
Re: Αντίγραφα ασφαλείας βάσει git;
Nikos Alexandris wrote: [snip] > Θέλω όμως να ρωτήσω (κάτι) σχετικά με τα αντίγραφα ασφαλείας. Το βρίσκω > κουραστικό να ψάχνω κάθε φορά τι και από που θέλω να αποθηκεύσω. Ακόμη > και στην περίπτωση της αυτοματοποιημένης (περιοδικά προγραμματισμένης με > τη βοήθεια κάποιου σεναρίου) αποθήκευσης δεδομένων υπάρχουν κάποια > (σημαντικά) μειονεκτήματα που σχετίζονται με το διαθέσιμο ελεύθερο χώρο > [1], με δεδομένα που σβήνονται κατά λάθος, με "αλλαγές" που πιθανόν > κάποιος θέλει να ακυρώσει και άλλα πολλά. > > > Οπότε και ψάχνω εδώ και καιρό κάποιο εργαλείο backup που να είναι όπως > (ή καλύτερα να χρησιμοποιεί) το git (ως βάση). Υπήρχε/ υπάρχει το gibak > [2] αλλά δεν είμαι σίγουρος ότι συντηρείται/ αναβαθμίζεται/ κ.λπ. > > > Από τα λίγα που γνωρίζω, το git πιθανότατα δεν ενδείκνυται για την > "παρακολούθηση" binary αρχείων (π.χ. βλέπε συζήτηση σχετικά με > permissions [3]). > > > Γνωρίζει κανείς κάποια "καλή" λύση; > Ευχαριστώ εκ των προτέρων, Νίκος > Το θέμα του τακτικού (as in regular, not tactical) backup είναι μεγάλο και ακανθώδες... και οι λύσεις είναι τουλάχιστον όσα και τα διαφορετικά σενάρια - δηλαδή αμέτρητες :) Όπως με κάθε πολύπλοκο πρόβλημα, η ποιότητα της απάντησης / λύσης είναι ευθέως ανάλογη της ποιότητας της ερώτησης / διατύπωσης. - Τι μέσο αποθήκευσης θέλεις / προτιμάς / μπορείς να χρησιμοποιήσεις για τα αντίγραφα ασφάλειας; ταινία, δίσκος, μηχανογραφικό χαρτί... - Τι είδους δεδομένα θα ασφαλίσεις; Πόσο συχνά αλλάζουν; Λάβε υπ' όψη ότι κάποιοι τύποι δεδομένων (π.χ. databases) χρήζουν ειδικής μεταχείρισης - ένα απλό cp / rsync δεν αρκεί (όχι από μόνο του). - Τι μέσο μετάδοσης θα χρησιμοποιηθεί; Ethernet / Fibre channel / SCSI / USB...; Και με τι ταχύτητα διαμεταγωγής; - Τι βάθος ιστορικού θέλεις; Πόσο αποθηκευτικό χώρο μπορείς να διαθέσεις; - Πόσα συστήματα (clients) θα ασφαλίσεις; Πόσο απομακρυσμένα είναι γεωγραφικά; - Πόσο χρόνο την εβδομάδα μπορείς να διαθέσεις για να "νταντεύεις" τα αντίγραφα ασφαλείας σου; - Υπάρχει (ή είναι πολύ πιθανό να υπάρξει σύντομα) ανάγκη προστασίας από φυσική καταστροφή που απαιτεί αντίγραφα να βρίσκονται σε απομακρυσμένη τοποθεσία; - Πόσο συχνά χρειάζεται να είναι τα αντίγραφα; (μεταφράζεται σε: πόσες ώρες / μέρες αλλαγών μπορείς να ανεχτείς να χαθούν;) Αυτές είναι μερικές μόνο από τις ερωτήσεις που χρήσουν απαντήσεων πριν αρχίσεις να συζητάς την τεχνολογική άποψη... Όσο για το git (ή οποιοδήποτε άλλο VCS) - πρώτον: ΔΕΝ είναι backup, δεύτερον: πολύ σπάνια είναι η καλύτερη λύση για δεδομένα που διαφέρουν δραστικά από πηγαίο κώδικα. Διαφώτισέ με (και τη λίστα) λίγο περισσότερο σχετικά με τις ανάγκες σου και στη συνέχεια θα συζητήσουμε περισσότερο για το ποια είναι η καλύτερη λύση. Φιλικά, Απόλλων > --- > > [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 > -- Ubuntu-gr mailing list Ubuntu-gr@lists.ubuntu.com If you do not want to receive any more messages from the ubuntu-gr mailing list, please follow this link and choose unsubscribe: https://lists.ubuntu.com/mailman/listinfo/ubuntu-gr
