backup question - tar.gz or not ?

[Nerigal]

actually one of my server have to backup about 100 Go of stuff every night with the direct admin backup feature. It take 6 hours to do so... and it take so long just because the fact that direct admin tar.gz each user before sending it over ftp... actually if you have a good Gigabytes Network i think it would be much faster to just backup users as raw data to the backup server exploiting the 100 Mo / sec network as it should be and so the backup server could care about the tar.gzing stuff...with an easy custom script.

calculate it as you wish but in my mind transferring raw data as an average rate of 60 Mo sec is much faster for night backup.

so i wondered if it is possible with direct admin backup to disable the tar.gzing with the direct admin backup feature...if not

plz add an option to do so

 

[nobaloney]

By default, no. I suppose you could write your own backup system. As many of us use backup/restore locally and would also benefit, I've moved your thread to be a Feature Request.

Jeff

 

[DirectAdmin Support]

Hello,

What we use for our files server is rsync. If you have a lot of data, much of which isn't going to change that often, but you need it to be duplicated elsewhere, rsync is the way to go. It transfers only the data that changed, so reduces load immensely, and also reduces bandwidth.

As for the DA backups, to change their format to a non-gz format may get messy (mainly with regards to restoring the data), so I'm not sure we'd go the "directory" route.

There has been talk of adding the per-item checkboxes at the Admin/Reseller level, just as it is at the User Level. The catch, is that you must know what you've got when you go to Restore you Users, because the gz files would be incomplete. We could set a "partial" flag in the name maybe, signifying that it's not "all there"... or some way of visually seeing what's in the backup based on the filename. The reason is that the restore at the Reseller/Admin Levels are for mass usage. The User Level restore is only going to be working on one file, so DA can show the User what's in the backup before restoring it. With a large number of Users, the contents can vary, so there would be no "unified" checkbox page that match. The closest would be "select the items, if they exist in the backup, to be restored", where DA would blindly restore the options if they're present, which could cause confusion.. An error message for any options that were not present could be displayed in the output maybe.

John

 

[interfasys]

Nerigal , I would suggest using duplicity if you're taking the rsync route. It encrypts everything with your PGP key before sending the data remotely.

 

[Nerigal]

Hello,

What we use for our files server is rsync. If you have a lot of data, much of which isn't going to change that often, but you need it to be duplicated elsewhere, rsync is the way to go. It transfers only the data that changed, so reduces load immensely, and also reduces bandwidth.

i would use rsync for sure if i could make backup compatible with DA restor system.

As for the DA backups, to change their format to a non-gz format may get messy (mainly with regards to restoring the data), so I'm not sure we'd go the "directory" route.

well not realy i think because
actualy an user.username.tar.gz extract 2 folders backup/ domain/

the non-gz system could just send "like it is actualy if not gz" in ftp but username/backup and username/domain

so after that an easy script can tar.gzing username/* with the structure DA is waitting for to be able to restore.