Search results

gibt ein neues ticket dazu, was m.E. mit dieser damaligen beobachtung zusammenhängt : https://bugzilla.proxmox.com/show_bug.cgi?id=7012

hello, i am missing some commandline option for proxmox-backup-client to see which files being backed up, i.e. some "more verbose mode" i know about PBS_LOG , but that's neither seems documented in the manpage, nor in the pbs wiki. and it also needs "debug" to print anything informational on...

ist halt so - wenn du selber scheisse baust, ist es einfach jemand anderen zu blamen bzw. dir die realtität passend zurechtzubiegen, anstatt zu reflektieren oder zurückzuruden. in unserer gesellschaft hat man damit sogar zunehmend erfolg - anders ist ein trump & co auch nicht zu erklären....

nein, wollt ich damit nicht sagen. nur sollte man sich halt nicht nur über solche selbsternannten youtube- oder read-my-tutorial-on-my-blog-profeten bilden sondern auch mal in die hersteller doku wälzen oder ins hersteller forum gucken. ich finde das erschreckend, wie überzeugt heute...

done https://bugzilla.proxmox.com/show_bug.cgi?id=7024

apparently, my question was a little bit too early when switching to metadata for change detection, it now prints file information i'm really impressed that proxmox-backup-client does an incremental run across 336254 and 106956 dirs in just 14s. i hardly can remember having seen such a fast...

war/ist es ihnen doch auch!? https://docs.docker.com/engine/release-notes/29/ Breaking Changes The daemon now requires API version v1.44 or later (Docker v25.0+). aber was können die denn dafür, daß deren "konsumenten" pennen oder leute ggf. veraltete versionen ihrer tools verwenden um mit...

is there a way to also have shown the number of processed files instead of volume/gb ? i'm doing some runtime testing for backups with larger file count and i cannot estimate based on this information i know i can set PBS_LOG=debug, but i'm really missing this as basic information. counting...

ich weiss nicht ob ich das "hürden einbauen" nennen mag. wenn von programmen/tools APIs geändert werden , hat das einen grund. davon abgesehen gibt es ja offensichtlich die möglichkeit clientseitig die gewünschte api version mitzuteilen bzw. zu downgraden. so ne api änderung kommt im kontext...

>Das ist doch gar nicht der Punkt. Ich finde es völlig legitim, docker in lxcs zu benutzen, wenn man sich der Problematik bewusst ist und den >damit verbundenen Folgen (Ausfall von Diensten, troubleshooting etc) leben kann. Mein Eindruck ist aber, dass viele Leute das nicht tun, sondern >weil...

i don't see performance regression . it's performance disadvantages of qcow2 on top of zfs are greatly exaggerated, imho. qcow2: # dd if=/dev/zero of=/dev/sdb bs=1024k status=progress count=10240 9954131968 bytes (10 GB, 9.3 GiB) copied, 12 s, 829 MB/s 10240+0 records in 10240+0 records out...

this is not meant to to make users/customers uncertain about product quality , but whoever is deeper into using qcow2 may have a look at https://bugzilla.proxmox.com/show_bug.cgi?id=7012 , it's about a case where qcow2 performs pathologically slow and while searching for the cause, i found...

>i stil don't know why that 2nd network line causes is , and i don't think it is too interesting to know ? maybe asymetric routing ?

sorry, aber können wir hier evtl bitte doch lieber beim thema bleiben?

i would first disable net1 temporarly in the old and then provide 4 cores and 2048mb to the new lxc comparing two different operating systems is hard enough - but they should have the same lxc/hardware ressources i guess the most prominent different between the two lxc here should be samba...

you mean you have a second lxc container which works without problems? those are both turnkey linux lxc containers, or what? the one with the issue has docker inside?

we had a ticket for this at https://bugzilla.proxmox.com/show_bug.cgi?id=3118, which i just closed. if anybody still sees this with any recent linux distro, please report. (i guess this exists, as bugs constantly (re)appear in linux) ;)

also mind https://bugzilla.proxmox.com/show_bug.cgi?id=4482 and https://bugzilla.proxmox.com/show_bug.cgi?id=3859

für zukünftige "lessons learned" sowie das damit verbundene "copy&paste" um es für andere leichter rüberzubringen: Es ist ein bekanntes Problem, dass bei größeren Updates docker-Container in LXC-Containern immer mal wieder kaputt gehen. Beide nutzen die gleichen Teile des Kernels, daher ist...

@floh8 , i agree that btrfs my be faster then zfs with small file / metadata access, but i would not consider that worth trying until proxmox verfiy didn't get optimization for better parallelism. you won't change your large xx terabytes datastore when in production....