Efficiënt een sparse img vanaf NFS share naar LV kopiëren

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • JJerome
  • Registratie: Oktober 2007
  • Laatst online: 27-07 15:33
Op dit moment maak ik gebruik van LVM volumes als devices voor KVM machines. Een backup maken van
een volledige machine is in dit geval een kwestie van het maken van een LVM snapshot, en deze via dd & cp als sparse image wegschrijven op een NFS share. Als volgt:

dd if=/dev/volumegroup/volume-snapshot | cp --sparse=always /dev/stdin /mnt/backup/backup.img

Dit heeft als voordeel dat alleen de daadwerkelijke data naar de share worden weggeschreven. Een volume van 25GB die maar 5GB in gebruik heeft kost maar een fractie van de tijd over het netwerk.

Restoren daarentegen duurt altijd veel langer. De volledige 25GB moet dan over het netwerk (zo lijkt het).
Het proces omdraaien heeft niet het gewenste resultaat, wat vast logisch is.

Is voor het ophalen ook een efficiënte manier, er van uitgaande dat het netwerk mijn bottleneck is?

Acties:
  • 0 Henk 'm!

  • H!GHGuY
  • Registratie: December 2002
  • Niet online

H!GHGuY

Try and take over the world...

NFS heeft blijkbaar nog geen support voor sparse files. Er was aan GSOC 2012 project om dit toe te voegen, maar ik zie niet direct of dit project succes had of niet.

Ik vermoed dat je zal moeten kijken om effectief minder data naar je NFS share weg te schrijven. Je kan kijken naar compressie; lzo is bvb een redelijke kandidaat aangezien het weinig CPU verbruikt.
Wil je er wat meer CPU tegenaangooien kun je ook nog naar gzip, bzip2 of zelfs xz kijken.

ASSUME makes an ASS out of U and ME


Acties:
  • 0 Henk 'm!

  • JJerome
  • Registratie: Oktober 2007
  • Laatst online: 27-07 15:33
Dat het wat meer CPU kracht kost is niet zo'n probleem. Ik zal eens testen wat er van de grootte overblijft na gzip. Uiteindelijk zullen veel volumes toch wel voor 75% van hun grootte gevuld worden, waardoor compressie sowieso wenselijk is.

[ Voor 4% gewijzigd door JJerome op 18-06-2013 13:45 ]


Acties:
  • 0 Henk 'm!

  • Rainmaker
  • Registratie: Augustus 2000
  • Laatst online: 14-07-2024

Rainmaker

RHCDS

Misschien kun je iets winnen door het met LessFS inline te DDUPpen, en dan deze database overzetten naar de andere machine?

Hangt een beetje af van het type data op je systeem.

We are pentium of borg. Division is futile. You will be approximated.


Acties:
  • 0 Henk 'm!

  • Hero of Time
  • Registratie: Oktober 2004
  • Laatst online: 22:26

Hero of Time

Moderator LNX

There is only one Legend

Kan je daar een image mee maken voor volledige herstel dan? Want dat is de hele gedachte hierachter.

Commandline FTW | Tweakt met mate


Acties:
  • 0 Henk 'm!

  • JJerome
  • Registratie: Oktober 2007
  • Laatst online: 27-07 15:33
Hero of Time schreef op dinsdag 18 juni 2013 @ 17:09:
Kan je daar een image mee maken voor volledige herstel dan? Want dat is de hele gedachte hierachter.
Het eindresultaat moet inderdaad aan beide kanten een raw image zijn.
H!GHGuY schreef op dinsdag 18 juni 2013 @ 12:36:
NFS heeft blijkbaar nog geen support voor sparse files. Er was aan GSOC 2012 project om dit toe te voegen, maar ik zie niet direct of dit project succes had of niet.
[...]
Overigens is het wegschrijven van een sparse image naar een NFS share dus geen enkel probleem, dat resultaat is prima. Ik probeer alleen te bedenken hoe ik deze data ook op dezelfde manier op kan halen.
Vanaf de backupserver het juist terugsturen naar de hypervisor zou moeten kunnen werken, maar lijkt mij een kromme methode. Ik wil ook in één keer de image weer in LVM zetten (Bijv: dd if=/mnt/backup/backup.img of=/dev/volumegroup/volume). Er is niet per definitie ruimte om de image eerst op te slaan.

Edit: gzip geeft me uiteindelijk een redelijk resultaat. Bestandsgrootte t.o.v. sparse file ongeveer gehalveerd. Backup duur is met +/- 50% toegenomen (zal een iets groter verschil worden zodra er een snellere netwerkverbinding tussen zit). Restoren is nu wel acceptabeler geworden (van +/- 40 minuten naar 8 minuten).

[ Voor 12% gewijzigd door JJerome op 18-06-2013 22:59 ]

Pagina: 1