<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Dear,<br>
<br>
3 years ago I have written scripts to make the backup fast and I
have reduced the load and cpu for<br>
a better backup to an other server. Now I have test again, how we
can use the proxmox backup,<br>
but for containers it´s absolute to slow, need to much cpu and make
an overhead of load a long time.<br>
So one container with 70 GB needs 5 hours. Thats not usable!<br>
<br>
So, small things to change the backup strategy works by us with own
scripts now to NFS very fast!<br>
<br>
a) create rsync to a separate folder on same drive. In this folder
hold the copy of the rsync and dont<br>
delete them after the backup, so next day when the backups runs
again, the rsync is much faster<br>
and need 10 % of the time as when they must create a complete new
copy. About this the files<br>
synchronised exactly the same, delete the entries, they equal
deleted on the source. <br>
OK, yes thats need for containers they will backed up the double
space! This must been a feature<br>
in the setting in the config-File, so admin can set tempfolder
and a flag for hold the rsync in this<br>
tempfolder! We make too for every container 2 rsync runnings. The
first in running mode of the<br>
container and the 2nd in suspended mode of the container!<br>
b) The second step is to create the tar-archives with lzo, but with
full and incremetal backup. So we<br>
make on the nfs for every container a folder and in this we
create the backups ins lzo-archives. When<br>
the counter file in this folder not exists or has inside a number
of backups they are runs over a limit,<br>
we delete only the timestamp - file (-g) and then a fullbackup
runs and the number of the backup will <br>
been written in this counter and begins from 1 otherwise +1. <br>
c) About this strategy, we can have expl. 15 backups per container,
but only every 7 days a fullbackup and<br>
the other days a incremental backup. This reduce extremly the
backuptimes, reduce the load on the<br>
server and need less backup space and we can devide the
fullbackups of containers on diferent days!<br>
Expl. first big container has no counter file a make a fullbackup
on monday, the other big container <br>
will backup full on tuesday and so on!<br>
<br>
We have reduced the time with this strategy for a lot of containers
to ca. 2 hours for ALL with less using<br>
cpu and load! This backup strategy is much secure, ok need for
containers, they must backup, the<br>
double space! But you see one big container 5 hours and we have 4
big containers as same, this will<br>
use with proxmox backup strategy 20 hours and with our concept all
together in 2-3 hours for all containers<br>
with less cpu and less serverload and our clients very happy about
this!<br>
<br>
A other idea is, to make not a rsync and hold the copy! I mean, but
I will test in feature too, make a copy<br>
of a container with inode links only! This works very fast, we used
in our other backup to hold many sets<br>
of backups with small using of place, why only when a file was
changed, then for the old and new file this<br>
need space. When the file was not changed, this need no space! So
easy tu use is, to make not the<br>
rsync, but make a<br>
<br>
/usr/bin/nice -n10 /usr/bin/ionice -c2 -n6 cp -al {container folder}
{temp_backup_folder} 2>/dev/null<br>
<br>
before create the archive files. The problem I see, you get this not
synchrone in short time, so as with<br>
rsync with 2 runnings of rsync. But this need no space and is very
fast on the fly and when the files changed on the<br>
source, then the server held automaticly 2 files otherwise only the
link!<br>
<br>
<br>
<div class="moz-signature">-- <br>
ACHTUNG: Ihr Anfragetext befindet sich unter unserem Absender!<br>
P.S. <a
href="http://blog.1awww.com/2012/05/30/achtung-internet-seiten-betreiber-eprivacy-richtlinien-umzusetzen/"
alt="ePrivacy in Europa">ePrivacy in Europa - lesen Sie mehr -
read more</a> <br>
<br>
Mit freundlichen Gruessen<br>
1awww.com - Internet-Service-Provider<br>
<br>
Detlef Bracker<br>
<img src="cid:part2.04090805.08000609@1awww.com"> Velilla, Calle
Club s/n, E 18690 Almunecar, Tel.: +34.6 343 232 61 * EU-VAT-ID:
ESX4516542D<br>
<br>
<font color="#3366ff" size="1">This email and any files
transmitted are confidential and intended only or the person(s)
directly addressed. If you are not the intended recipient, any
use, copying, transmission, distribution, or other forms of
dissemination is strictly prohibited. If you have received this
email in error, please notify the sender immediately and
permanently delete this email with any files that may be
attached. <br>
<br>
Este correo electrónico y, en su caso, cualquier fichero anexo
al mismo, contiene información de carácter confidencial
exclusivamente dirigida a su destinatario o destinatarios. Queda
prohibida su divulgación, copia o distribución a terceros sin la
previa autorización escrita de Detlef Bracker. En caso de no ser
usted la persona a la que fuera dirigido este mensaje y a pesar
de ello está continúa leyéndolo, ponemos en su conocimiento que
está cometiendo un acto ilícito en virtud de la legislación
vigente en la actualidad, por lo que deberá dejarlo de leer
automáticamente.<br>
<br>
Detlef Bracker no es responsable de su integridad, exactitud, o
de lo que acontezca cuando el correo electrónico circula por las
infraestructuras de comunicaciones electrónicas públicas. En el
caso de haber recibido este correo electrónico por error, se
ruega notificar inmediatamente esta circunstancia mediante
reenvío a la dirección electrónica del remitente.<br>
<br>
El correo electrónico vía Internet no permite asegurar la
confidencialidad de los mensajes que se transmiten ni su
integridad o correcta recepción, por lo que Detlef Bracker no
asume ninguna responsabilidad que pueda derivarse de este hecho.<br>
<br>
No imprima este correo si no es necesario. Ahorrar papel protege
el medio ambiente.<br>
</font></div>
</body>
</html>