DA instructions on admin_backups and remote backups WITH dates

The reason for this is that if you're going to do cron remote backups, you should have multiple dated versions, and not just have every backup overwrite the previous one.

By default, some sort of dates should be applied to the filenames, or subfolders (just like with "system backups"). I don't understand the logic behind NOT setting some sort of dates by default, especially if you are given an option to run this from cron--like why would anyone NOT want a date associated with your backups? It's ridiculous.
 
Last edited:
Also, there should be an option for rotating backups... Example: keep only the last 5 backups.
 
I love DA--have been using it forever... But when the most basic fundamental need, like the above, goes overlooked all these years, someone gotta say something--come on now, this is just silly!
 
That no one has responded to the thread is surprising to me; perhaps no one else is interested in the feature?

I've moved the thread it's now a feature request :).

I solve the problem at the remote server end by revolving directories on the backup server, but I agree that this would be a nice feature.

Jeff
 
I'm not sure this is going to do what we want.

For example, we do daily backups and set up to append the day of the week.

In the middle of the week a user gets deleted. In this scenario the backup will stay in the directory because the same directory would get used if it exists.

So After a few months, for example, the system drive crashes, and we need to restore the user. He'd end up with all the users he had ever backed up, and if his account was set for a smaller number of users, he might get the wrong users restored with errors for users the system attempted to restore after his limit was reached, even if those users were current users recently added, because the deleted users would have been restored.

Am I making sense?

Am I misunderstanding something?

If I'm right then I'll probably continue to rotate on the backup server.

Jeff
 
I'm guessing you're right, you could of course check the file modification dates on the backup files before restoring, to see if they were actually recent, or left behind (in a GUI this could be done very easily by sorting on date, selecting all non-recent files and delete them).

Other than that you can write scripts to tackle the issue (delete old files automatically) but then again, most of us are already using custom scripts to manage the backup retention.

I suppose the new date feature that has been added can be used to help out in a retention setup, but isn't a complete solution in most cases.
 
Last edited:
Arieh said:
I'm guessing you're right, you could of course check the file modification dates on the backup files before restoring, to see if they were actually recent, or left behind (in a GUI this could be done very easily by sorting on date, selecting all non-recent files and delete them).
Click to expand...
I could. But it's another step in the restore process And it means we're wasting space saving accounts we don't need to save. With many machines and terrabytes of backups this could add up. Our current backup server is 3.8 TB, but it's soon to be replaced by a system holding 6 TB with room to expand to 10 TB.
Other than that you can write scripts to tackle the issue (delete old files automatically) but then again, most of us are already using custom scripts to manage the backup retention.
Click to expand...
I've already got scripts to manage it; every night, just before a new backup starts, I remove backup 6, increment the filenames the backups 1 through 5 to 2 through 6, rename currentbackup to backup1, and create a new currentbackup directory. Very little work, easy enough to automate, and each folder holds only the files it needs.

Works for me. :) But for people who can't or won't run scripts on a backup server the DirectAdmin solution is a great step forware.

Jeff
 
You must log in or register to reply here.
Back
Top