[pablofreirechavez]

hola que tal tengo este problema con el Servidor Proxmox

cuando hago el respaldo es todo normal y cuando quiero subir el respaldo me sale este error

restore vma archive: lzop -d -c /var/lib/vz/dump/dump/vzdump-qemu-AVL-105-2015_10_13-09_44_25.vma.lzo|vma extract -v -r /var/tmp/vzdumptmp698444.fifo - /var/tmp/vzdumptmp698444

TASK ERROR: command 'lzop -d -c /var/lib/vz/dump/dump/vzdump-qemu-AVL-105-2015_10_13-09_44_25.vma.lzo|vma extract -v -r /var/tmp/vzdumptmp698444.fifo - /var/tmp/vzdumptmp698444' failed: got timeout

verifique disco pero si hay espacio
trate crear el backup sin comprimir y tengo el mismo error

cabe indicar que tengo este problemas con los backup de ese servidor pero si hago los mismo backup en otro servidor y los traslado a la vez a otro server
no hay problema.

asumo que es el servidor principal que tiene problemas de backup

alguna ayuda ¡¡¡¡ necesito sacar esas maquinas virtuales para ponerlas en otro equipo servidor ya que es mucho tiempo volverla a crear desde cero son 5 virtuales en total...

[deackgler]

Buenas, soy nuevo en proxmox tengo un Servidor de 48gb de ram, con 3 discos de 1TB, lo que me sucedio fuelo siguiente teniendo solo 1 TB en disco solo 1 disco tenia mi instalacion de proxmox con 14 VM corriendo la cual al introducir el segundo disco de 1TB procedi codeando para expandir el /var/lib/vz lo cual dañe la particion donde se encontraba mi sistema y tuve que hacer reinstalacion en otro disco de 1tb y dejando la infor intacta en el otro disco la cual quiero salvar todos los VM o discos qcow2 de cada VM porque tengo datos muy importantes de mi vida hay como puedo hacer para obtenerlos y pasarlos a una carpeta en /mnt/backups ? el que me ayude le dare un millon de gracias.

[CoPeRniX]

Buenas compañero,

Ando varios días peleado con vzdump para backup, te explico:

Quiero realizar un backup de un CT que ocupa unos 50GB aproximadamente. En su día, en la instalación de proxmox asigne a la unidad / 50GB de espacio. Mi intenció es lanzar vzdump a una unidad montada de hubic o alguna unidad NFS, pero veo que al realizar snapshot este me usa la partición / por lo que me quedo sin espacio y fallo el backup....

A ver si puedes orientarme un poco.

Gracias,
Saludos.

[kkenshinn]

Buenas de nuevo, seguiré publicando las novedades al respecto para que si alguien tiene algún problema similar, tenga una referencia de cómo proceder, aunque cada caso hay que analizarlo individualmente.

Os comento, hoy como dije ayer iba a probar a realizar el snapshot sin compresión sobre una unidad de red NFS, esta mañana a primera hora he tenido que matar al demonio "maldet" (antivirus malware) que se ejecuta en torno a las 7:30, ya que la búsqueda de los ficheros modificados hace 2 días, me estaba aumentando el I/O excesivamente, y comprometía la estabilidad y el snapshot.

De modo que al poco tiempo de hacer esta labor y con casi un 80% llena la unidad temporal para el snapshot (119 GB), ha finalizado el mismo sin errores. Curiosamente... ocupa menos espacio el snapshot sin comprimir que el comprimido:

-rw-r--r-- 1 root root 159194913814 jul 20 08:54 vzdump-openvz-103-2015_07_20-00_30_06.tar.lzo
-rw-r--r-- 1 root root 104672450560 jul 24 08:13 vzdump-openvz-103-2015_07_24-00_30_07.tar

Aunque añadí en "vzdump.conf" la variable:

exclude-path: '/var/lib/psa/dumps/.+'

Para hacer que no se copiaran los backups del Plesk del container, que ya se transfieren por rsync, y hacer que tarde presumiblemente menos tiempo. Estoy restaurando la máquina en el servidor de backup (nfs) para testeat esto, y que todo lo demás se ha copiado corréctamente (entiendo que sí).

Os mantendré informados, en cualquier caso si alguien tiene alguna sugerencia que nos la diga y nos ayudamos entre todos :-)

Editado:
Pues efectivamente... las copias de seguridad del Plesk no se han copiado en el snapshot:

root@backup-01:/var/lib/vz/root/103/var/lib/psa# du -sh dumps/
4,0K    dumps/

Adjunto reporte del log del snapshot:

INFO: Starting Backup of VM 103 (openvz)
INFO: CTID 103 exist mounted running
INFO: status = running
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating lvm snapshot of /dev/mapper/pve-vz ('/dev/pve/vzsnap-ns366256-0')
INFO: Logical volume "vzsnap-ns366256-0" created
INFO: creating archive '/mnt/pve/nfs_daily/dump/vzdump-openvz-103-2015_07_24-00_30_07.tar'
INFO: Total bytes written: 104672450560 (98GiB, 3.6MiB/s)
INFO: archive file size: 97.48GB
INFO: Finished Backup of VM 103 (07:43:38)
INFO: Backup job finished successfully
TASK OK

Un saludo.

[kkenshinn]

Buenas de nuevo os comento las buenas nuevas, hoy he analizado en tiempo real el estado del backup de proxmox con lzop para ver el consumo de espacio de la unidad temporal.

### lvs
  vz                pve  owi-aos-- 866,00g
  vzsnap-ns366256-0 pve  swi-aos-- 119,00g      vz      88,11

Por lo que la copia de seguridad no se iba a completar llevaba ya consumida un 88,11% de los 119 GB de espacio libre destinados a la misma, y sólo se había realizado la copia por NFS de:

### ls -l
-rw-r--r-- 1 root root  55177768960 jul 23 07:41 vzdump-openvz-102-2015_07_23-00_30_12.tar.dat
drwxr-xr-x 2 root root         4096 jul 23 00:30 vzdump-openvz-102-2015_07_23-00_30_12.tmp

Cuando la copia final con lzop pesará finalmente cerca de los 150 GB.

Por otro lado hoy el I/O se ha incrementado (cerca del 50-60%), comprometiendo el rendimiento de los containers única y exclusivamente por crear el snapshot, ya sé que se puede establecer en "vzdump.conf" el "bwlimit" y el "ionice" para establecer rendimiento vs tiempo, pero no he conseguido en esta máquina establecer unos valores aptos.

De este modo he cancelado el snapshot, volviendo el I/O a valores que rondan el 10-20% entre los 2 containers comentados. Mañana procederé a realizar el snapshot sin compresión, para probar el resultado del mismo, pero... ¿se os ocurre alguna idea adicional?

Un saludo!

[kkenshinn]

Buenas a todos tengo un problema al realizar los snapshots en uno de los servidores dedicados con Proxmox que administro desde hace una semana, esta máquina tiene alojados 2 containers Centos 6 + Plesk 12 con 200 y 100 suscripciones respectivamente cada una, por lo que tienen alojados muchos pequeños ficheros.

El peso de cada backup de cada container con LZOP, actualmente debe rondar los 148 GB y 137 GB, tardando en finalizarse unas 6-7 horas. Dado el problema reportado, el típico "Read error at byte 0, while reading 4608 bytes: Input/output error" cambié la configuración para usar una carpeta NFS de un servidor de backups, y el primer día esta configuración funcionó bien, aunque tardando unas 9 horas.

Esta máquina cuenta con 32 GB de RAM y 2 HDD HARD RAID 1 con EXT4

Adjunto copia de mi configuración y logs:

### vzdump.conf
size: 121856

### pveversion -v
proxmox-ve-2.6.32: 3.4-157 (running kernel: 2.6.32-37-pve)
pve-manager: 3.4-6 (running version: 3.4-6/102d4547)
pve-kernel-2.6.32-32-pve: 2.6.32-136
pve-kernel-2.6.32-39-pve: 2.6.32-157
pve-kernel-2.6.32-37-pve: 2.6.32-150
pve-kernel-2.6.32-34-pve: 2.6.32-140
pve-kernel-2.6.32-38-pve: 2.6.32-155
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.7-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.10-2
pve-cluster: 3.0-18
qemu-server: 3.4-6
pve-firmware: 1.1-4
libpve-common-perl: 3.0-24
libpve-access-control: 3.0-16
libpve-storage-perl: 3.0-33
pve-libspice-server1: 0.12.4-3
vncterm: 1.1-8
vzctl: 4.0-1pve6
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 2.2-10
ksm-control-daemon: 1.1-1
glusterfs-client: 3.5.2-1

### /var/log/syslog
Jul 22 07:17:32 ns366256 kernel: device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception.
Jul 22 07:17:33 ns366256 kernel: EXT4-fs error (device dm-0): ext4_find_entry: reading directory #26870325 offset 0
Jul 22 07:17:33 ns366256 kernel: __ratelimit: 138 callbacks suppressed
Jul 22 07:17:33 ns366256 kernel: Buffer I/O error on device dm-0, logical block 0
Jul 22 07:17:33 ns366256 kernel: lost page write due to I/O error on dm-0
Jul 22 07:17:33 ns366256 kernel: EXT4-fs error (device dm-0): ext4_find_entry: reading directory #26870325 offset 0
Jul 22 07:17:33 ns366256 kernel: EXT4-fs (dm-0): previous I/O error to superblock detected
Jul 22 07:17:33 ns366256 kernel: Buffer I/O error on device dm-0, logical block 0
Jul 22 07:17:33 ns366256 kernel: lost page write due to I/O error on dm-0
Jul 22 07:17:34 ns366256 kernel: EXT4-fs error (device dm-0): ext4_find_entry: reading directory #26870325 offset 0
Jul 22 07:17:34 ns366256 kernel: EXT4-fs (dm-0): previous I/O error to superblock detected
Jul 22 07:17:34 ns366256 kernel: Buffer I/O error on device dm-0, logical block 0
Jul 22 07:17:34 ns366256 kernel: lost page write due to I/O error on dm-0

### Backup Error Proxmox
INFO: Total bytes written: 82024960000 (77GiB, 3.3MiB/s)
INFO: tar: Exiting with failure status due to previous errors
ERROR: Backup of VM 103 failed - command '(cd /mnt/vzsnap0/private/103;find . '(' -regex '^\.$' ')' -o '(' -type 's' -prune ')' -o '(' -regex './var/lib/psa/dumps/.+' -prune ')' -o '(' -regex './var/lib/psa/dumps/.+' -prune ')' -o -print0|sed 's/\\/\\\\/g'|tar cpf - --totals --sparse --numeric-owner --no-recursion --one-file-system --null -T -|lzop) >/mnt/pve/nfs_daily/dump/vzdump-openvz-103-2015_07_22-00_30_07.tar.dat' failed: exit code 2
INFO: Backup job finished with errors
postdrop: warning: uid=0: File too large

### Scheduler sda y sdb
Deadline

### Pveperf
CPU BOGOMIPS:      56035.36
REGEX/SECOND:      1535793
HD SIZE:           9.49 GB (/dev/md2)
BUFFERED READS:    14.61 MB/sec
AVERAGE SEEK TIME: 226.70 ms
FSYNCS/SECOND:     2.65
DNS EXT:           40.46 ms
DNS INT:           5.29 ms

### dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
402653184 bytes (403 MB) copiados, 3,48669 s, 115 MB/s

### vgdisplay
  VG Name               pve
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  958
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               985,24 GiB
  PE Size               4,00 MiB
  Total PE              252222
  Alloc PE / Size       221695 / 866,00 GiB
  Free  PE / Size       30527 / 119,25 GiB

Adicionalmente mientras se realiza el backup, se realiza una sincronización mediante rsync y otra con lftp a distintos servidores de backups, para copiar webs, correos y bases de datos de forma incremental; pero como digo quiero poder realizar el snapshot completo.

Un saludo y gracias de antemano.