Search results

There are NO snapshots on the volume and it definitely consume 50-100 MBytes/s directly after starting garbage collection until the garbage collection fails. Should I make video for to proof this?

When I start the garbage collection and look at "watch df -h", it counts down by 100MB/s until the 6GB of free disk space is exhausted and fails. After failing the free disk space is 6GB again. For what does it use 6GB? How to solve this problem?

Super, bin noch auf PVE6. Dann gehts ja nach dem Update.

Es wäre sehr praktisch, wenn man im Feld Hinweise, klickbare HTML-Links einfügen könnte, die bei Klick ein neues Fenster oder einen neuen Tab mit der URL aufmacht. Konkret die Admin oder Service-URLs,die von dieser Mascheine zur Verfügung gestellt werden kann. URLs könnten automatisch erkannt...

How much free space does the garbage collect need? I got the following error during garbage collect, while having 16GB free on root und 6 GB free on the backup drive: 2021-07-31T14:34:18+02:00: starting garbage collection on store pvebackup 2021-07-31T14:34:18+02:00: Start GC phase1 (mark used...

Where to I have to put this UVEV rule? In the meantime it discovered that using partitions in a luks encrypted drive seems to be the problem. After the system boots, lsblk gives the following picture: nvme0n1 259:0 0 953.9G 0 disk └─nvme0n1p1 259:1 0 400G 0 part └─nvme-c1...

I use full disk encryption with cryptsetup for the rpool disks and separate vmdate disks. The disks are decrypted at boot time with the initramfs option in crypttab. The boot work fine but the data pool is not recognized and imported reliably. Only after a "partprobe" command it is imported. It...

arch: amd64 cores: 2 hostname: xxxx memory: 2048 mp0: vmdata1zfs:subvol-103-disk-2,mp=/DXUSWP,backup=1 net0: name=eth0,bridge=vmbr0,gw=192.xx.xx.xx,hwaddr=yyyyyy,ip=xxxxxxxxx/24,type=veth onboot: 1 ostype: debian rootfs: vmdata1zfs:subvol-103-disk-1,size=32G startup: order=21 swap: 2048...

I stopped pvesr.timer, then created a snapshot '__replicate_101-0_1617281220__' for both disks, used 'zfs send -I ' to delta transfer it to the other location and started pvesr.timer. However, the first thing the replication job does, is deleting the "stale" snapshot. Here is the log...

Promox current directory is container disk: chown 100000:101001 DISK chown 100000:101001 y Then ls -ln. Output: drwxr-xr-x 2 100000 101001 2 Jan 5 2020 DISK drwxr-xr-x 2 100000 101001 2 Apr 1 14:40 y Then pct enter <CTID>, ls -ln in root directory. OUtput: drwxr-xr-x 11 0 65534...

I have a unprivileged container and mounted a second dxu unter /MYDISK On the Proxmox side it got the access 100000:100000 but under LXC it shoes up as root:nogroup. Why is it not shown as root:root as other directories which have 100000:100000? Is this a bug? I also tried to change the group...

I tried but the snapshot got deleted very quickly. Do I have to halt the replication service (how? which is the service name?). How does Proxmox find the replication snapshot? Does it use the latest one or is the last snapshot registered anywhere?

Ähnliche Frage von mir, aber leider bislang keine Antwort. https://forum.proxmox.com/threads/reactivate-replication-with-existing-synchronized-snapshot.86613/

I had a replication of a 2 TB VM running. For some unknown reason the special replication snapshots *__replicate* are gone. But I have old manual non-replication snapshot and was able to synchronize the ZFS dataset to the second server. I then tried to create a *__replicate*" snapshot hoping...

Any news on the subject. Several people have the same problem and the fix shoud not too complicated.

I have the same problem. On a Windows Server 2003R2 with just 65 GB hard disk, 14,5 GB are "changed" every day even though the machine is NOT used at all! Even the deduplication doesn't seem to reduce the amount. Where do this tremendous changes come from? INFO: creating Proxmox Backup Server...

Actually it is not the problem, that differences are not known, but it seems to be a design deficiency in the container backup format, which is quite different from the VM backup format.

The problem is not LUKS vs ZFS encryption, but the problem to be able to remotely unlock the server. The servers usually have no keyboard/monitor. So a base system is needed to boot up, connect via SSH to unlock the volumes.

At boot decryption is not possible (otherwise I could use full rpool encryption). So is it possible to prevent pve-cluster.service to automatically start up and wait for manual disk decryption and manuall start command (all via ssh)?

I have to store the master private key AND the master key password which is much longer than the actuall encryption key. So I still dont' understand what the use case scenaria is, where the use of the RSA master encryption is useful instead of storing the actual encryption key.