All good.
plus this was in the first few lines of the OP....
"️ Setting up the Debian container ️
We will be using a Debian LXC as the base for PBS."
plus this was in the first few lines of the OP....
"️ Setting up the Debian container ️
We will be using a Debian LXC as the base for PBS."
But Udos remark wasn't on the OPs post but antubis question:
The answer to that is "no" which is exactly what Udo explained. So your dispute is a just a missunderstanding because both of you talked about different things
fair point and acceptedThe answer to that is "no" which is exactly what Udo explained. So your dispute is a just a missunderstanding because both of you talked about different things
@PwrBank , i think i have nailed the permissions needed, and i went one step further and wrote a script that can be run as a cron job on truenas that backs up the pbs dataset to Azure (in my case). The script checks PBS isn't writing to the store, stops the proxmox backup service (not the container), does a snapshot, restarts the pbs service in the container, then snapshot is mounted, rcloned to azure and it is alll cleaned up (snapshot deleted and then mount unmounted). - lemme know if you are interested, for me this is going to be my production pbs1 from now on.
having done this its probably not worth stopping the pbs service as snapshots are so quick, so a pre- script for the sync task to make sure there are no backup jobs running and one is probably good to go for 99% of use cases and use the synctask to manage the snapshot lifecycle - but now i have a template to use with other services where that might be less true....
having done this its probably not worth stopping the pbs service as snapshots are so quick, so a pre- script for the sync task to make sure there are no backup jobs running and one is probably good to go for 99% of use cases and use the synctask to manage the snapshot lifecycle - but now i have a template to use with other services where that might be less true....
Last edited:
I really wouldn't do this if you care sbout your data, in this thread a simmiliar script failed:
and that is why
1. i stop the pbs backup service (only when there are no current jobs running)
2. i snapshot the pbs datasets
3. restart pbs server so it is available for backups (because at this point its out of the picture)
4. only backup the r/o mounted snapshot
backing up a live file system like that script - that's hilarious! - his post shows the race conditions of the blocks rclone has indexed at the start of the job 'disappearing'
primary backup of the pbs will be to another pbs i haven't yet built, though considering my # of backups and speed with metadata option i won't use pbs sync but two jobs in the cluster - one to each pbs (my whole backup cycle every 2 hours is like 45s)
tl;dr never let a backup tool backup live files without understanding the implications..... and tl;dr my pbs data is quite safe with this approach, if it isn;t then we have bigger issues as it would mean the on-disk state can't be trusted....
Last edited:
oh god they did it over tailscale too, rofl - I have a 10gb external link and i am very close to Azure US West 2 and a years worth of pbs data for my main proxmox cluster is maybe 500GB tops
Last edited:
Probably you know that, but I thinks it's worth to mention: every time you switch the destination the "dirty bitmap" is dropped. If you toggle every time then every backup needs to read the complete source.
That's why "one single primary PBS" plus "some secondaries via remote sync" is/was better.
(( Disclaimer: that was the actual behavior last time I checked. Any news on this one...? ))
All good
You obviouvsly know what you are doing and know of possible problems and how to avoid them. My sermon was more for people googling for rclone pbs backups or something like that and ending up in this thread so they think things through before they proceed
Last edited:
no i didn't, i wasnt going to change the destination, just have tow jobs, I had assumed each job maintains its own bitmap and comapares against the metadata (i used metadat mode) - i will do some testing and look oout for what you said, its not like the sync jobs will be long, i just heard they were slower. Thanks for the tip.
well i like to think that, but shhhh, do you hear that - sounds like my pride coming before a fall - like this week when i eventually relalized i was having cephFS issues on one node because with a script i had accidentally overwritte the keyfile with a different key.... in /etc/pve/priv .... thank god i never rebooted the other two nodes....
yeah on the script i spent two hours designing it with chatgpt to account for a bunch of failure modes before i even tested it once (i can't code, not even bash scripts, so thats going to be my achillies heal and where i make more mistakes....) but i have designed the requirements for geo dispersed cloud control planes to be used by hundreds of thousands of customers and millions of users - my devs hate me for thinking though all the edge case failures, hahaha.
next up, testing the same methodologies with urbackup and backrest to figure out what i want to do for general data backups from loca machines > truenas and truenas > cloud
i have been using pbs to backup some raspberrypis and my ceph volumes - its worked well so far.... i think PBS is exceptional piece of tech that I would love to expanded to more use cases natively / with gui etc.
Last edited: