it's possible to add conditions in -ttl of Velero backup (backup from kubernetes clusters). For example: I have a schedule that makes backups everyday at 15:00, the -ttl of this backups is 72 hours, so in 72 hours, this backup will be deleted. Which is the problem? The problem is if the cluster is not up for 3 days, the backups will be deleted after it turns on, and there are will not be any backup left. I need to create a backup with -ttl 72 hours only if there are 3 backups or more in the blob storage. It's possible with Velero?
please use this below command has been used 72hrs backup only.
velero create schedule newschedule --schedule="*/5 * * * *" --snapshot-volumes --include-namespaces=default --volume-snapshot-locations=<SNAPSHOT_LOCATION>
To check this command:
velero schedule get
Make sure snapshot location must be same example/06-local-volumesnapshotlocation.yaml.
Sample output of the above command :
NAME STATUS CREATED SCHEDULE BACKUP TTL LAST BACKUP SELECTOR
newschedule Enabled 2022-06-30 15:15:39 +0530 IST */5 * * * * 720h0m0s 5m ago <none>
For your Reference :
openebs/velero-plugin
Back Up and Restore a Kubernetes Cluster Using Velero
you can go ahead and create a schedule.
Setting up the schedule
"Back up my cluster every day at 7 am"
velero schedule create every-day-at-7 --schedule "0 7 * * *"
Related
This should be quick - I know how to run .net webjobs down to every minute..
eg 0 0/1 * 1/1 * *
but I would like to run every 10 seconds!! I can find unix methods, but no azure webjobs / ,net examples..
To schedule a triggered WebJob you need to add a schedule property to the settings.job file. The value of the schedule is cron expression that has 6 fields to represent the schedule: {second} {minute} {hour} {day} {month} {day of the week}.
So you just add the following to a settings.job file if you want to run every 10 seconds.
{
"schedule": "*/10 * * * * *"
}
If your app runs continuous or scheduled WebJobs, enable Always On to ensure that the WebJobs run reliably. This feature is available only in the Basic, Standard, and Premium pricing tiers.
For more details, you could refer to this article.
the patterns seems to be like Cron schedule jobs
*/10 * * * *
https://crontab.guru
I am using shared hosting cpanel my server timezone UTC format.
Every minute cron job is working fine.
Minute Hour Day Month Weekday Command
* * * * *
But when I am trying to Once per day it's not working.
15 21 * * *
in the above settings, it should run at 09:15 pm but it's not working.
verify your local timezone and server timezone are same or different.
in cronjob set the time by server timezone....
may be
I've developed a webjob and while I've been testing it, I set it to be manually triggered. I'm happy with the functionality and now I want to set it to run every 30 minutes.
In the publish file (webjob-publish-settings.json) I set this "runMode": "Continuous" and I included a setings.job file with this setting
{
"schedule": "0 */30 * * * *"
}
I initially set it to 'copy if newer' and I uploaded the webjob. In the azure webjobs section I had a listing for this webjob, type = continuous and it showed the schedule setting.
I've had to make some amendments and upload again but now the status says 'Pending Restart' and the schedule info has gone. I changed the settings.job file to 'copy always' but the schedule still isn't showing.(just n/a)
how is this process supposed to work ?
** UPDATE
I still cant get this to work, in my main program file I have this
Task callTask = host.CallAsync(typeof(Functions).GetMethod("CreateQueueMessage"));
callTask.Wait();
I then have a webjob-publish-settings.json file with this
"runMode": "OnDemand"
and finally, a settings.job file with this
"schedule": "0 0,15,30,45 * * * *"
so I would expect it to run every 15 mins now, but it doesn't, the schedule doesn't even show up alongside the webjob
If your goal is to have a scheduled WebJob, you should not be deploying it as a Continuous WebJob, which is a very different thing. Continuous WebJobs are for cases where you have an executable that starts and never terminates. Triggered (and scheduled) WebJobs are used when you have an exe that starts, performs one task, and then terminates.
The schedule is completely ignored in continuous WebJobs.
The reason you're seeing your Continuous job run every minute is that the system keeps trying to restart it, since it expects it to never terminate.
I'm trying to setup a cron job with Bolt.cm via the Plesk 11.5.30 admin console.
Bolt task scheduler documentation: https://docs.bolt.cm/v20/tasks
Scheduled Tasks
I have setup crontab for the apache user as follows:
Min H DM M DW Command
0 */1 * * * /var/www/vhosts/mysite.com/httpdocs/app/nut cron
0 */1 * * * httpdocs/app/nut cron
The reason for two different commands here is that I've read in another thread troubleshooting Plesk that the command path should be relative from the domain. I assume if the first one fails, the second will still run. I also assume the above will run cron every hour.
Bolt Config
In my config file the cron_hour is set to 3am. However as the listener is set for an hourly event CRON_HOURLY I assume the setting is bypassed/ignored. Either way this setup has been running for over 48 hours and no effect has yet been witnessed.
Bolt Setup
As a test I have added the following into my Bolt extension so that it should simply send me an email when it is run (the following has been cut down to keep it short).
use \Bolt\CronEvents;
class Extension extends \Bolt\BaseExtension
{
function initialize() {
$this->app['dispatcher']->addListener(CronEvents::CRON_HOURLY, array($this, 'cronNotifier'));
}
function cronNotifier() {
// send email script...
}
}
I've tested my email script individual so I know it works. With the cron job setup and assumed to be running this function is never hit. What's more is that in the database the bolt_cron table remains to be empty.
If anyone could help suggest some things I could try to get this running it would be greatly appreciated.
THE FIX
In order to fix this issue I altered my schedule to execute every 5 minutes (quicker debug loop). I then made the following discoveries:
I had to set execute permissions on public for the nut file (so apache user could execute it)
for the server I'm using only the full path version works
Thanks #Gawain for prompting me in the right direction.
Scheduled Tasks
Yes, that looks correct. The handling of directory locations was enhanced recently, but you used to need to call nut from in the Bolt directory.
Bolt Config
cron_hour only applies to daily, and longer periods. There was a bug I fixed recently that was blocking out midnight to 3 am hourly tasks.
OK, there should be traces logged in the Bolt log about running cron events.
If you run this, do you see the hourly job trigger and your email sent?
./app/nut cron --run=cron.Hourly
If that works, then the problem is with the system cron/crontab, if editing directly were you using crontab -e?
Also if you're on an older checkout of master, you can try to prefix the crontab command section with
cd /var/www/vhosts/mysite.com/httpdocs &&
...before each invocation of ./app/nut
For one of my two Azure scheduler service job collections, the one that is hosted in the South Central US region is having some real problems. Absolutely nothing shows up now on the Dashboard, Scale, Jobs or History "tabs" (see screen shot). Is anyone else having similar issues with any of their job collections in this (or any other) Azure region?
(sorry, can't attach an image)
This was due to an issue that was impacting the portal display for jobs with more complex schedules (e.g. on a particular day of the week).
In the meantime, the jobs themselves do not have any issue and will continue to execute as expected.
You can also see the jobs via the powershell cmdlets (can be installed from here):
PS C:\> Get-AzureSchedulerJob -JobCollectionName northcentraljc -Location "North Central US"
JobCollectionName : northcentraljc
JobName : northcentralbing
Lastrun : 8/4/2014 9:30:01 AM
Nextrun : 8/11/2014 9:30:00 AM
StartTime : 5/26/2014 9:30:00 AM
Status : Enabled
Recurrence : 1 per Week
Failures : 0
Faults : 0
Executions : 11
EndSchedule : None
As an update: the issue was fixed on ~10 PM (PST) on 8/5/2014.