Achja, dat zijn van die dingen waar je eindeloos overheen kunt kijken
Overigens heb ik de benodigde rsync opties op een andere manier uitgevonden: ik heb in authorized_keys het commando vastgezet op een shell-scriptje met de volgende inhoud:
#! /bin/sh
echo "$SSH_ORIGINAL_COMMAND" >> /tmp/ssh-command.log
Het gevolg is dat ssh het gevraagde commando niet uitvoert maar logt. Als je dan dus je rsync client uitvoert (als echte run, niet dry-run) dan krijg je in het log precies te zien wat rsync had willen uitvoeren.
Jouw methode werkt natuurlijk ook, mits je er aan denkt om de -n weg te halen
Overigens, de --sender optie is slecht gedocumenteerd, maar die dient er volgensmij voor om rsync te beperken tot het verzenden van bestanden, wat in het geval van pull-backups de veiligheid zou verhogen.
Ja maar, stel je hebt op de webserver dus gebruikers pietje en jantje. Beide hebben een directory in /home/pietje en /home/jantje.
Hoe maak ik dan een user aan op de webserver die om beide directorys mag lezen en niet mag schrijven? Of nog beter, hoe maak ik een user aan die alleen in /home mag lezen? Want dan kan ik het hele verhaal natuurlijk omdraaien, wat in mijn ogen toch veiliger is en overzichtelijker.
Wat voor gebruiker wordt dat dan? Of moet ik gewoon de root in de authorized_keys file zetten. Is dat wel verstandig? Kun je mij een goede hint of tip geven?
Of moet ik voor iedere gebruiker een authorized_keys file aanmaken? Stel als die server straks 1001 gebruikers heeft, moet ik ze allemaal handmatig bij langs. Daarom backup ik liever gewoon in een keer de /home directory.
Laat ik even beginnen te zeggen dat ik niet vind dat je per se vanaf de backupserver hoeft te backuppen. Ik was het niet zozeer oneens met backuppen vanaf de webserver, maar meer met de notie dat backuppen vanaf de backupserver altijd fout is. Beide zijn valide manieren, en welke het beste is is afhankelijk van allerlei afwegingen
Ikzelf gebruik rsync om full-system backups te maken, dat betekent dat elke file op mijn productieserver ook op de backupserver aanwezig is. Inclusief files als /etc/passwd, /etc/shadow, de ssh private host key, ssh public client keys, SSL private keys, en weet ik wat nog meer. Dat geeft een aanvaller zo verschrikkelijk veel ammunitie dat als ze op mijn backupserver inbreken mijn productieserver een peuleschil moet zijn. Andersom is een ander verhaal.
Bovendien draait mijn productieserver veel services en mijn backupserver juist heel minimaal, en omdat ik op mijn backupserver zelden inlog kan ik daar verregaandere veiligheidsmaatregelen nemen zonder mezelf te irriteren. Dat alles maakt dat het risico op inbraak op mijn backupserver lager is en dat ik het dus prettiger vind om vanaf mijn backupserver op mijn productieserver in te loggen dan andersom.
Maar voor jouw situatie ligt dat misschien anders. Geen full-system backups maakt het al anders bijvoorbeeld
Voor jouw wensen zijn er verschillende opties, elk met hun eigen voor- en nadelen:
Backups maken als root. Één rsync-actie, leesrechten op alle bestanden. Maar als iemand het voor elkaar krijgt in te loggen op je ssh (door je private key te bemachtigen, door een bug in ssh, etc), en het vaststaande commando voor rsync toch weet te misbruiken, dan heb je een aanzienlijk groter probleem.
Een backup-user aanmaken, die lid maken van de groepen van al je gebruiker in /home, en zorgen dat alle files en directories in /home group-readable zijn (bv dmv een cronjob). Één rsync-actie, en minimale rechten. Alleen het stukje van files group-readable houden is een beetje bewerkelijk.
Per user backuppen. Op zich geen gekke optie; backup kan voor elke user overal bij waar hij bij moet kunnen. Het grootste nadeel is dat het iets meer configuratie is (authorized_keys voor elke user, en elke user instellen op de backupserver). Maar dat is op zich ook af te vangen, de authorized_keys kun je eventueel opnemen in /etc/skel/, en op de backupserver zou je het met één cronjob aan kunnen pakken door een stukje te automatiseren met zoiets:
#! /bin/sh
for USER in jantje pietje klaasje
do
rsync -blabla "${USER}@webserver:" bla
tar -bla bla
rm -r bla
done
Backups van de webserver naar de backupserver pushen is natuurlijk ook nog steeds een optie. Cronjob per user. Public key per gebruiker in de authorized_keys op de backupserver. Maar deze optie is wel lastiger als je processing wil doen na een backup (zoals tarren).
Opties te over
Hero of Time schreef op woensdag 12 februari 2014 @ 08:30:
Als je zonodig alles in een backup archief wilt hebben op een centrale plek, kijk dan naar echte backup software, zoals Bacula. Nu zit je met half gare oplossingen te werken die meer bedoelt zijn voor het in sync houden van systemen, niet om verschillende locaties naar een centrale plek te consolideren als backup.
Ik denk dat rsync wel zo'n beetje het meestgebruikte stuk gereedschap is voor backups eigenlijk
Maar je hebt wel een punt; zelf wat in elkaar zetten brengt in plaats van bestaande en geteste backup-software gebruiken brengt risico's met zich mee. Hoe gaat een zelfbouw-oplossing om met bv een volle doel-schijf?
Er zijn best wel relatief simpele pakketten op basis van rsync te vinden (rsnapshot is eentje die me zo te binnen schiet), het is misschien ook wel een goed idee om daar naar te kijken
:strip_icc():strip_exif()/u/55227/crop6245f0ff038e2_cropped.jpg?f=community)
/u/26742/000000751.png?f=community)
Ik kan niet anders zeggen dat het nu werkt!/u/125506/link-8bit.png?f=community)