GIT comme outil de sauvegarde
Sur un serveur, installez git
cd /
git init
git add .
git commit -a -m "Yes, this is server"
Obtenez alors /.git/ pour pointer vers un lecteur réseau (SAN, NFS, Samba) ou un disque différent. Utilisez une tâche cron toutes les heures/jour, etc. pour mettre à jour les modifications. Le répertoire .git contiendrait une copie versionnée de tous les fichiers du serveur (à l'exception de ceux inutiles/compliqués comme/proc,/dev etc.)
Pour un serveur de développement non important où je ne veux pas les tracas/le coût de son installation sur un système de sauvegarde approprié, et où les sauvegardes ne seraient que pour plus de commodité (IE, nous ne le faisons pas besoin pour sauvegarder ce serveur mais cela gagnerait du temps si les choses tournaient mal), cela pourrait-il être une solution de sauvegarde valide ou tombera-t-il simplement dans un gros tas de caca?
Vous n'êtes pas stupide. L'utilisation de git comme mécanisme de sauvegarde peut être intéressante, et malgré ce que d'autres ont dit, git fonctionne très bien avec les fichiers binaires. Lisez cette page du Git Book pour plus d'informations sur ce sujet. Fondamentalement, puisque git n'utilise pas de mécanisme de stockage delta, il ne se soucie pas vraiment de l'apparence de vos fichiers (mais l'utilitaire de git diff est assez faible pour les fichiers binaires avec une configuration de base).
Le plus gros problème avec l'utilisation de git pour la sauvegarde est qu'elle ne conserve pas la plupart des métadonnées du système de fichiers. Plus précisément, git n'enregistre pas:
- groupes de fichiers
- propriétaires de fichiers
- autorisations de fichier (autre que "est-ce 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 difficile de bien faire les choses.
Une recherche Google pour métadonnées de sauvegarde git donne un certain nombre de résultats qui semblent valoir la peine d'être lus (y compris certains outils qui tentent déjà de compenser les problèmes que j'ai soulevés ici).
etckeeper a été développé pour sauvegarder /etc et résout bon nombre de ces problèmes.
Je ne l'ai pas utilisé, mais vous pourriez regarder bup qui est 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 le .git autorisations de répertoire, sinon pousser /etc/shadow peut être lisible dans le .git répertoire.
Bien que techniquement, vous puissiez le faire, je mettrais deux mises en garde:
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 n'avez pas de processus (documenté ou automatisé) pour construire une nouvelle machine. Et si vous vous faisiez acheter un bus, qui saurait quoi faire et ce qui était important?
La récupération après sinistre est importante, mais il est préférable d'automatiser (script) la configuration d'une nouvelle boîte de développement plutôt que de tout sauvegarder. Bien sûr, utilisez git pour votre script/documentation mais pas pour chaque fichier 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. L'utilisation de git comme sauvegarde pour n'importe quel système offre 2 grands avantages:
- 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 un contrôle total sur 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. Vous voulez effacer quelque chose de votre histoire? Aucun problème. Récupérer une version de votre fichier est aussi simple que n'importe quelle commande git.
- Autant de miroirs que vous le souhaitez, et tous peuvent avoir des durées de sauvegarde personnalisées. Vous obtiendrez votre miroir local, qui n'est pas surchargé par un trafic Internet lent, et vous donne ainsi (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 énorme avantage, car je constate que la plupart du 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 à distance, qui offre l'avantage de la protection des données en cas de sinistre local ou de vol. Et supposez que vous vouliez que votre miroir distant soit sauvegardé à un moment personnalisé pour économiser votre bande passante Internet? Aucun problème.
Bottom line: Une sauvegarde git vous donne des quantités incroyables de pouvoir sur le contrôle de la façon dont vos sauvegardes se produisent.
J'ai configuré cela 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 (mais on s'attend à ce que vous poussiez cela quelque part à distance, sinon vous serez vissé si le disque dur meurt.)
Vous devrez d'abord installer cygwin (avec rsync), et également installer git pour Windows: http://git-scm.com/download/win
Ensuite, créez votre dépôt git local (exécuté 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 Windows Scheduler:
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 sur n'importe quel 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 à Windows Scheduler 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 élément supprime accidentellement une section de texte et la manque? Vérifiez simplement votre dépôt git.
Ce n'est pas une mauvaise idée, mais je pense qu'il y a 2 drapeaux rouges à soulever:
- 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 le mentionner.)
... mais quand même, cela peut être une bonne sauvegarde pour les choses liées à 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 dire à votre cronjob d'ajouter des balises, puis assurez-vous que les validations qui ne sont pas balisées seront nettoyées.
J'ai une fois développé une solution de sauvegarde basée sur Subversion. Bien que cela ait très bien fonctionné (et que git 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. Avec une bonne utilisation du lien dur, j'ai un serveur de fichiers de 300 Go (avec un demi-million de fichiers) avec une sauvegarde quotidienne, hebdomadaire et mensuelle remontant à un an. L'espace disque total utilisé est seulement une copie complète + la partie incrémentielle de chaque sauvegarde, mais grâce aux liens physiques j'ai une structure de répertoire complète "live" dans chaque des sauvegardes. Dans d'autres Word, les fichiers sont directement accessibles non seulement sous daily.0 (la sauvegarde la plus récente), mais même dans daily.1 (yestarday) ou hebdomadaire.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.
Une autre très bonne option est rdiff-backup, mais comme j'aime avoir des fichiers toujours accessibles simplement en allant de l'explorateur à \\ nom_serveur, rsnapshot était une meilleure solution pour moi.
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 (leur contenu entier pourrait et va changer) et vous pourriez avoir des problèmes avec le .git le dossier devient vraiment volumineux. Je recommanderais de configurer un .gitignore fichier et en sauvegardant uniquement les fichiers texte dont vous avez vraiment besoin.
J'ai eu la même idée de sauvegarder avec git, essentiellement parce qu'il permet des sauvegardes versionnées. Ensuite, j'ai vu rdiff-backup , qui fournit cette fonctionnalité (et bien plus). Il a une interface utilisateur vraiment sympa (regardez les options CLI). J'en suis assez content. Le --remove-older-than 2W est plutôt cool. Il vous permet de supprimer simplement les versions antérieures à 2 semaines. rdiff-backup stocke uniquement les différences de fichiers.
Je suis extrêmement nouveau sur git, mais les branches ne sont-elles pas locales par défaut et doivent-elles être poussées explicitement vers des référentiels distants? Ce fut une surprise désagréable et inattendue. Après tout, ne veux-je pas que tous mon référentiel local soient "sauvegardés" sur le serveur? Lire le git book :
Vos succursales locales ne sont pas automatiquement synchronisées avec les télécommandes que vous écrivez - vous devez explicitement pousser les branches que vous souhaitez partager. De cette façon, vous pouvez utiliser des branches privées pour le travail que vous ne souhaitez pas partager et afficher uniquement les branches de sujet sur lesquelles vous souhaitez collaborer.
Pour moi, cela signifiait que ces branches locales, comme les autres fichiers non-git sur ma machine locale, risquaient d'être perdues à moins d'être sauvegardées régulièrement par des moyens non-git. Je le fais de toute façon, mais cela a brisé mes hypothèses sur git `` sauvegarder tout '' dans mon référentiel. J'adorerais avoir des éclaircissements à ce sujet!
C'est une approche qui est utilisée, elle a du sens.
Keepconf utilisez rsync et git pour ce travail, c'est un wrapper sur ces outils pour garder la chose facile.
Vous n'avez besoin que d'un serveur central avec des clés ssh configurées pour l'accès aux serveurs de sauvegarde et 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 git commit.
Vous voudrez peut-être vérifier bup sur github qui a été conçu pour servir à utiliser git pour la sauvegarde.
J'ai trouvé que c'était une bonne méthodologie pour mes boîtes de développement. Cela les fait passer de quelque chose qui ne doit être sauvegardé qu'à un point de terminaison de déploiement.
Tous les manifestes de configuration et d'installation de packages sont stockés dans Puppet, permettant un redéploiement et des mises à jour de configuration faciles. Le répertoire Puppet est sauvegardé avec git. Kickstart est utilisé pour effectuer le déploiement initial.
Je garde également un référentiel YUM personnalisé pour tous les packages en cours de développement. Cela a l'avantage supplémentaire que les packages avec lesquels nous travaillons ne sont pas simplement laissés en tant que binaires sans surveillance sur le système local - si cela se produit et que les fichiers sont bien détruits. Quelqu'un n'a pas suivi la procédure appropriée.
Cela fonctionnerait quelque peu, mais deux mises en garde.
Les ajouts de fichiers ne seront pas récupérés automatiquement lorsque vous effectuez la validation. Utilisez --porcelean om git status pour trouver de nouvelles choses à ajouter avant de faire la validation.
Pourquoi les tracas d'un montage à distance pour le .ssh? Il pourrait être fragile Bd vous ne saurez pas qu'il a échoué. Utilisez un référentiel nu pour l'extrémité distante avec une connexion de clé ssh normale. Tant que le référentiel est vide et que vous ne poussez qu'à partir d'une seule source, il est garanti de fonctionner sans fusion.
Mon opinion personnelle est que c'est essentiellement à l'envers. Vous placez les fichiers dans une solution de sauvegarde, plutôt que de les retirer.
Beaucoup mieux serait de centraliser la configuration du serveur en premier lieu, puis de le tirer vers le bas, en utilisant quelque chose comme une marionnette.
Cela dit, cela peut fonctionner, je ne pense pas que ce serait si bon.
Essayez de regarder dans backuppc - c'est assez facile à installer et franchement génial.