У мене є сервер CentOS 5.7, який буде створювати резервні копії своїх файлів щоночі. Я стурбований тим, що відвідувачі різних сайтів, на яких розміщується сервер, матимуть погіршену ефективність, коли резервна копія передається по всій мережі.
Чи можна обмежити максимально дозволену пропускну здатність процесу мережевим інтерфейсом? Я хотів би обмежити передачу файлів на основі SSH лише половиною моєї доступної пропускної здатності. Це може бути на стороні сервера або клієнта; тобто я би радий це зробити або на клієнті, який ініціює з'єднання, або на сервері, який отримує з'єднання.
(На жаль, я не можу додати інтерфейс, призначений для резервного копіювання. Я міг би збільшити свою доступну пропускну спроможність, але це означатиме лише, що передача мережі буде завершена швидше, але все ж максимум загальна потужність з'єднання, роблячи це.)
Деякі передумови
Можливо, якийсь фон в порядку. Відступивши, у мене виникла проблема з недостатнім місцевим простором для створення резервної копії. Введіть SSHFS! Резервна копія зберігається на нібито локальному диску, щоб ніколи не було жодних бітів резервного копіювання на самому веб-сервері.
Чому це важливо? Тому що це, здавалося б, скасує використання поважних rsync --bwlimit
. rsync
насправді не робить передачу, а також не може, тому що я навіть не можу зекономити місце для збереження резервного файлу.
Я чую, як ви запитуєте: "Тож чекайте, навіщо вам навіть робити резервну копію? Чому б не лише rsync
вихідні файли та папки?" Тому що дратівлива річ під назвою "Плеск" є в суміші! Це мій хостинговий веб-хостинг, який використовує Plesk для зручності. Як такий, я використовую Plesk для ініціювання створення резервних копій, оскільки Plesk додає всілякі додаткові чари в резервну копію, що робить його споживання під час процедури відновлення дуже безпечним.
сумне обличчя
ionice
для придушення записів, які може зробити процес. Оскільки я пишу у файлову систему SSHFS, я можу скинути клас процесу резервного копіювання до 3, щоб повністю поступитися місцем будь-якому іншому процесу, який хоче записати. Таким чином я отримую ефект, який я хочу, а це ніколи не погіршувати досвід відвідувачів сайту через пропускну здатність резервного копіювання.