add several processors - handlers for file operations (tar, zip, 7z)

[lexxpavlov]

reopen PR #29 - fix tests
I wanted to add password to archives. But tar command don't have internal possibility of encription, and I decided to add zip compression. The next step was create separate class for compression.

I refactored Database handlers, because file operations not linked with name of these classes (Mysql, MongoDB, Postgresql), in database class only dump operation remains.

I created Processor classes, which handle all file operations (copyFolders and compress).
In this classes I added password option and compression ratio for archivers.

In documentation I added section about choice of archiver - tar, zip or 7z.

And I fixed database tests and add new processor tests (and catch a bug :) tests rules! )

[dizda]

Wow! What a nice PR bro, thank you for your contribution !

It's all good to me !

[lexxpavlov]

Glad to code for you! :)
Your bundle was first in google by "symfony backup" request, and your bundle is great!
My English not well, and you may fix my sections in documentation (readme.md).

[lexxpavlov]

I add date_format option for one purpose - user may set date_format at Y-m-w (week). And everyday backup will override yestarday backup - it will produce one backup per week - every week. And save disk size, needed for backups.
It would be nice to add ability of delete old backups for all of storages. It makes this bundle really great.

[dizda]

For us * :)

Ah indeed, I didn't knew that bundle was first in google :)
BTW My english is well too, i'm french actually! Haha

Yes, setting the date is a good point, for those who wants to save only weeks or months backup !
Ok I will think about deleting old backups, because if you set other date format, it will be more difficult to guess filenames of older files we want to delete, what do you think ? Do you have any suggestions ?

[lexxpavlov]

Yes, you are right, deleting is a trouble, and with custom date format is more trouble.
I see only two ways to do this:

1. save file names and its datetime to database into special table, and doing purge of storage with info from this table.
2. put backups to several folders (with more strong name format) and purge older folders at all.

$filename = date('Y-m') . '/' . $this->filePrefix . '_' . date($this->dateformat) . $this->getExtension();

First way is better, in my mind. And add to database a new field - level of backup (dayly/monthly/minor/major/mybestbackup/etc). This field will be pointed at the command line or in config (default level).
I may try to do this task, but general command, not a real deleting in storage classes.

By the way, creation of intermediate folders for backups may be a good idea. If I will make a backup every day, I will have more than 300 files in backup folder. And in few years of backuping I will have tons of files!

[dizda]

Hmm there is maybe another solution bro.
Let's say we set the maximum date that we want to keep our files.

delete_after: 2 weeks

2 weeks is a DateTime string compatible (see http://3v4l.org/iHtFj )

Now we have that, we can get each files in the backup output directory and compare the "Last modified date" of files (http://php.net/manual/en/function.filemtime.php)

And each files that are older than 2 weeks, will be deleted.
Maybe we can use the Symfony Finder component (http://symfony.com/doc/master/components/finder.html#location), seems to be very neat !

What do you think?

[lexxpavlov]

I thought about mtime, and I afraid that this don't work in all cases. Some filesystems may not support mtime. Even local filesystem may have mtime turned off (for optimisation purpose).
But now I googled and found:
Amazon S3 and Dropbox is support mtime (if client tells mtime while uploads file - need to explicitly specify mtime).
I don't find information, whether the CloudApp supports mtime.
GridFS don't support, but have uploadDate field in the file info.
This solution is good. User will decide if he may to enable deleting or not.

[dizda]

You're right!

Or maybe we can store a file in the backup directory?
.backuped-files, which contain every filenames with the date in timestamp stored in CSV or YAML format to be easily processed by PHP.

This, avoid storing informations in a DB so it's means, avoid many adapters for all kind of database and table creation.

[lexxpavlov]

self-maid meta info. Good idea.

[dizda]

Lol yep, but it'll be stored locally, right ?

[lexxpavlov]

Local or remote - not so important. What is important - consistence of this
metainfo.
But I don't see big difference between local file and database table.
13 сент. 2014 г. 23:16 пользователь "Jonathan Dizdarevic" <
notifications@github.com> написал:

Lol yep, but it'll be stored locally, right ?

—
Reply to this email directly or view it on GitHub
#30 (comment)
.

[dizda]

👍

[lexxpavlov]

I think about one thing now. In present time adding of new storage is
simple - needs add file uploading only. But deleting of old backups will
raise the bar of difficulty for new storage developing. Less people will
contribute own storages...
13 сент. 2014 г. 23:21 пользователь "Jonathan Dizdarevic" <
notifications@github.com> написал:

[image: 👍]

—
Reply to this email directly or view it on GitHub
#30 (comment)
.

[dizda]

What you mean?

[lexxpavlov]

I say that some storages will be support purging, and some storages will be not. It is not necessary to do purge required in storage.