Search results

Hi, @IsThisThingOn For the questions about stop mode I don't know the exact answers. For the dirty bitmaps: from the docs ( https://pbs.proxmox.com/docs/technical-overview.html#fixed-sized-chunks ) and from the observation I know that dirty bitmaps are used only for disk images (not RAM) of VMs...

Note that RAID gives you only redundancy, not backup. If the data are modified by mistake or by someone hostile, you have only redundant garbage, not the data you expect to have. I think you can omit SSD and ZFS and off-site PBS if you want, that's OK. But I recommend at least the following or...

Of course this approach is better than no backup, but it's far from optimal. If somehow the data are modified / deleted by mistake or encrypted by ransomware, then rsync will happily overwrite previous copies with fresh copies (which happened to be broken, encrypted etc.) or even will remove...

You mean upgrading is not possible? What commands do you execute, in detail? And what are their results?

Hi, @Gabrielays When you were searching for a solution, did you see this first result I've got in G. search? https://forum.proxmox.com/threads/connection-error-401-no-ticket-nginx-reverse-proxy.94158/

Hi, @pulipulichen You posted only a screenshot and to make matters worse, it doesn't show all the logs' content (the wrapped parts). If we could see the log in the CODE blocks (this < / > icon above), maybe we could help more. Anyway, what I can hardly see in the screenshot, there's some...

Welcome, @Zexan Hard to guess, because you haven't given the details, e.g. what exactly happens in which stage of installation. Anyway, you check whether the same problem exists with installers of other systems, like Debian, Ubuntu or when booting from a rescue image, e.g. SystemrescueCD.

Have you studied the threads I linked to? And possibly other similar? Have you tried the actions described there?

Depending on the needs of the original poster, it may work enough well :) . I'm writing this from my own experience in a lab. So, @whostolemyname , don't feel discouraged. If you have no faster disks at the moment, use HDDs. Slow backup is better than no backup! ;-)

The official VMware best practices are even more strict: "Do not use a single snapshot for more than 72 hours. The snapshot file continues to grow in size when it is retained for a longer period. This can cause the snapshot storage location to run out of space and impact the system...

Welcome, @whostolemyname I'm not commenting on your particular hardware. Just generally. A few points, in no particular order. 1) Keeping the backups on the same disks as the primary data is not very safe. 2) Though not optimal, you can build Proxmox Backup Server as a virtual machine in the...

Oh, removing subscription nag. You had (or have) some non official addon, which is known to cause problems, especially during upgrade. My advice is get rid off that thingy entirely. P.S. See e.g. these threads...

I don't know if this is the reason, but in Proxmox one should NOT use apt upgrade (NOR apt-get upgrade ). Only apt full-upgrade (or apt-get dist-upgrade ). Disclaimer: I can't guarantee that in your current state of the system, running the proper command now will make it better or worse...

Compression setting? I don't think so. I'm just searching for possible difference reason. Another idea: is the issue time- (or sequence)-related? What if you swap the jobs in time? Will the failure "follow" the job or will it stay at the same time window?

@gralf are you sure the backup jobs have the same config? In the log the options not only have other order and the contents, but also they don't match the screenshots. E.g. it the screenshots, Compression fields are the same: ZSTD. While in the log the first job is --compress gzip and the...

Is it just a warning / informational message? Or a hard error after which you can't continue the installation?

PVE normally doesn't use GUI locally anyway. The GUI is by means of a web browser.

As I wrote: you can check the logs. E.g with journalctl

Check in the (cron) log, which program is called at this time. Then you should be able the find the place where this you@example.com address is written. Or maybe it's not written there, but this is the default address used by this program when the program wasn't instructed what real address to use.

@fribse I would search with: grep -ir you@example.com /etc P.S. After posting it I've noticed that the email address in the command was automatically placed between EMAIL and /EMAIL tags. Of course the real command has to be without these tags. P.S. 2 It's worth to add -a option to grep...