GIT comme outil de sauvegarde

101

Sur un serveur, installez git

cd /
git init
git add .
git commit -a -m "Yes, this is server"

Ensuite, /.git/pointez sur un lecteur réseau (SAN, NFS, Samba ou autre) ou un autre disque. Utilisez un travail cron toutes les heures / tous les jours, etc. pour mettre à jour les modifications. Le répertoire .git contiendrait une copie versionnée de tous les fichiers du serveur (à l'exception des fichiers inutiles / compliqués comme / proc, / dev, etc.)

Pour un serveur de développement non important pour lequel je ne veux pas avoir la peine de le configurer sur un système de sauvegarde approprié, et où les sauvegardes seraient uniquement commodes (IE, nous n'avons pas besoin de sauvegarder ce serveur, mais cela économiserait Cela pourrait-il être une solution de sauvegarde valide ou tombera-t-il dans un gros tas de caca?

Tache
la source
3
ne scintille pas en utilisant une idée similaire?
B14D3
@ B14D3 Je pense que sparkleshare est plus une sorte de chose dropbox de type, mais je vais examiner
Smudge
2
vous avez raison, mais il utilise git pour créer une sorte de problème (copier sur plusieurs ordinateurs et contrôler les versions de fichiers);)
B14D3
Le gros problème avec cela est qu’il n’ya pas de contrôle central - vous devez avoir un accès direct (ssh) à la machine pour effectuer toute forme de validation de maintenance ou de sauvegarde. Je trouve toujours d'installer une application sur les boîtes à sauvegarder, puis de les administrer à partir d'un emplacement central est un gain beaucoup plus important.
hafichuk
@hafichuk Avec des outils comme Puppet / Chef, ce n'est pas un gros problème, mais je vois ce que vous voulez dire.
Smudge

Réponses:

88

Vous n'êtes pas une personne stupide. Utiliser gitcomme mécanisme de sauvegarde peut être intéressant, et malgré ce que d’autres ont dit, gitfonctionne très bien avec les fichiers binaires. Lisez cette page du livre Git pour plus d’informations sur ce sujet. En fait, depuis gitest de ne pas utiliser un mécanisme de stockage du delta, il ne se soucie pas vraiment ce que vos fichiers ressemblent (mais l'utilité git diffest assez faible pour les fichiers binaires avec une configuration de stock).

Le plus gros problème de l'utilisation gitde la sauvegarde est qu'elle ne conserve pas la plupart des métadonnées du système de fichiers. Plus précisément, gitn'enregistre pas:

  • groupes de fichiers
  • propriétaires de fichiers
  • autorisations de fichier (autre que "est-ce l'exécutable")
  • attributs étendus

Vous pouvez résoudre ce problème en écrivant des outils pour enregistrer ces informations de manière explicite dans votre référentiel, mais il peut être délicat de les obtenir correctement.

Une recherche Google sur les métadonnées de sauvegarde git donne un certain nombre de résultats qui méritent d'être lus (y compris des outils qui tentent déjà de compenser les problèmes que j'ai évoqués ici).

etckeeper a été développé pour la sauvegarde /etcet résout beaucoup de ces problèmes.

alsacs
la source
16
+1 pour avoir mentionné les ACL / permissions
Larry Silverman
23
Git ne stocke pas non plus les répertoires vides.
Flimm
et ça craint aussi pour le suivi du déplacement / renommage de fichiers, à travers l’historique.
cregox
1
Puisque git ne traite pas très bien les fichiers binaires, vous pouvez également vous pencher sur l’ annexe git , ce qui permet de mieux le faire. Cela change cependant l'idée de ce que c'est génial.
Wouter Verhelst
1
Mon avis est que vous pouvez utiliser git pour sauvegarder des données mais pas des serveurs entiers
EKanadily
21

Je ne l'ai pas utilisé, mais vous pouvez regarder bup, un outil de sauvegarde basé sur git.

Ragoût
la source
Jamais vu bup auparavant, l'air intéressant
Smudge
1
J'ai commencé à utiliser bup récemment, quelques jours avant que mon disque dur ne tombe en panne;) La restauration s'est bien passée, je le recommande donc!
André Paramés
1
@ AndréParamés donc ce que vous dites, c'est juste après que vous ayez installé votre disque dur qui s'est écrasé ... mmmmhh ... :) je plaisante
hofnarwillie
12

Cela peut être une solution de sauvegarde valide, etckeeper est basé sur cette idée. Mais gardez un œil sur les .gitautorisations du répertoire, sinon vous /etc/shadowpourrez lire le .gitrépertoire dans le répertoire.

Pierre
la source
11

Bien que techniquement, vous puissiez le faire, je mettrais deux réserves à son encontre:

1, vous utilisez un système de contrôle de version source pour les données binaires. Vous l'utilisez donc pour quelque chose pour lequel il n'a pas été conçu.

2, je m'inquiète de votre processus de développement si vous ne disposez pas d'un processus (documentation ou automatisé) pour la construction d'une nouvelle machine. Et si vous deviez acheter un bus, qui saurait quoi faire et ce qui était important?

La reprise après sinistre est importante, mais il est préférable d’automatiser (par script) la configuration d’un nouveau boîtier de développement plutôt que de tout sauvegarder. Utilisez bien git pour votre script / documentation mais pas pour tous les fichiers sur un ordinateur.

Phil Hannent
la source
4
Les boîtes de développement proviennent toutes de fichiers KickStart et durent en moyenne deux ou trois mois avant d'être reconstruites. Mais les gens changent de configuration et font des choses, nous reconstruisons les boîtes et les gens disent: "Hé, je sais que je ne l’ai pas mis dans le contrôle de la source mais j’avais de la merde sur cette boîte" et je me moque de leur stupidité. Tout autour, bons moments. Les données binaires seraient une chienne, c'est quelque chose que j'ai totalement négligé sous la douche.
Smudge
J'applaudis votre attitude envers ceux qui ne parviennent pas à suivre les principes de base. Personnellement, je suis dans une situation similaire à vous, mais j’ai un référentiel git qui relie dans tous les fichiers de configuration ce qui pourrait être important plutôt que de tout attraper. Plus un doc txt avec les étapes d'installation.
Phil Hannent
1
Je pense que git fonctionne assez bien pour les fichiers binaires, car la majeure partie du référentiel de Google Android est constituée de référentiels git contenant des exécutables prédéfinis.
user377178
6

J'utilise git comme sauvegarde pour mon système Windows, et cela a été incroyablement utile. Au bas de l'article, je montre les scripts que j'utilise pour configurer sur un système Windows. Utiliser git en tant que sauvegarde pour n’importe quel système offre 2 grands avantages:

  1. Contrairement aux solutions commerciales qui utilisent souvent leur propre format propriétaire, votre sauvegarde est dans un format open source largement pris en charge et très bien documenté. Cela vous donne le contrôle total de vos données. Il est très facile de voir quels fichiers ont changé et quand. Si vous souhaitez tronquer votre historique, vous pouvez également le faire. Voulez-vous effacer quelque chose de votre histoire? Aucun problème. Obtenir une version de votre fichier est aussi simple que n'importe quelle commande git.
  2. Autant de ou peu de miroirs que vous voulez, et tous peuvent avoir des temps de sauvegarde personnalisés. Vous obtiendrez votre miroir local, libéré du trafic Internet lent, ce qui vous donne (1) la possibilité d'effectuer des sauvegardes plus fréquentes tout au long de la journée et (2) un temps de restauration rapide. (Les sauvegardes fréquentes sont un avantage considérable, car je trouve que plus le temps que je perds un document est dû à une erreur de l'utilisateur. Par exemple, votre enfant écrase accidentellement un document sur lequel il travaille depuis 5 heures.) Mais vous obtiendrez votre miroir distant, qui offre l’avantage de la protection des données en cas de sinistre local ou de vol. Et supposez que vous souhaitiez que votre miroir distant soit sauvegardé au moment voulu pour économiser votre bande passante Internet? Aucun problème.

En bout de ligne: une sauvegarde git vous donne une quantité incroyable de puissance pour contrôler le déroulement de vos sauvegardes.

Je l'ai configuré sur mon système Windows. La première étape consiste à créer le dépôt git local dans lequel vous allez valider toutes vos données locales. Je recommande d'utiliser un deuxième disque dur local, mais utiliser le même disque dur fonctionnera correctement (mais on s'attend à ce que vous le poussiez quelque part à distance, ou sinon votre vissé si le disque dur meurt.)

Vous devez d’abord installer cygwin (avec rsync), ainsi que git pour Windows: http://git-scm.com/download/win

Ensuite, créez votre dépôt Git local (n’exécutez qu’une seule fois):

init-repo.bat:

@echo off
REM SCRIPT PURPOSE: CREATE YOUR LOCAL GIT-REPO (RUN ONLY ONCE)

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror


REM Create the backup git repo. 
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
mkdir %GBKUP_LOCAL_MIRROR_HOME%
git %GIT_PARAMS% init
git %GIT_PARAMS% config core.autocrlf false
git %GIT_PARAMS% config core.ignorecase false 
git %GIT_PARAMS% config core.fileMode false
git %GIT_PARAMS% config user.email backup@yourComputerName
git %GIT_PARAMS% config user.name backup

REM add a remote to the git repo.  Make sure you have set myRemoteServer in ~/.ssh/config   
REM The path on the remote server will vary.  Our remote server is a Windows machine running cygwin+ssh.  
REM For better security, you could install gitolite on the remote server, and forbid any non-fast-forward merges, and thus stop a malicious user from overwriting your backups.
git %GIT_PARAMS% remote add origin myRemoteServer:/cygdrive/c/backup/yourComputerName.git

REM treat all files as binary; so you don't have to worry about autocrlf changing your line endings
SET ATTRIBUTES_FILE=%GBKUP_LOCAL_MIRROR_HOME%\.git\info\attributes
echo.>> %ATTRIBUTES_FILE% 
echo *.gbkuptest text>> %ATTRIBUTES_FILE% 
echo * binary>> %ATTRIBUTES_FILE% 
REM compression is often a waste of time with binary files
echo * -delta>> %ATTRIBUTES_FILE% 
REM You may need to get rid of windows new lines. We use cygwin's tool
C:\cygwin64\bin\dos2unix %ATTRIBUTES_FILE%

Ensuite, nous avons notre wrapper de script de sauvegarde, qui sera appelé régulièrement par le planificateur Windows:

gbackup.vbs:

' A simple vbs wrapper to run your bat file in the background
Set oShell = CreateObject ("Wscript.Shell") 
Dim strArgs
strArgs = "cmd /c C:\opt\gbackup\gbackup.bat"
oShell.Run strArgs, 0, false

Ensuite, nous avons le script de sauvegarde lui-même que le wrapper appelle:

gbackup.bat:

    @echo off

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror
REM the user which runs the scheduler
SET GBKUP_RUN_AS_USER=yourWindowsUserName
REM exclude file
SET GBKUP_EXCLUDE_FILE=/cygdrive/c/opt/gbackup/exclude-from.txt

SET GBKUP_TMP_GIT_DIR_NAME=git-renamed
for /f "delims=" %%i in ('C:\cygwin64\bin\cygpath %GBKUP_LOCAL_MIRROR_HOME%') do set GBKUP_LOCAL_MIRROR_CYGWIN=%%i

REM rename any .git directories as they were (see below command)
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (%GBKUP_TMP_GIT_DIR_NAME%) do ren "%%i" ".git" 2> nul

SET RSYNC_CMD_BASE=C:\cygwin64\bin\rsync -ahv --progress --delete --exclude-from %GBKUP_EXCLUDE_FILE%

REM rsync all needed directories to local mirror
%RSYNC_CMD_BASE% /cygdrive/c/dev %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/asmith %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/bsmith %GBKUP_LOCAL_MIRROR_CYGWIN%

cacls %GBKUP_LOCAL_MIRROR_HOME% /t /e /p  %GBKUP_RUN_AS_USER%:f

REM rename any .git directories as git will ignore the entire directory, except the main one
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (.git) do ren "%%i" "%GBKUP_TMP_GIT_DIR_NAME%" 2> nul
ren %GBKUP_LOCAL_MIRROR_HOME%\%GBKUP_TMP_GIT_DIR_NAME% .git

REM finally commit to git
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
SET BKUP_LOG_FILE=%TMP%\git-backup.log
SET TO_LOG=1^>^> %BKUP_LOG_FILE% 2^>^&1
echo ===========================BACKUP START=========================== %TO_LOG%
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set mytime=%%a%%b)
echo %mydate%_%mytime% %TO_LOG%
echo updating git index, committing, and then pushing to remote %TO_LOG%
REM Caution: The --ignore-errors directive tells git to continue even if it can't access a file.
git %GIT_PARAMS% add -Av --ignore-errors %TO_LOG%
git %GIT_PARAMS% commit -m "backup" %TO_LOG%
git %GIT_PARAMS% push -vv --progress origin master %TO_LOG%
echo ===========================BACKUP END=========================== %TO_LOG%

Nous avons le fichier exclude-from.txt, où nous mettons tous les fichiers à ignorer:

exclude-from.txt:

target/
logs/
AppData/
Downloads/
trash/
temp/
.idea/
.m2/
.IntelliJIdea14/
OLD/
Searches/
Videos/
NTUSER.DAT*
ntuser.dat*

Vous devrez aller dans un dépôt distant et faire un 'git init --bare' dessus. Vous pouvez tester le script en exécutant le script de sauvegarde. En supposant que tout fonctionne, accédez au planificateur Windows et pointez une sauvegarde toutes les heures vers le fichier vbs. Après cela, vous aurez un historique git de votre ordinateur pour chaque heure. C'est extrêmement pratique - chaque fois accidentellement supprimer une section de texte et le manquer? Il suffit de vérifier votre référentiel git.

utilisateur64141
la source
Juste curieux - cela fonctionnera-t-il également pour les lecteurs réseau lents ou non standard, comme ceux émulés par NetDrive ou Expandrive? Je trouve que la plupart des logiciels de sauvegarde échouent avec ces lecteurs réseau. De plus, les choses deviennent péniblement lentes et ont tendance à s’arrêter, si je veux lister tous les fichiers de la sauvegarde et extraire des fichiers individuels. Est-ce que git est capable de résoudre ces problèmes?
JustAMartin
@ JustAMartin Je ne l'ai jamais testé sur des lecteurs réseau, je ne peux donc pas le dire. Une fois que vous avez récupéré les fichiers dans un dépôt git, git est très efficace.
user64141
4

Ce n’est pas une mauvaise idée, mais je pense qu’il faut lever deux drapeaux rouges:

  • Si le disque dur échoue, vous perdrez tout si vous ne poussez pas votre validation sur un autre serveur / lecteur. (Événement si vous avez un plan pour cela, je préfère mentionner.)

... mais cela peut quand même être une bonne sauvegarde pour les problèmes liés à la corruption. Ou comme vous l'avez dit, si le dossier .git / est ailleurs.

  • Cette sauvegarde augmentera toujours en taille. Il n'y a pas d'élagage ou de rotation ou quoi que ce soit par défaut.

... Vous devrez donc peut-être demander à votre cronjob d'ajouter des balises, puis assurez-vous que les commits qui ne sont pas étiquetés seront nettoyés.

FMaz008
la source
Nous monterions probablement le répertoire .git sur un serveur distant, bien que le classique rm -Rf /soit source de problèmes. Notre système de sauvegarde actuel conserve les données pendant 2 ans ou 50 versions (selon la dernière éventualité), de sorte que notre sauvegarde augmente constamment. Mais j'aime bien l'idée d'ajouter des tags, nous pourrions avoir des tags "quotidien", "hebdomadaire", etc.
Smudge
+1 pour les besoins en espace sans cesse croissants
hafichuk
@sam git est en croissance constante. Vous ne pouvez pas élaguer l’histoire de plus de N ans. Je suppose que votre système actuel le fait.
RDS
1
En ce qui concerne l’augmentation de la taille, veuillez «git gc» régulièrement ou avant d’appliquer à un autre serveur (central). Sans cela, le dépôt git peut devenir beaucoup plus gros qu'il ne le devrait. Auparavant, j’avais un rapport de 346 Mo avec git pouvant se réduire à 16 Mo.
Hendy Irawan
3

Je ne l'ai pas essayé avec un système complet, mais je l'utilise pour mes sauvegardes MySQL (avec l'option --skip-extended-insert) et cela a vraiment bien fonctionné pour moi.

Vous allez rencontrer des problèmes avec les fichiers de données binaires (tout leur contenu peut et va changer) et vous pourriez avoir des problèmes avec le fait que le .gitdossier devienne vraiment volumineux. Je vous recommande de configurer un .gitignorefichier et de ne sauvegarder que les fichiers texte dont vous savez vraiment qu'il vous faut.

Scott Keck-Warren
la source
Je l'utilise aussi pour les sauvegardes MySQL, avec --extended-insert = false. Assurez-vous de "git gc" régulièrement ou juste après le commit.
Hendy Irawan
3

Une fois, j'ai développé une solution de sauvegarde basée sur la subversion. Même si cela a très bien fonctionné (et que ça devrait fonctionner encore mieux), je pense qu'il existe de meilleures solutions ici.

Je considère rsnapshot comme l’un des meilleurs, sinon le meilleur. Grâce à une bonne utilisation du lien physique, j’ai un serveur de fichiers de 300 Go (avec un demi-million de fichiers) avec une sauvegarde quotidienne, hebdomadaire et mensuelle pouvant aller jusqu’à un an. L'espace disque total utilisé ne représente qu'une copie complète + la partie incrémentielle de chaque sauvegarde, mais grâce aux liens physiques, j'ai une structure de répertoires "en direct" complète dans chacune des sauvegardes. En d'autres termes, les fichiers sont directement accessibles non seulement sous daily.0 (la sauvegarde la plus récente), mais même dans daily.1 (yestarday) ou hebdomadairement.2 (il y a deux semaines), etc.

En partageant le dossier de sauvegarde avec Samba, mes utilisateurs peuvent extraire le fichier des sauvegardes simplement en pointant leur PC vers le serveur de sauvegarde. Rdiff-backup

est une autre très bonne option , mais comme j'aime avoir des fichiers toujours accessibles en sélectionnant simplement l'explorateur sous \\ nom_serveur, rsnapshot était une meilleure solution pour moi.

Shodanshok
la source
La dernière version de rdiff-backup date de 2009. Est-il extrêmement bien conçu et ne nécessite aucune mise à jour ou s'agit-il simplement d'un projet abandonné?
Mateusz Konieczny
Je ne sais pas si c'est maintenu, mais c'est fondamentalement "fait".
Shodanshok
En regardant savannah.nongnu.org/bugs/…, il semble qu’il y ait eu une activité jusqu’en 2015, mais de nombreux rapports de bugs sont ignorés. Je pense que je vais le classer comme un abandonné.
Mateusz Konieczny le
2

J'ai eu la même idée de sauvegarder avec git, essentiellement parce que cela permet des sauvegardes versionnées. Ensuite, j'ai vu rdiff-backup , qui fournit cette fonctionnalité (et bien plus encore). Il a une très belle interface utilisateur (regardez les options de la CLI). Je suis assez content de ça. C'est --remove-older-than 2Wplutôt cool. Il vous permet simplement de supprimer les versions de plus de 2 semaines. rdiff-backupne stocke que les diffs de fichiers.

Daniel
la source
2

Je suis extrêmement nouveau pour git, mais les branches ne sont pas locales par défaut, et doivent être explicitement poussées vers des référentiels distants? Ce fut une surprise désagréable et inattendue. Après tout, est-ce que je ne veux pas que tous mes dépôts locaux soient «sauvegardés» sur le serveur? Lire le livre git :

Vos branches locales ne sont pas automatiquement synchronisées avec les télécommandes auxquelles vous écrivez. Vous devez explicitement pousser les branches que vous souhaitez partager. De cette manière, vous pouvez utiliser des branches privées pour un travail que vous ne souhaitez pas partager et ne faire remonter que les branches de sujet sur lesquelles vous souhaitez collaborer.

Pour moi, cela signifiait que ces branches locales, comme d'autres fichiers non-git sur ma machine locale, risquaient d'être perdues si elles n'étaient pas sauvegardées régulièrement par des moyens non-git. Je le fais quand même, mais cela a brisé mes hypothèses sur le fait de tout sauvegarder dans mon dépôt. J'aimerais des éclaircissements à ce sujet!

Matthew Cornell
la source
1
À peu près tout ce qui concerne git à l'exception des télécommandes est local. C'est par conception. Vous pouvez pousser des objets vers des télécommandes et vous devriez, surtout si vous utilisez cette sauvegarde comme dans ce scénario. Encore une fois, oui, pour les branches, vous devez les pousser explicitement si vous voulez les ajouter à une télécommande. Pour le développement, c’est très bien parce que vous voulez souvent tester quelque chose, mais il n’est pas nécessaire que cette branche de test soit préservée indéfiniment. Une fois que vous avez obtenu ce dont vous avez besoin, vous allez probablement le fusionner avec une branche dev et supprimer la branche test.
LocalPCGuy
1

J'ai trouvé que c'était une bonne méthodologie pour mes boites de développement. Cela les élimine de quelque chose qui doit être sauvegardé à un seul noeud final de déploiement.

Tous les manifestes d'installation et de configuration de la configuration sont stockés dans Puppet, ce qui facilite le redéploiement et les mises à jour de la configuration. Le répertoire Puppet est sauvegardé avec git. Kickstart est utilisé pour effectuer le déploiement initial.

Je conserve également un référentiel YUM personnalisé pour tous les packages en cours de développement. Cela présente l’avantage supplémentaire que les paquets avec lesquels nous travaillons ne sont pas simplement laissés sous la forme de fichiers binaires non surveillés sur le système local - si cela se produit et que les fichiers sont bien archivés. Quelqu'un n'a pas suivi la procédure appropriée.

Tim Brigham
la source
1

C'est une approche qui est utilisée, c'est logique.

Keepconf utilise rsync et git pour ce travail, c’est un wrapper sur cet outil pour garder la chose facile.

Vous avez seulement besoin d'un serveur central avec des clés ssh configurées pour accéder aux serveurs de sauvegarde et de quelques lignes dans le fichier de configuration. Par exemple, c’est mon propre fichier pour garder tous les fichiers / etc / et les paquets debian installés:

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

[files]
/etc/*
/var/lib/dpkg/status

Avec cela, j'ai la sauvegarde rsync et le commit git.

Rfraile
la source
0

Mon opinion personnelle est que tout cela est fondamentalement à l'envers. Vous introduisez les fichiers dans une solution de sauvegarde plutôt que de les extraire.

Il serait bien préférable de commencer par centraliser la configuration du serveur, puis de la baisser, en utilisant quelque chose comme une marionnette.

Cela dit, cela peut marcher, je ne pense tout simplement pas que ce serait si bon.

Essayez de regarder dans backuppc - il est assez facile à installer et est franchement brillant.

Sirex
la source
0

Cela fonctionnerait un peu, mais deux mises en garde.

  1. Les ajouts de fichiers ne seront pas automatiquement pris en compte lors de la validation. Utilisez --porcelean om git status pour rechercher de nouveaux éléments à ajouter avant d’effectuer le commit.

  2. Pourquoi le problème d'un montage distant pour le .ssh? S'il est fragile, vous ne saurez pas qu'il a échoué. Utilisez un référentiel nu pour l'extrémité distante avec une connexion par clé ssh normale. Tant que le référentiel est nu et que vous ne poussez que depuis une source, il est garanti que votre travail fonctionnera sans fusion.

Andrew
la source