Copy yesterday's daily backup to weekly / monthly retention BEFORE running today's
At present, the daily backup will look at the dates that the last weekly or monthly backups were run, and work out whether either of them is due today.
If both of them are, weekly takes priority while monthly waits until the following day. That is key: It stops the weekly and monthly backups being for the same date, so that you always have both of those independently to restore to.
However what then happens is that the daily backup is run, and (if necessary) the resulting backup is copied to the weekly / monthly folder.
Suppose someone has their site set up just to retain weekly backups. On the day after their weekly backup has run, they only have one backup of each account, because the weekly backup has been overwritten with today's daily, so the daily and weekly backups are the same. In a similar vein, if someone has both weekly and monthly retention set, they have 3 different backups except for on a day when the weekly or monthly backup has been stored; on those days, they only have 2, because the daily backup will be the same as one or the other.
There is a very simple way to improve this: Instead of copying the daily backup folder to the weekly or monthly one AFTER running today's backup, do it before. That way, just after a weekly backup has been taken, the weekly backup will be yesterday's, and the daily one will be today's. Now there are no longer days of the week or days of the month when there is one fewer backups.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
We are no longer accepting requests for enhancing the older backup system. The backup system introduced in 11.38 uses a different of method retaining and creating backups.
We are no longer accepting requests for enhancing the older backup system. The backup system introduced in 11.38 uses a different of method retaining and creating backups.
Nice featire request ! This makes a lot of sense no real need for complicated approach just a simple hard link copy before running each backup.
Either this or a simple hook would do the job too…Sorry about not voting I will try and remember to come back in a few months and see if I've been given any votes (my account seems to have missed any votes renewals we were promissed).
Nice featire request ! This makes a lot of sense no real need for complicated approach just a simple hard link copy before running each backup.
Either this or a simple hook would do the job too…Sorry about not voting I will try and remember to come back in a few months and see if I've been given any votes (my account seems to have missed any votes renewals we were promissed).
Absolute HORRID idea. This kills the real use of weekly and monthly backups. PLEASE by gid do not even consider this.
Absolute HORRID idea. This kills the real use of weekly and monthly backups. PLEASE by gid do not even consider this.
One of the worst requests I have ever seen.
One of the worst requests I have ever seen.
We are no longer accepting requests for enhancing the older backup system. The backup system introduced in 11.38 uses a different of method retaining and creating backups.
We are no longer accepting requests for enhancing the older backup system. The backup system introduced in 11.38 uses a different of method retaining and creating backups.
Kenneth has responded, quite fairly, that the legacy backup system is not going to have any new features.
However, the underlying issue that I was raising still exists.
I was describing how the legacy system, on certain days of the month, has fewer independent backups than you would expect. If you set it up to use daily, weekly and monthly backups, you get 3 different dates of backup to use. However, on those dates when the weekly and monthly backups are made, you only get 2. Storage space for 3 is still used.
This same issue still exists for the new backup system, just in a different form. Suppose someone wishes to retain daily backups for 3 days, and to retain 2 monthly backups. They'll be using the disk space to store 5 backups. Ideally, that would mean 5 different dates are being stored. However, on 16th of the month, the daily backups would be for 14th, 15th and 16th, and the monthly ones would be for the 1st and 15th. So the backup for 15th is stored twice.
It would be far better to find a way to have 5 backup dates available if 5 backups are being stored. The easy way to do this is to move, not copy, the daily backup to the monthly location. The backup system could then check that 3 backups exist before getting rid of an old one. So, on the 16th, before the backup there would be backups for 12th, 13th and 14th. The new backup on 16th would mean 13th gets deleted. We'd then have restore points for 1st and 15th of the month (in the monthly location), and 13th, 14th and 16th of the month (daily location).
Kenneth has responded, quite fairly, that the legacy backup system is not going to have any new features.
However, the underlying issue that I was raising still exists.
I was describing how the legacy system, on certain days of the month, has fewer independent backups than you would expect. If you set it up to use daily, weekly and monthly backups, you get 3 different dates of backup to use. However, on those dates when the weekly and monthly backups are made, you only get 2. Storage space for 3 is still used.
This same issue still exists for the new backup system, just in a different form. Suppose someone wishes to retain daily backups for 3 days, and to retain 2 monthly backups. They'll be using the disk space to store 5 backups. Ideally, that would mean 5 different dates are being stored. However, on 16th of the month, the daily backups would be for 14th, 15th and 16th, and the monthly ones would be for the 1st and 15th. So the backup for 15th is stored twice.
It would be far better to find a way to have 5 backup dates available if 5 backups are being stored. The easy way to do this is to move, not copy, the daily backup to the monthly location. The backup system could then check that 3 backups exist before getting rid of an old one. So, on the 16th, before the backup there would be backups for 12th, 13th and 14th. The new backup on 16th would mean 13th gets deleted. We'd then have restore points for 1st and 15th of the month (in the monthly location), and 13th, 14th and 16th of the month (daily location).
I TOTALLY AGREE.
The new backup system does also have the bug.
But anyways, the new backup system is anyway already full of bugs...
It cant even save in remote ftp system files backups, or guess what, it does...
If you are a developer and set via api an option to enable (the already enabled)
settings to move to remote ftp the system files, else it keeps them local (#2 bug)
even if retention is off...
if we got to manually edit config files, its a bunch of perl scripts,
not a control panel...
I TOTALLY AGREE.
The new backup system does also have the bug.
But anyways, the new backup system is anyway already full of bugs...
It cant even save in remote ftp system files backups, or guess what, it does...
If you are a developer and set via api an option to enable (the already enabled)
settings to move to remote ftp the system files, else it keeps them local (#2 bug)
even if retention is off...
if we got to manually edit config files, its a bunch of perl scripts,
not a control panel...
Replies have been locked on this page!