GIT comme outil de sauvegarde

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?

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.

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

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.

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.

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.

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.

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.

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.

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.

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!

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.

Vous voudrez peut-être jeter un œil sur bup sur github, qui a été conçu pour servir l’utilisation de git pour la sauvegarde.

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.

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.

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.