PBS-migratie – valse start

by wbk | 16 juni 2025 13:17

Update: onderstaand stappenplan is de prullenbak ingegaan nadat ik van RAID0 naar RAID5 ging, ipv RAID10. Herzien: rechtstreeks naar RAID10[1] met een kleine hardware-aanpassing.

Oude situatie: 1x 4TB in gebruik + 3x 4TB ongebruikt
Nieuwe situatie: RAID10 over 4x 4TB + LVM caching over 4x 0,2TB SSD

Stappen:

• HDD’s identificeren en overbrengen naar nieuwe behuizing
• LVM RAID0 over 2x 4TB, caching toevoegen
• 8TB RAID0 LVM toevoegen aan PBS
• PBS sync van ZFS op 1x 4TB naar 8TB RAID0 LVM
• Mirror toevoegen aan beide schijven, van 2x 4TB naar 4x 4TB

Praktische uitvoering:

• 1x 4TB SAS blijkt defect, voorlopig vervangen met beschikbare 3TB of 6TB SATA schijf
• LVM voorbereiden:
  • fdisk /dev/sde
    • g – nieuw GPT disklabel
    • n – nieuwe partitie (partitie 1, vanaf default sector 2048 tot default laatste sector, en dan van de laatste sector een stukje afhalen om ~1% vrije ruimte over te laten)
    • t – type: lvm
    • p – print indeling ter controle
    • w – schrijf de indeling naar schijf
  • pvcreate /dev/sde1 /dev/sdf1
  • vgcreate backup /dev/sde1 /dev/sdf1
  • Striped LV over de twee HDD’s, stripesize van 1 MB
    • Niet de volle 100% vrije ruimte gebruiken om toekomstige mutaties niet te blokkeren (Volume group "backup" has insufficient free space (0 extents): 8 required
    • lvcreate -n localbaks -vt -i2 -l95%VG backup -I 1M /dev/sdf1 /dev/sde1
  • Tijdelijk de huidig beschikbare SSD toevoegen als dmcache
    • vgextend backup /dev/sda1
  • Cachevol maken en toevoegen aan de striped LV; gebruik niet %VG, dat gaat over de volledige VG, niet over de aangewezen PV
    • lvcreate -vt -n localbaks_cache -L 70G backup /dev/sda1
    • lvconvert --type cache --cachepool localbaks_cache backup/localbaks
  • Is het nodig om cache te verwijderen?
    • lvconvert --uncache backup/localbaks
• Het gecreerde volume toevoegen aan PBS; omdat het geen raw disk device is, kunnen we niet het disk subcommand van proxmox-backup-manager gebruiken. Daarom handmatig een bestandssysteem aanmaken, mounten en vervolgens een datastore maken:
  • mkfs.ext4 /dev/mapper/backup-localbaks
  • mkdir -p /mnt/datastore/localbaks
  • echo '/dev/mapper/backup-localbaks /mnt/datastore/localbaks ext4 defaults 0 0' >> /etc/fstab
  • proxmox-backup-manager datastore create localbaks /mnt/datastore/localbaks

Vervolgstappen

sync-job: ingericht via de web-GUI:

• Gecreëerd vanuit de nieuwe ‘localbaks’ datastore, als ‘sync pull job’
• ‘remote’ uitgevinkt, locale oude datastore als bron aangewezen
• volledige namespace
• jaarlijks (want eenmalig) gepland
• vervolgens met ‘run now’ handmatig gestart

De actie trekt volgens de ‘administration’ sectie van PBS zo’n 100% CPU met IO wait op 80% en 6 van 16 GB geheugen bezet; htop geeft 10-15% belasting op elk van de 4 cores bij een bescheiden geheugengebruik van <700 MB

Transfersnelheid zit op zon 80 MB/s via PBS en 100 MiB/s via htop wat redelijk bij elkaar in de buurt komt.

Er is wel een groot verschil in het aantal IOPS op de oude disk tegenover de nieuwe gecachte RAID0: volgens PBS ongeveer 20 IOPS op de oude schijf, tegelijkertijd zo’n 700 IOPS op de nieuwe schijf. Zelfs als de oude schijf 4k sectors zou hebben en de nieuwe 512b, is dat verschil niet te verklaren.

De verhouding tussen bandbreedte en IOPS op de nieuwe RAID0 is 1 MB/s voor elke 10 IOPS, dus 100 kB per I/O. Later nog eens naar kijken, wordt vervolgd.

Todo’s

• RAID0 –> RAID10
• 1x 80 GB SSD vervangen door deel van 4x 200 GB SSD
• 1x 100 GB system SSD vervangen door deel van 4x 200 GB SSD

Source URL: https://blog.osba.nl/2025/06/16/pbs-migratie/

---